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

[Mariano Martinez Peck]

On Sat, Jun 18, 2011 at 4:20 PM, Gerardo Richarte <gera at corest.com> wrote:

>
> **
> 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?
>

mmmm I have in mind only yhe two that are for executing CompiledMethod in an
object. Those are primitive 188 and 189.
    "Perform method directly"
        (188 primitiveExecuteMethodArgsArray)
        (189 primitiveExecuteMethod)

But that ony happens by using the bytecode as we saw in this example. I have
no idea whether the same can happens from another place.




> In any case, I think there is a subtle difference
> between a bytecode and a primitive.
>

+1


> 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.
>

Do you know what happens in other Smalltalk VMs in this concrete case for
example?


> 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.
>
>
thanks, interesting :)



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


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110618/3c94bff7/attachment.htm