Re: [Xen-devel] [PATCH v3 10/10] x86/MSI-X: provide hypercall interface for mask-all control

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Thu, Jun 11, 2015 at 09:35:51AM +0100, Jan Beulich wrote:
> >>> On 05.06.15 at 13:28, <JBeulich@xxxxxxxx> wrote:
> > Qemu shouldn't be fiddling with this bit directly, as the hypervisor
> > may (and now does) use it for its own purposes. Provide it with a
> > replacement interface, allowing the hypervisor to track host and guest
> > masking intentions independently (clearing the bit only when both want
> > it clear).
> 
> Originally I merely meant to ping the tools side changes here
> (considering that the original issue has been pending for months,
> delayed by various security issues as well as slow turnaround on
> understanding the nature and validity of that original issue, I'd
> _really_ like to see this go in now), but thinking about it once
> again over night I realized that what we do here to allow qemu
> to be fixed would then also be made use of by the kernels
> running pciback: While Dom0 fiddling with the MSI-X mask-all bit
> for its own purposes is at least not a security problem, it doing
> so on behalf of (and directed by) a guest would be as soon as
> the hypervisor side patches making use of that bit went in.

It is hard to comment on this since I don't know exactly what
those patches would do.  But the 'pci_msi_ignore_mask'
from 38737d82f9f0168955f9944c3f8bd3bb262c7e88, "PCI/MSI: Add
pci_msi_ignore_mask to prevent writes to MSI/MSI-X Mask Bits""
should have prevented that. That said said patches could change
the pci_msi_ignore_mask of course.

> 
> While I continue to be of the opinion that all direct writes to
> interrupt masking bits (MSI-X mask-all, MSI-X per-entry mask,
> MSI per entry mask) outside of the hypervisor are wrong and
> should be eliminated, the scope of the problem now clearly
> going beyond qemu made me reconsider whether we shouldn't,
> as advocated by Stefano, follow the trap-and-emulate route
> instead. This would not only mean adding code to x86's existing
> port CF8/CFC intercepts, but also write-protecting the MMCFG
> pages for all PCI devices being MSI or MSI-X capable, emulating
> writes with inspection / modification of writes to any of the mask
> bits located in PCI config space. (A subsequent optimization to
> this may then be a hypercall to do config space writes,
> eliminating the emulation overhead, accompanied by a bitmap
> indicating which devices' CFG space can be written directly.)
> 
> For a (from now on) timely resolution of the original problem I'd
> really appreciate opinions (or alternative suggestions).

Weeding out the direct writes is nice, but the process of eliminating
those is going to take time.

I like your idea as it provides a nice mechanism to track which
component is at fault writting to those areas and can help in
fixing that. But on the flip side - it also might delay patches
for the offending code as we would have already an 'firewall'
in place.

> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel