[Mono-dev] [PATCH] Implement field load/store verification

Rodrigo Kumpera kumpera at gmail.com
Fri Jun 22 11:54:17 EDT 2007


The attached fix fixes only the load address issue with constructors, the
paragraphs about class constructors said about this fact. I'll focus on the
access checks until we settle down the overlapping field issue. Enjoy your
vacations. :)

Cheers,

On 6/22/07, Rodrigo Kumpera <kumpera at gmail.com> wrote:
>
>
>
> On 6/22/07, Paolo Molaro <lupus at ximian.com> wrote:
> >
> > On 06/21/07 Rodrigo Kumpera wrote:
> > > >This should be allowed in the .cctor for the class (same for the
> > > >equivalent case of an instance field and the .ctor): a test case is
> > > >something like:
> > > >
> > > >        readonly static MyValueType v = new MyValueType (5);
> > > >
> > > >Note, eventually you also need to add accessibility checks: the
> > method
> > > >needs to be able to access the field keeping in mind both the field's
> >
> > > >and the field's class visibility.
> > > >
> > >
> > > Definely, the spec say nothing about that, I'll add this check and
> > mark it
> >
> > There are references to this both in the instance constructor and type
> > initializers paragraphs (and also under Field contract attributes).
> >
> > > as a spec issue. About the accessibility checks, I'm going to tackle
> > all
> > > cases at once, as it should quite hairy, I believe.
> >
> > There is code to deal with this in mini/mini.c, it is mostly complete
> > (look for can_access_field and can_access_method). Note that such code
> > must not be duplicated, we need to share it for both implementations.
> >
> > > >The code for overlapped fields is not as trivial as this. It is
> > moreover
> > > >something you should do on a per-type basis instead of per-field
> > access
> > > >in the IL code. metadata/object.c has the code to do proper
> > overlapping
> > > >field detection: that code should not be duplicated.
> > >
> > >
> > > I don't quite follow you, I should test it it's a load/store to a
> > class with
> > > bad overlapping, even if the target is a good field?
> >
> > The process of verification doesn't involve just a single method's
> > code: major things in the assembly containing it must be checked first.
> > verify.c contains quite a bit of those checks, more are needed of
> > course.
> > Between them there is the field overlapping detection: it is a check
> > that doesn't belong inside the field access checks, but it belongs
> > to a per-type check that you need to perform anyway.
> > In the field access you need just to check if the type was ok
> > and the type should have been checked earlier (though it's reasonable to
> > check it lazily whenever a type is seen, but the full checks for the
> > type are needed, not just about overlapping fields). So you'd have code
> > like this whenever a type or class is seen:
> >
> >         if (!type_is_ok (type)) {
> >                 report verification/validation issues in type
> >                 return;
> >         }
> >
> > and inside type_is_ok():
> >         // lazy check
> >         if (!type_has_been_checked (type))
> >                 check_type (type);
> >         return type_status (type) == ok;
> >
> > With this code field overlapping will just be one of the many checks
> > performed inside check_type ().
>
>
> So the idea is to lazy check all types that a method faces, seen a
> reasonable approach. About the overlapping tests, I've been checking against
> .net and I got the following results regarding verifiable code:
>
> -can create objects with dangerous overlapping
> -can load/store from other non-overlapping field
> -only loading from bad overlapping fields cause verification errors.
>
> What you think that should be done on this case?
>
> Rodrigo
>
> lupus
> >
> > --
> > -----------------------------------------------------------------
> > lupus at debian.org                                     debian/rules
> > lupus at ximian.com                             Monkeys do it better
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070622/9f8bc485/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: field_ops_and_misc_fixes_take2.patch
Type: application/octet-stream
Size: 14204 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070622/9f8bc485/attachment.obj 


More information about the Mono-devel-list mailing list