On Tue, Apr 01, 2008 at 08:10:31PM +0200, Andrea Arcangeli wrote: > On Tue, Apr 01, 2008 at 06:18:07PM +0100, Daniel P. Berrange wrote: > > and very few application domains are allowed to access them. THe KVM/QEMU > > policy will not allow this for example. Basically on the X server, HAL and > > dmidecode have access in current policy. It would be undesirable to have to > > all KVM guests full access to /dev/mem, so a more fine grained access method > > would have benefits here. > > But pci-passthrough can give a root on the host even to the ring0 > guest, just like /dev/mem without VT-d, so there's no muchx difference > with using /dev/mem as far as security is concerned. Only on the CPUs > including VT-d it's possible to retain a mostly equivalent security > level despite pci-passthrough.
Clearly it is a loosing battle without VT-d. That doesn't mean we should design it to loose in general. So we should design to that when we do have VT-D it will have the maximum security possible. VT-d will only become more widespread over time. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
