Re: Ping: [PATCH] x86/MSI: add mechanism to protect MSI-X table from PV guest accesses

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 28/02/13 09:22, Jan Beulich wrote:
>>>> On 07.02.13 at 09:44, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>>> On 06.02.13 at 17:50, "Jan Beulich" <JBeulich@suse.com> wrote:
>>> This adds two new physdev operations for Dom0 to invoke when resource
>>> allocation for devices is known to be complete, so that the hypervisor
>>> can arrange for the respective MMIO ranges to be marked read-only
>>> before an eventual guest getting such a device assigned even gets
>>> started, such that it won't be able to set up writable mappings for
>>> these MMIO ranges before Xen has a chance to protect them.
>> I should probably mention the alternatives:
>>
>> 1) Brute force scan of the (PV) guest's L1 page tables, locating
>> eventual mappings of the questionable MMIO pages, and
>> converting those mappings to R/O ones.
>>
>> 2) Snoop BAR modifications (via xen/arch/x86/traps.c:
>> guest_io_write(), taking note of which BAR(s) are relevant at the
>> point where the device gets first detected/reported), perhaps
>> along with snoops of the PCI_COMMAND_MEMORY bit.
> So I just now sent a mail to Linux'es PCI subsystem maintainer,
> assuming that we'll go with the approach the patch presented at
> the start of this thread. The outcome of this, however, is not
> really relevant for the hypervisor side change to go in, as it
> would only affect the placement of the new hypercall within
> pciback or the core PCI subsystem.
>
> That assumption is largely because no-one really voiced an opinion
> towards a preference of one of the alternatives described above.
>
> Unless I'll receive an explicit NAK or further comments moving this
> discussion forward, I'm intending to commit the patch without
> anyone's ACK in a few days time _and_ backport it to the stable
> trees (4.2 at least, not sure how well it will backport to 4.1).
>
> Jan

For what it is worth, I think the principle is good.  One query I have
is whether it is sensible to restrict this to dom0, as the comments
indicate, or whether it should be permitted to be used by any domain
with appropriate permissions to manage PCI passthrough.

How do you see dom0 attempting to use these hypercalls in an example of
passing a PCI device through to an untrusted domain?

~Andrew