[Mono-dev] The State Of Mono Assembly Verification?
Miguel de Icaza
miguel at ximian.com
Thu Feb 2 13:46:18 EST 2006
Hello Paolo,
> > I've been experimenting with calling
> > mono_image_verify_tables and mono_method_verify a la
> > pedump, but I think verification is erroneously
> > failing, especially when verifying branching.
>
> mono_method_verify () has been superseded by verification during
> JIT time. The latter is more correct and complete, though a few
> checks are still missing.
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).
Miguel.
Hi,
There are no problems with these AFAIK, it is just a _lot_ of work.
IMHO, instead of
modifying the JIT, we should implement a proper verifier which we need anyway.
Zoltan
On 1/23/06, Miguel de Icaza <miguel at novell.com> wrote:
> Hello Paolo, Zoltan,
>
> Today if the JIT fails to compile a method because of some internal
> problem (someone produced some invalid IL, we reference an assembly that
> does not exist, the code has been obfuscated) we typically g_abort.
>
> I would like to turn these into exceptions (this is in part
> required by some folks which are embedding the Mono runtime and might be
> running arbitrary code on it).
>
> Ignore the security issues for now, those we are discussing in
> parallel with Sebastien, but this is a step that we need to get in
> place.
>
> Is there anything stopping us from doing it that I might be missing,
> or is this just a matter of going through the code, encapsulating the
> errors into some error reporting format, and throwing an exception in
> the layer closest to the JIT?
>
> Miguel
>
More information about the Mono-devel-list
mailing list