It is much simpler than that! You just need a separate Smalltalk root
object to which only the VM has access. It has its own set of classes
which are unique pointers. This means that the user-level image never
has any pointer to any of the objects inside of this core image. This
means that it can never GET access to it either! So they can't tamper
with the code in the first place, since they can't see it.
The VM just passes code from the user-part of the memory to the
verification part of the memory, since the VM has access to both. As
simple as that.
cheers,
Toon
On 03/22/2011 02:17 PM, Igor Stasenko wrote:
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
