Walter did yo realy go Ohhhh?

[Nick Sabalausky]

"David Jeske" <davidj at gmail.com> wrote in message 
news:g37coj$2q9u$1 at digitalmars.com...
> Nick Sabalausky Wrote:
>> ... From the security perspective, for instance, there are differences
>> (With a VM, you can sanbox whatever you want, however you want,
>> without requiring a physical CPU that supports the appropriate security
>> features.)
>
> It seems that security/verifiability, and ease of executing on an unknown 
> target processor are the two major benefits of a VM.
>
> However, you might be interested in looking at software based fault 
> isolation if you have not seen it. It may make you reconsider how much you 
> need a VM to implement code security. There is a pretty simple explanation 
> here:
>
>  http://www.cs.unm.edu/~riesen/prop/node16.html
>
>


Thanks. Interesting read.

Although expanding *every* write/jump/(and maybe read) from one instruction 
each into five instructions each kinda makes me cringe (But maybe it 
wouldn't need to be a 1-to-5 on every single write/jump after some sort of 
optimizing-compiler-style magic?). I know that paper claims an overhead of 
only 4.3% (I wish it had a link to an online copy of the benchmark 
tests/results), but it was written ten years ago and, as I understand it, 
pipelining and cache concerns make a far larger speed difference today than 
they did back then. And, while I'm no x86 asm expert, what they're proposing 
strikes me as something that might be rather pipeline/cache-unfriendly.

Plus, maybe this has changed in recent years, but back when I was doing x86 
asm (also about ten or so years ago), the x86 had *very* few general-purpose 
registers. Like 4 or 5, IIRC. If that's still the case, that would just make 
performance worse since the 5-6 extra registers this paper suggests would 
turn into additional memory access (And I imagine they'd be cache-killing 
accesses). I'm not sure that they mean by i860, though, 
Intel-something-or-other probably, but I assume i860 isn't the same as 
i86/x86.

Granted, I know performance is a secondary, at best, concern for the types 
of situations where you would want a sandbox. But, I can't help thinking 
about rasterized drawing, video decompression, and other things Flash does, 
and wonder what Flash would be like if the browser placed the flash plugin 
(I mean the actual browser plugin, not an SWF) into this style of sandbox.

Of course, VMs have overhead too (though I doubt Flash's rendering is done 
in a VM), but I'm not up-to-date enough on all the modern VM implementation 
details to know how a modern VM's overhead would compare to this. Maybe I'm 
just confused, but I wonder if a just-in-time-compiled VM would have the 
potential to be faster than this, simply because the VM's bytecode 
(presumably) has no way of expressing unsafe behaviors, and therefore 
anything translated by the VM itself from that "safe" bytecode to real 
native code would not need those extra runtime checks. (Hmm, kinda weird to 
think of a VM potentially being *faster* than native code for something).