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

[Jim Purbrick]

> mono_method_verify () has been superseded by
> verification during JIT time.

When JIT time verification is failed is there an
exception thrown that an embedding app can use to take
appropriate action?

> The latter is more correct and complete, though a
few
> checks are still missing.

Do you know exactly which checks are missing? I can
currently only inject microthreading in to assemblies
that use a subset of the full CIL opcodes anyway and
so have to whitelist opcodes as I transform
assemblies. If the missing checks only apply to
opcodes like exception handling that I currently don't
allow then the missing checks may not be a problem.

> There are several rules to enforce, we haven't yet
> scheduled a full audit to make all the checks and 
> make sure they are correct.

> Mono development is driven by user needs and user
> contributions, so contributing fixes and features is

> the best way to get something done.

Fine. We need bytecode verification and are happy to
contribute to get it done. Our initial goal is to
fully verify the subset of CIL that we currently use.

> We'll help with advice, code reviews, and
> actual code, since full verification is one of our 
> mid/long term goals anyway.

Allowing the gamut of languages that target the CLI to
be used is one of our mid/long term goals too and
we'll need full verification to allow that, so our
goals are aligned.

> Plus it helps to know that some people actually need

> the feature.

Well, we need the feature.

> I suggest starting with a comprehensive list of test
> cases that we can use as a test suite for the 
> verification process.

What's the best way to set up this test suite?
Manually craft unverifiable assemblies for each
verification check and then test that Mono rejects
them?

> > open CLI assembly verifiers I could use instead?
> 
> There is no complete and tested verifier, so your
> best bet is to help us improve the mono one. 

Fine.

> Also note that a verifier is not enough
> to ensure secure execution: you need also the CAS
> runtime support that Sebastien has been working on 
> (activated with the --security switch).

Yes, I've been talking to Sebastien about this. We're
currently using method call whitelists rather than CAS
while we're only allowing the LSL language and library
calls, but want to use CAS in the mid/long term when
we allow arbitrary languages and open up parts of the
.NET framework for use by scripts.

Cheers,

Jim.


		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com