The issue isn't whether or not the architeture as it existed in the past is or isn't able to securely isolate user and kernel mode processes in an OS which may not exist. If an OS can be written to securely isolate user and kernel mode processes then I am sure that someone clever will find a way to use it to do such a thing and may have an excellent security solution for that OS which runs on current chips. I wish whomever tries to do this the best of luck. [Moderator's Obnoxious Note: I believe such an operating system is called "Unix"...] In Windows there are a number of reasons we can't use the current isolation model for absolute enforcement of isolation. The biggest business reasons are backwards compatibility for applications and kernel mode drivers, both of which count on the current architecture and all of it's strengths (and quirks). As we have stated before, we designed Pd with the assumption that we couldn't break apps and we couldn't break device drivers. Arbitrary Windows code which runs today must continue to run and function in Pd as it does today, and yet Pd must still be able to provde protection. Someone with a niche OS who doesn't care about breaking things may use a different approach - they don't have gazllions of lines of 3rd party code counting on version to version compatibility. We do.
From a technical perspective, there are also a number of reasons that the current isolation models don't work My guess is that a hard core Linux or Unix kernel dev could probably explain this just as well as MS could, however I will see if I can get someone on our end to outline the issues as we see them.
I think that you are talking about separating user-mode processes in VMWare (right?). What about SCSI controllers? The BIOS? Option ROMS? Kernel mode device drivers? DMA devices? Random kernel foo.sys? What if the attack uses SMM to attack VMWare itself? How does VMWare prove that the environment it inherited when it booted is valid? Lastly - Pd is only partially about process isolation. Nothing in the current architecture even attmempts to address SW attestation, delegated evaluation, authentication, or the sealing of data. P ----- Original Message ----- From: "Nathaniel Daw" <daw@cs.cmu.edu> To: <cryptography@wasabisystems.com> Cc: "Cypherpunks" <cypherpunks@minder.net> Sent: Tuesday, September 17, 2002 3:01 PM Subject: Re: but _is_ the pentium securely virtualizable? (Re: Cryptogram: Palladium Only for DRM)
The fact that VMWare works just means they used some tricks to make it practically virtualize some common OSes, not that it is no longer possible to write malicious software to run as user or privileged level inside the guest OS and have it escape the virtualization.
I spoke with someone who had evaluated the appropriateness of the VMWare internals for security sandboxing with respect to just this point. He seemed to believe that it is simply not possible for processes in the guest to escape the sandbox (perhaps, in light of the paper you cite, this signals inefficiencies in VMWare). Other people on this list were, I believe, involved in porting VMWare to be hosted under the BSD architecture and may be able to speak further about this. In any case, the broader point that has been made repeatedly is that even if the Pentium is not efficiently, securely virtualizable due to quirks in its instruction set, clearly there are architectures which are but which avoid the objectionable, user-hostile, aspects of the Pd scheme.
n
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to
majordomo@wasabisystems.com
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com