[Vm-dev] Re: [Pharo-project] test crashing the cog vm

Eliot Miranda eliot.miranda at gmail.com
Thu Mar 24 18:53:05 UTC 2011


On Thu, Mar 24, 2011 at 11:42 AM, Igor Stasenko <siguctua at gmail.com> wrote:

> On 24 March 2011 19:34, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >
> >
> > On Tue, Mar 22, 2011 at 5:34 AM, Stéphane Ducasse
> > <stephane.ducasse at inria.fr> wrote:
> >>
> >> But why we could not have a byecode validator at the image level that
> >> first make sure that byte code are in sync with the format of the
> objects.
> >
> > Because it can be compromised.  An in-image verifier is subject to
> attack,
> > and could be disabled by an attack that got past the in-image verifier
> > before it got a chance to run.  An in-VM verifier is not possible to
> > side-step because it is the only way to execute code.  So an in-VM
> verifier
> > can be secure but an in-image one can't and so is pointless.
> >
> For real hacker there's nothing impossible :)
>

True, but it can be much harder.  How would you attempt to hack past the
fact that the interpreter and JIT code, including the verifier, is in
read-only memory?  If this is the only route to create executable code, and
it always verifies the bytecode before it executes then it is secure right?

[there are issues; one doesn't want to verify a method each time it is
activated in the interpreter, but e.g. a bit in the header saying "this
method has been verified" might be easy to compromise.  I'm not sure it is
though, because one big advantage of the current funky method format (half
literals, half btes) is that there's only one primitive to construct a
method and it has to have a valid header, and there's only one way to modify
the header, objectAt:put:.  So as far as I can see the VM can in fact
preserve the integrty a header flag bit that says "this method has been
verified".  Am I right or wrong?]


>
> Right now its not possible to split image to layered onion (like
> operating system does, where you have kernel level,
> and user level), but i think (at least in theory) such composition
> could be implemented, except that sure thing
> we don't have resources to invest in this direction.
>
> It is actually nice field for research (hello guys from academy :)
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110324/674e1dba/attachment-0001.htm


More information about the Vm-dev mailing list