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

[Xen-devel] pciback: question about the permissive flag

To: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] pciback: question about the permissive flag
From: Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 06 Jul 2010 23:37:27 +0200
Delivery-date: Tue, 06 Jul 2010 14:38:21 -0700
Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:subject:content-type; s=smtpout; bh=q8KE8uVJo0qXt4DK9DwRWysiJV8=; b=u8cQAQSO0jYGa5yFj6isv2SnURRiqgAC89q+3WpuibZ6dcNWOqmiYwRMjQjc7ueCTTyQ16yfst0uCkrtDjI0kRiTiow3GUqrUgsOy1O4BdLB6rEsSFPwsPWTWAsEz95iZUMrdjyOdRU0iDzo38gDtwdckLD+qXl4Yhfin0kNv38=
Envelope-to: www-data@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Lightning/1.0b2pre Thunderbird/3.0.5
I'm trying to understand the purpose of the permissive flag in the Xen
pciback driver. The comments in the code suggest that setting
permissive=1 is "potentially unsafe", and I've been wondering why?

My thinking goes this way -- we either:

1) have IOMMU/VT-d in the system, and use it to isolate the device
assigned to a DomU, in which case allowing the DomU to fully control the
assigned device's config space should not be a problem because VT-d
should do its job (we hope at least ;),

or

2) we don't have IOMMU/VT-d, in which case assigning a device to
anything other than Dom0 is simply insecure, no matter if we try to
restrict access to config space (but still allow DMA engine to be
programmed by DomU) or not.

So, what am I missing here?

joanna.

Attachment: signature.asc
Description: OpenPGP digital signature

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