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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.02.13 at 11:00, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Thu, 2013-02-07 at 08:44 +0000, Jan Beulich wrote:
>> >>> On 06.02.13 at 17:50, "Jan Beulich" <JBeulich@xxxxxxxx> 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.
> 
> This sounds reasonable, is the "when resource allocation ... complete"
> difficult to assess or likely to be fragile going forward?

I went through that logic on the Linux side a couple of times, but
couldn't really convince myself of when resource re-allocation might
happen, or would be guaranteed not to happen. I may have to try
to ping the PCI subsytem maintainer(s) to (hopefully) get a firm
statement...

>> 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.
> 
> When would this occur? Just on setup (might be ok) or on any MMU update
> (clearly not) or some middle ground (like only DOMID_IO mappings
> perhaps)?

Since we carry out the page table modifications for the guest
anyway, the only point this is needed is when the first MSI-X
interrupt gets set up. But the guest can do this setup at any rate,
and hence it might get us (maliciously) very busy in this scan, and
handling preemption here might be tricky.

>> 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.

Actually, the I/O port based CFG accesses would even be the more
strait forward part. The trickier thing would be the MMCFG based
alternative.

> Do these modifications come straight from the guest, or do they come
> from dom0 via pciback and/or dom0's own PCI subsystem setup? If these
> are coming via pciback then it seems reasonable to me to use physdev
> operations, which takes us back to the patch you've implemented I think.

All CFG accesses go through pciback. The resource assignment (and
hence BAR modifications) are done exclusively by Dom0 (anything
else would be a security hole).

Jan



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