Walter did yo realy go Ohhhh?

[Don]

Nick Sabalausky wrote:
> "Don" <nospam at nospam.com.au> wrote in message 
> news:g37vm8$114c$1 at digitalmars.com...
>> 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...
>>
> 
> What's the difference between that x86 page protection and whatever that new 
> feature is (something about process protection I think?) that CPUs have just 
> been starting to get?  (boy, I'm out of the loop on this stuff) 

The page protection is implemented by the OS, and only applies to user 
apps, not kernel drivers.

 From reading the AMD64 System Programming manual, it seems that the 
'secure virtual machine' feature is roughly the same thing, except at an 
even deeper level: it prevents the OS kernel from accessing specific 
areas of memory or I/O. So it even allows you to sandbox the kernel (!)