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] granting access to MSI-X table and pending bit array

To: "Konrad Rzeszutek Wilk" <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] granting access to MSI-X table and pending bit array
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Wed, 07 Jul 2010 15:31:28 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 07 Jul 2010 07:31:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100707141424.GE4823@xxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4C346F8C0200007800009F57@xxxxxxxxxxxxxxxxxx> <20100707141424.GE4823@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 07.07.10 at 16:14, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
> On Wed, Jul 07, 2010 at 11:14:04AM +0100, Jan Beulich wrote:
>> The original implementation (c/s 17536) disallowed access to these
>> after granting access to all BAR specified resources (i.e. this was
>> almost correct, except for a small time window during which the
>> memory was accessible to the guest and except for hiding the
>> pending bit array from the guest), but this got reverted with c/s
>> 20171.
>> 
>> Afaics this is a security problem, as CPU accesses to the granted
>> memory don't go through any IOMMU and hence there's no place
>> these could be filtered out even in a supposedly secure environment
>> (not that I think devices accesses would be filtered at present, but
>> for those this would at least be possible ), and such accesses could
>> inadvertently or maliciously unmask masked vectors or modify the
>> message address/data fields.
>> 
>> Imo the pending bit array must be granted read-only access to the
>> guest (instead of either granting full access or no access at all),
>> with the potential side effect of also granting read-only access to
>> the table. And I would even think that this shouldn't be done in the
>> tools, but rather in Xen itself (since it knows of all the PCI devices
>> and their respective eventual MSI-X address ranges), thus at once
>> eliminating any timing windows.
> 
> That sounds sensible. You got a patch ready?

Would be nice, but that's not that simple as currently there's no way
to distinguish r/w mmio and r/o mmio.

Additionally we may need to override the guest's page table
attributes, as generally at least Linux maps I/O memory writeable
no matter whether any writes will actually happen - which to me
seems to be an ugly hack (but I can't think of better alternatives).

Furthermore I'm not really clear how a HVM guest's writes to the
MSI-X table get processed - clearly they can't be let through to
the actual MMIO region. I'd guess they somehow get redirected
to qemu (since pciback doesn't seem to be handling this), but I
don't know this process very well...

Jan


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