On 22 March 2011 08:55, Marcus Denker <marcus.denker@inria.fr> wrote:
On Mar 22, 2011, at 12:17 AM, Toon Verwaest wrote:
On Mon, Mar 21, 2011 at 7:23 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
This would be a nice little topic... this bytecode verifier.
Probably on top of Opal
The bytecode verifier must be in the VM. Â If it is up in the image it can be side-stepped. Â The VM is the ultimate executor of code and so it must apply verification. Â It could be written in Smalltalk and verified in Smalltalk and then translated. Â But it must be part of the VM and used by the VM before running any previously unverified method. best, Eliot
Indeed, Mariano's response made me want to scream: NOOOOO! :)
HOWEVER!, Thinking about it now, it's actually a very interesting proposal! What if we write this piece of software in Smalltak and give it to the VM as part of the VM definition. The VM decides what the application can see, so it might as well not give access to this smalltalk-written bytecode validator that it knows to be safe. If it's built by a separate classbuilder in a separate environment, it can be clearly separated, invulnerable to become: and other evil-doing. So, in short. It's written in Smalltalk (YAY!), but becomes part of the VM runtime, not of the image running on the VM. If we just make sure that we can write out image segments that the VM can use as part of its core (exactly what I do in Pinocchio incidentally), we can just develop and test it nicely in Pharo. Ain't that super-duper cool?
If we would have solved the security problem already, then we could use it for the bytecode verifyer, too... (guarantee that nobody tampers with the verifyer). We need to reify that was makes "the VM" special and provide it for all smalltalk code. But that is of course research and completely  not clear yet what it means.
By stretching, you can treat VM as a hardware which you can't change and must follow its rules. But as someone said, hardware is an early crystallized software, which means that we can change it, but at much higher cost(s) in terms of engineering effort and time. As we hopefully approach closer to self-sustaining systems (like SqueakNOS shows) the need in VM, as a separate software layer between hardware and a language is smearing. And i would really like to see it completely disappeared at some day. There are a family of languages which is already very close to self-sustaining form - a concatenative languages, like Forth or Factor. Most of them are implemented in themselves, and have very thin layer between language and hadrware implemented in C, the rest is already in language. See http://concatenative.org/wiki/view/Factor/Optimizing%20compiler
Marcus
-- Marcus Denker  -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
-- Best regards, Igor Stasenko AKA sig.