On Thu, 24 Mar 2011, Igor Stasenko wrote:
On 24 March 2011 19:53, Eliot Miranda eliot.miranda@gmail.com wrote:
On Thu, Mar 24, 2011 at 11:42 AM, Igor Stasenko siguctua@gmail.com wrote:
On 24 March 2011 19:34, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Mar 22, 2011 at 5:34 AM, Stéphane Ducasse stephane.ducasse@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.
Also note that this effort is against the "keep the VM simple, move as much stuff to the image side as possible" paradigm.
Levente
-- Best regards, Igor Stasenko AKA sig.