Walter did yo realy go Ohhhh?

[Yigal Chripun]

Nick Sabalausky wrote:
> "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).
> 
> 
could you explain please why there's a need for a sandbox in the
first-place?
I think that security should be enforced by the OS. On windows, I see
the need for external means of security like a VM since the OS doesn't
do security (Microsoft's sense of the word is to annoy the end user with
a message box, requiring him to press OK several times...)
But on other OSes that seems unnecessary since the OS provides ways to
manage security for code. linux has se-linux and there are newer OSes
developed with the concept of capabilities.
so, unless I'm on windows, what are the benefits of a VM that I won't
get directly from the OS?

--Yigal