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

[Eliot Miranda]

2011/3/24 Levente Uzonyi <leves at elte.hu>

>
> On Thu, 24 Mar 2011, Igor Stasenko wrote:
>
>
>> On 24 March 2011 19:53, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>
>>>
>>>
>>>
>>> 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?]
>>>
>>
>> To my thinking, verification needs to be performed at the moment of
>> installation method to some class.
>> Because if method is not installed anywhere, performing verification
>> is just a waste of time,
>> and moreover it could be erroneous and tedious, because compiler could
>> fill method's state in multiple stages.
>>
>> Instead, if we could have a primitive
>> installMethod: aMethod forClass: aClass
>> then we can put verification there as well as sealing compiled method
>> for the rest of its life.
>> As well, as we no longer need to flush cache (like
>> MethodDictionary>>at:put: does), because VM can do this
>> correctly in given primitive so, it is an additional benefit.
>>
>> For this to work, we should also prevent modification to methods
>> dictionary once it assigned to particular class
>> (we will need additional primitives for removing/replacing methods in
>> given dictionary).
>>
>
> Note that are primitives (188 and 189) to execute methods which are not
> installed in the object's class's method dictionary.
>

+1


>
> Also note that this effort is against the "keep the VM simple, move as much
> stuff to the image side as possible" paradigm.
>

+1


>
>
> Levente
>
>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110324/1373c813/attachment.htm