[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH 2/3] New 'permissive' attribute for hostdev



On 12/21/2009 02:57 PM, Daniel P. Berrange wrote:
> On Mon, Dec 21, 2009 at 08:43:14PM +0100, Jiri Denemark wrote:
>>>> When it is set to 'yes', some check whether a device is safe to be
>>>> assigned to a guest will be weakened.
>>>
>>> I think this is a rather ill-defined concept to be adding the guest XML,
>>> since there are many checks done for assignment, and this is only impacting
>>> one of them. Whether to allow a device beind a non-ACS enable switch to be
>>> used in a VM has implications beyond just the one VM it is assigned to. Thus
>>> is strikes me that the decision as to whether to allow use of devices behind
>>> non-ACS switches should be a host level attribute. eg a config item in the
>>> /etc/qemu/qemu.conf file
>>
>> This was the idea behind:
>>
>>      What remains to be implemented is the logic of the whitelist that you
>> mention in comments #2 and #3.  To be honest, I don't love this idea of the
>> whitelist; not only will we have to maintain some kind of table, we will need
>> to make sure the table is up-to-date every time new hardware comes out.  It
>> also breaks the security of the setup without letting the user know about
>> (because it is on a magic whitelist that the user probably won't know anything
>> about).
>>
>>      I have an alternate proposal.  What if we added a new <permissive/> tag
>> to the libvirt XML for device assignment?  In the normal case, we wouldn't
>> allow *any* passthrough of devices behind non-ACS switches.  However, if the
>> user knows what they are doing, and they want to take this risk, they can add
>> the <permissive/> tag to the XML, in which case it would allow the assignment
>> to happen.  This can even be used pretty successfully in virt-manager; it just
>> needs to catch the appropriate exception from the first assignment, pop-up
>> "This is dangerous because of non-ACS, blah, blah.  Are you sure?", and then
>> re-do the assignment with the <permissive/> tag.
> 
> I think this is a pretty horrible user experiance, since the first thought
> will be 'what on earth is ACS?', closely followed by clicking 'OK'. There are
> also already many other restrictions on PCI device assignment, such as the
> availabilty of FLR, availablity of PM-reset, even VT-d itself, and we don't
> have user facing tunables to turn off those checks. These are all low-level
> hardware details that users really aren't equipped to understand - even
> most of us developers don't really understand them. 
> 
> I don't much like the idea of having to maintain a whitelist of devices
> that are safe to use, but pushing the problem off to the end user via 
> a config option/confirm dialog is just avoiding the issue. 

I know I'm very late in responding to this, but I thought I'd expand a bit
about the problem (and why maintaining a whitelist doesn't solve the problem
either).

Any PCI devices that are behind non-ACS bridges are not safe to assign to
guests (since they can initiate peer-to-peer DMA transfers to other
devices, theoretically subverting IOMMU isolation).  Unfortunately, a
number of multifunction NICs operate in exactly this manner; they are
non-ACS capable, meaning that if you assigned different functions on the
card to different guests, they could subvert each other.  Doubly
unfortunate is that these types of NICs are *exactly* the types of NICs
that you would want to do assign to guests.

A whitelist doesn't really help here.  While you can whitelist these
multi-function NICs to allow them to be passed-through, you are also
lowering the security of the system without telling the administrator.
That's why I suggested the additional <permissive> (or whatever) flag;
I didn't want to lower overall security of the system without giving
the administrator a heads-up.

I agree that users/administrators probably have very little idea of
what ACS is, but I don't have any better ideas at the moment.  We are
stuck between the rock of lowered security and the hard place of poor
user experience.  If anyone has better ideas about how to go about
this, I'd be happy to hear them.

-- 
Chris Lalancette


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]