On 22 March 2011 14:02, Toon Verwaest <[email protected]> wrote: > The problem is exactly what you had at hand. Your bytecode WAS valid, but it > was used in combination with an incompatible class layout. So validation > here wouldn't solve anything. You always need to validate in a closed world > to ensure you don't accidentally break everything. Whenever you change > something, you need to ensure that you revalidate the relevant parts. In > this case you could for example just have validated that your new class is a > valid subclass of its superclass; which it was not. > > To make the system more secure obviously you would have to check those > things, but if you add part of the API that circumvents these checks, like > you were doing by calling "Class new" rather than using the ClassBuilder > which does do the checks, everything breaks. The only authority that can > actually ensure that you don't circumvent these checks is the VM. > > Obviously you can make sure already in your image that you have enough > checks everywhere. You just don't have a crashproof mechanism that will > chain your users down avoiding that they shoot themselves in the foot with > segfaults. If you put it inside of the VM you -can- provide such a > mechanism, because you don't execute anything unless you know it's safe. And > as I said, this piece of code could be a piece of prevalidated Smalltalk > code that's immutable from the rest of the image. >
Yep.. and that is possible only after you introduce irreversible immutability mechanism into VM, which marking object(s) to be immutable for the rest of their existence. > cheers, > Toon > > On 03/22/2011 02:37 PM, Alexandre Bergel 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. >>> Why this has to be done in the vm. >> >> I agree with Stef. It is not obvious for me why it has to be done at the >> VM. >> >> Alexandre > > > -- Best regards, Igor Stasenko AKA sig.
