[Vm-dev] I really don't understand why this doesn't crash

[Gerardo Richarte]

On 06/15/11 05:05, Mariano Martinez Peck wrote:
>
>     and lastly but not less, you have found 2 security problems in the VM
>     (may be just one, ok).
>
>     The first one is at a language level, where you can break the
>     encapsulation of objects by executing an arbitrary CompiledMethod
>     in any
>     object.
>
>
> Yes, but this is already possible with some other primitives ;)
It'd be very interesting to build a list of those primitives, what others
do you have in mind? In any case, I think there is a subtle difference
between a bytecode and a primitive.  A primitive can be effectively
stopped at language level, by not exposing a method, or discretionary
exposing it, or not making reachable the object implementing it. A
bytecode is different, and has to be checked by the interpreter-jit
(runtime environment in general). Well, I think

>
> What I wonder, and what I would really like to know is the reason why
> NOT to check bounds. Is all about speed?
>
I think yes, it is speed: if every bytecode had to check it, it'd be a
strong degradation of performance. A more complex implementation
could have a /bytecode verifier/, to check, when then native code is
emitted, if the structure of the receiver, in this case, is suitable for
the code. In an interpreter similar checks could be done, once the
first time a method is going to be activated in a certain receiver
(if instance methods are not possible in the system, this could be
cached per class, otherwise some little more complex checks have
to be implemented.

As a note, the Java VM and the Flash VM, at least, have strong bytecode
verifiers specifically for security reasons.

    gera


> Thanks
>
>
> -- 
> Mariano
> http://marianopeck.wordpress.com
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110618/e6e6d2de/attachment.htm