From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: granting access to MSI-X table and pending bit array Date: Wed, 7 Jul 2010 10:14:24 -0400 Message-ID: <20100707141424.GE4823@phenom.dumpdata.com> References: <4C346F8C0200007800009F57@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <4C346F8C0200007800009F57@vpn.id2.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org 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? > > Jan