I am not saying that this is feasible with the current VM. But I am doubtful that the bytecode verification can only be done in the VM. If something get wrong, why not to raise a primitiveFailed, as 1/0 will do? I have the impression that you give a particular status to the bytecodes. I have the feeling that we should not. I can realize a division, and time to time it get wrong (/0). But the VM does not crash. So, why if I evaluate the wrong bytecodes, the VM should crash? You could have the necessary guards in the VM. But the full algorithm for verification could be in the VM. I am not expert on this and I may perfectly be wrong. Most of virtual machine maker will say that a good debugger and profiler can only be done in the VM. Do you agree with this? Cheers, Alexandre On 22 Mar 2011, at 09:24, Toon Verwaest wrote:
Construct me any scenario just based on the image, and I can show you how I can avoid it and segfault your system anyway.
Construct me any piece of code that can segfault my approach. I doubt that you'll find any.
I can't really say more, since I don't know what you are unconvinced about :)
cheers, Toon
On 03/22/2011 03:19 PM, Alexandre Bergel wrote:
Hi Toon,
Thanks for having taken the time to reply. I understand your and Eliot's email but I am left unconvinced.
Alexandre
On 22 Mar 2011, at 09:02, Toon Verwaest 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.
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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.