[Mono-dev] The State Of Mono Assembly Verification?

[Sebastien Pouliot]

Hey Zoltan,

Not sure if you were answering me or, more probably, the complete
thread, anyway...

On Thu, 2006-02-02 at 21:43 +0100, Zoltan Varga wrote:
>                                   Hey,
> 
>  IMHO, verification should be kept separate from the JIT. The job of the JIT is
> to generate machine code _fast_, while the goal of the verifier is to
> be _secure_.

I think there are other issues to consider (like code duplication,
reuse, total time...) but personally I don't mind either solution.

> Mixing the two would probably lead to a JIT which wasn't very fast, and it
> wasn't very secure either. 

Can this be re-phrased as "can't have maximum performance with all
security checks" ? as I believe we *could* have a fast (but not as fast
as it could be) JIT with all checks - just like MS has (at least if we
had the same resources ;-).

> 'We are missing some checks' is a far cry from security.

Can't disagree with that. In fact 'We have all the checks' is still a
far cry from security ;-)

> 
>                                             Zoltan
> 
> On 2/2/06, Sebastien Pouliot <sebastien.pouliot at gmail.com> wrote:
> > On Thu, 2006-02-02 at 20:41 +0100, Joachim Ante wrote:
> > > > A few weeks ago I asked about something related to this, currently when
> > > > the JIT encounters something it does not like, it bails out in the form
> > > > of a g_abort, and the question was whether there were any reasons not to
> > > > try to recover from this gracefully and return an exception.
> > > >
> > > > Zoltan suggested that we should implement a proper verifier, but if the
> > > > right way of doing verification is by sending the method to the JIT,
> > > > then we should go down the path I proposed (email pasted at the end).
> > > I second this. It would be very very useful for us if mono wouldn't g_assert
> > > but throw exceptions when the dll is invalid/broken/obfuscated/maliciously
> > > modified.
> >
> > I believe it would be useful to many people - even if most don't realize
> > it today. Until then Mono is "restricted" to run trusted code which,
> > IMHO, "limits" it usefulness (I admit the "limit" is probably rather low
> > as there are very few applications supporting partial trust today).
> >
> > Anyway the truth (please feel all free to prove me wrong ;-) is that
> > security, especially runtime security, hasn't been very popular with
> > contributors - in any form (e.g. code, samples, reviews, test cases...).
> >
> > I may be biased but I'm glad that Novell is investing in this (ok I'm
> > totally biased ;-). However Mono could use a little more global support
> > and/or contributions in this domain. I guess we could see this as either
> > a participation or a patience game ;-)
> > --
> > Sebastien Pouliot  <sebastien at ximian.com>
> > Blog: http://pages.infinit.net/ctech/
> >
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >
-- 
Sebastien Pouliot  <sebastien at ximian.com>
Blog: http://pages.infinit.net/ctech/