WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] possible pciback security issue


On 4 May 2006, at 15:08, Jan Beulich wrote:

Having looked more closely into what would be needed to enable MSI
support I stumbled across a simple question: If a
domU is granted access to an MSI-capable device, it could maliciously
or erroneously enable MSI on that device and
program an arbitrary vector to be delivered, or even force the message
address and/or value to something that might make
the system misbehave/crash.
It would seem to me that filtering only a few header fields is
insufficient from a security point of view, not only
from the perspective of MSI. While this may severely limit
functionality, I think by default only read access must be
granted to any fields/bits of unknown meaning (namely everything
outside the header).

That *is* the default.

Oh, sorry, I missed the permissive flag.

Ryan's putting together a story on device-specific PCI config-space access filtering, to avoid needing to set the permissive flag for as many common devices as possible.

As for the particular example of MSI -- I think pciback will set up that field as part of device handoff when booting a driver domain. Then it should not be necessary for the driver domain to touch the MSI PCI config field at all. We should probably explicitly disable access to that field, even when permissive mode is enabled.

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel