On Fri, Jan 06, 2006 at 05:54:00PM +0100, Manuel Bouyer wrote:
> On Thu, Jan 05, 2006 at 11:47:55PM -0500, Thor Lancelot Simon wrote:
> 
> Or read arbitrary memory. I fully understand that.
> 
> > It's not a point to gloss over, because the
> > security implications are very real -- and the cost of using xbd for
> > domU disks to mitigate the problem is, really, quite small.
> 
> Yes, they're real.?But it's still not exactly the same thing as giving
> full access to dom0: you have to hack domU's the kernel first, in order
> to execute code with kernel privileges.

I don't understand what you mean.  Given a malicious application
running in dom0 (a "privileged" domain), it must "hack dom0's kernel
first" in order to write arbitrary memory.

If you allow domU kernels to access PCI DMA engines, a malicious
application running in such a domU (what people erroneously, once
it has DMA access, call an "unprivileged" domain) must "hack domU's
kernel first".

In both cases, a bug in the OS kernel running in the domain the
malicious application is running in allows arbitrary memory to be
written, including that belonging to other domains.

In other words, just as I originally said, if you grant an
"unprivileged" domain access to a PCI device that does DMA, you no
longer have a domain that is actually unprivileged at all -- a bug in
its kernel has precisely the same consequences as a bug in the domain
0 kernel; the "privileged/unprivileged" distinction disappears.

This is why I strongly recommend against granting domains in which
one intends to run any network-facing applications (or to which one
intends to grant access to potentially untrustworthy users) access
to any PCI device.  Use xbd instead: it is simple, enforces proper
access controls, and imposes only a small performance penalty.

Thor