but _is_ the pentium securely virtualizable? (Re: Cryptogram: Palladium Only for DRM)

Peter PeterNBiddle at hotmail.com
Wed Sep 18 09:15:12 PDT 2002


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 at cs.cmu.edu>
To: <cryptography at wasabisystems.com>
Cc: "Cypherpunks" <cypherpunks at 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 at wasabisystems.com
>

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com





More information about the cypherpunks-legacy mailing list