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

[Igor Stasenko]

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


-- 
Best regards,
Igor Stasenko AKA sig.