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

[Paolo Molaro]

On 02/02/06 Miguel de Icaza wrote:
> >  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_.
> > Mixing the two would probably lead to a JIT which wasn't very fast, and it
> > wasn't very secure either. 'We are missing some checks' is a far cry
> > from security.
> 
> What about this plan:
> 
> 	* Introduce an API in the runtime that verifies an assembly.
> 
> 	* The API can be invoked from a tool, we already have pedump
> 	  --verify.
> 
> 	* This API could be exposed to those that do not want to call
> 	  an external process to verify. 

We already have all that, what is missing is interest from contributors
to fix/finish the implementation (or time for us inside Novell to do it).
At first I implemented the current external verifier, mostly to help with
the development of mcs;-), so you guys could check that the compiler produced
valid code. I had planned to use the same verifier inside the jit, to avoid
duplication of code. The issue is that the jit has different needs.
The JIT needs to be able to execute also non-verifiable code, but it can also
avoid some checks which would be expensive. So using the external verifier
was more of a burden and it would slow down compilation too much.
The JIT needs to check for valid IL code always and it needs to do it
while converting IL code to the internal representation, because
it needs to change the IR (typically by inserting instructions etc.).
So the JIT can't be done without it's own IL code checks, having an
external verifier is usless for the JIT viewpoint (consider also the needs
to verify and validate Re.Emit code in memory).

Now, we have two needs:
1) validation and verification at JIT time
2) offline validation and verification

Now, point 1 is always needed and it needs to be implemented mostly inside
the jit (metadata checks can be external and shared with 2).
Having limited time, I didn't work anymore on 2 (metadata/verify.c),
because 1 can always be used to implement at least the most useful
subset of 2.

If contributors are willing to work on 2, it's fine, but that won't help
much with the security of the mono runtime, which is what people
ultimately want, IMHO.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better