Walter did yo realy go Ohhhh?

[Don]

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.

It's quite unnecessary on an x86. The x86 has page protection 
implemented in hardware. It's impossible to write to any memory which 
the OS hasn't explicitly given you.
The problem occurs when the OS has buggy APIs which have exposed too much...

> 
> 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.

It was an old Intel CPU.

> 
> 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).
> 
>