Squeak VM stability?
Dan Ingalls
Daniel.Ingalls at sun.com
Sat Dec 29 04:31:30 UTC 2007
[apologies if this is late in the discussion. I have spent the last
couple of hours battling with various verschluggener mail profiles
for reestablishing a setup that works for me to post on squeak-dev
[my problem and new ISP ;-]]
Michael van der Gulik <mikevdg at gmail.com> wrote...
>Is the policy of the VM makers (whoever they currently are) to
>prevent the VM from crashing, particularly when given malicious
>bytecodes?
>
>This is a general question, mostly related to
><http://bugs.squeak.org/view.php?id=1395>
>http://bugs.squeak.org/view.php?id=1395 which is now closed. Is it
>considered a bug if I can crash the VM with a maliciously crafted
>method?
>
>Which direction would the Squeak community want to go in? Should we
>aim to have a VM that would never seg fault and dump core (or blue
>screen under Windows), regardless of what rubbish is fed to it?
>Doing extra sanity checks and bounds checking would possibly have a
>performance penalty.
This is an interesting topic, and at this point I can't presume to
answer where the community wants to go with it. I can say that, as
first designed, the VM was considered to be perfect if it would
execute every valid method perfectly, and ideal if it did so at
maximum speed.
To deal with garbage would require a lot of checks to be made, all of
them in frequent bytecodes, and many of them more expensive than the
actual operations themselves. For instance, it would appear that you
would want to do range checks on loads, stores and jumps, which is
just about all there is. I suppose you could do less than this and
still make it uncrashable, but if one is going to pay this kind of
attention to integrity, one would want to tell the user at the first
sign of error, rather than just keep making errors but not crash.
This would mean checking load bounds rather than waiting until
something weird happens later because you loaded garbage from an
invalid location.
Therefore, I suspect that things would be much more complicated, and
would run something like 2-3 times slower than before. And what,
exactly, is improved over VMs of the last 10 years? My opinion,
FWIW, is that execution of valid methods well compiled is still a
good success criterion for the VM. If someone wants to feed the VM
from a different source, then they should provide appropriate
integrity checks on their bytecodes. And if security is the real
agenda here, then it's probably best to acknowledge that up front and
look at the bigger system issues involved (http://www.ERights.org
being a good place to start ;-), before worrying about malicious
bytecodes.
- Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20071228/5a05c17d/attachment.htm
More information about the Squeak-dev
mailing list
|