Re: some questions

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Thu, Jan 05, 2006 at 02:44:36PM -0500, Thor Lancelot Simon wrote:
> On Thu, Jan 05, 2006 at 08:35:43PM +0100, Manuel Bouyer wrote:
> > On Thu, Jan 05, 2006 at 12:18:59PM -0500, Thor Lancelot Simon wrote:
> > > >
> > > > Yes, that what's it's for. You'll have to build custom kernels with
> > > > PCI support for the domUs
> > > 
> > > It's very important to understand that if you allow any "unprivileged"
> > > domain to access a device that does DMA, the domain is no longer
> > > unprivileged in any meaningful way.
> > 
> > The situation is not that bad, the dom0 controls which kernel is loaded
> > in the domU, and also controls the console.
> 
> I'm pretty sure it is, in fact, "that bad".  A misbehaving domU with
> access to a PCI device that does DMA, on a platform without an IOMMU
> (does Xen 3 even bother to use the IOMMU where available?) can overwrite

Are there x86 hardware with IOMMU ?

> memory in the dom0 kernel and gain complete control of the machine.  Heck,
> if the DMA device is a disk controller, you've even got convenient temporary
> storage to stash the complete memory contents of the system, scan through
> them to figure out what you need to smash, then DMA the right page back
> into place where you aren't supposed to be writing.  In other words, the
> hypervisor, in this case, gives you no meaningful isolation between the
> kernels at all.

Sure. But for this you have to gain direct access to the DMA device,
so the domU's kernel has to misbehave. Which kernel is running on the
domU is under the domain0's control, so if enouth access control are
present in this kernel (and it's bug-free :) it can be trusted.
For this, the kernel's memory has to be non-writable for any userland process,
this is why I talked about starting this kenrel at securelevel 1.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--