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

Jiri Denemark jdenemar at redhat.com
Mon Dec 21 19:43:14 UTC 2009


> > 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 just changed it to an attribute as I think it fits better.

Jirka




More information about the libvir-list mailing list