qemu-devel
[Top][All Lists]
Advanced

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

Re: device hotplug & file handles


From: Michal Privoznik
Subject: Re: device hotplug & file handles
Date: Mon, 11 May 2020 12:20:41 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

On 5/7/20 4:49 PM, Gerd Hoffmann wrote:
   Hi,

For usb device pass-through (aka -device usb-host) it would be very
useful to pass file handles from libvirt to qemu.  The workflow would
change from ...

   (1) libvirt enables access to /dev/usb/$bus/$dev
   (2) libvirt passes $bus + $dev (using hostbus + hostaddr properties)
       to qemu.
   (3) qemu opens /dev/usb/$bus/$dev

... to ...

   (1) libvirt opens /dev/usb/$bus/$dev
   (2) libvirt passes filehandle to qemu.

Question is how can we pass the file descriptor best?  My idea would be
to simply add an fd property to usb-host:

  * Coldplug would be "-device usb-host,fd=<nr>" (cmd line).
  * Hotplug would be "device_add usb-host,fd=<getfd-name>" (monitor).

Will that work from libvirt point of view?
Or does anyone have an better idea?

thanks,
   Gerd

PS: background: https://bugzilla.redhat.com/show_bug.cgi?id=1595525


I don't have a better idea, but a little background on why libvirt even invented private /dev in the first place. The reason was that occasionally, when udev ran its rules it would overwrite the security labels on /dev nodes set by libvirt and thus denying access to QEMU. See:

https://bugzilla.redhat.com/show_bug.cgi?id=1354251

Now, I think there is the same risk with what you are proposing. This isn't problem for DAC where permissions are checked during open(), but it may be a problem for SELinux where each individual operation with the FD is inspected.

Having said that, I am not against this approach, in fact I'm in favour of it. Let's hope that people learned that having udev overwriting seclabels is a bad idea and the bug won't appear again.

Michal




reply via email to

[Prev in Thread] Current Thread [Next in Thread]