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). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 4 May 2006, at 13:57, 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. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 04.05.06 15:06 >>> > >On 4 May 2006, at 13:57, 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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, 2006-05-04 at 15:13 +0100, Keir Fraser wrote:> 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. > > -- KeirDoing something like the attached patch should be sufficient to ensure that even in permissive mode, you can''t turn on MSI (note that I quickly coded this patch as an example and haven''t compiled/tested it yet; I believe it should do what we want, but I''m not really in a position to give it the testing that it deserves). I don''t really like having to add fields to just block the handling in permissive mode (I feel as though this is creeping towards a default permit mentality), but I understand its usefulness for letting users get their devices working immediately if they''re willing to accept the risk of less isolation. AFAICT, the rest of the MSI fields are meaningless unless the MSI enable bit is set so I believe that is all that needs to be protected. Ryan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel