pci device assignment as non-root?
Hello!
I'm - finally - experimenting with PCI device assignment in kvm-83, starting with something as simple as an internal dialup modem (not softmodem) which uses no DMA and does not share IRQ with other devices.
The thing works just fine, but only when run as root. When running as non-root, even after chmod'ing /sys/bus/pci/.../config appropriately, it fails to activate the device in question:
$ kvm ... -pcidevice host=03:06.0 ... Failed to assign irq for "03:06.0": Operation not permitted Perhaps you are assigning a device that shares an IRQ with another device?
(No IRQ sharing here).
After looking at the source I found this in
x86/kvm_main.c:assigned_device_update_intx():
if (!capable(CAP_SYS_RAWIO))
return -EPERM;So basically it wants the user to have SYS_RAWIO capability to assign the irq. That's probably right, but it effectively makes the whole thing root-only, because capability system is broken on linux (it's another long topic, what's relevant here is that one can't grant any given capability to a given non-root process). Even if it were solved and a non-root has SYS_RAWIO, it's better to drop that capability after all the init stuff is done, following the very good principle of least privilege (this is why I want to run it as non-root to start with; it's more: on a production system I'll restore permissions of the sysfs files after startup).
So it looks like some other trick is needed here (not cap_sys_rawio but some traditional unix rwx thing), OR kvm binary has to be able to drop privileges after all the init is done.
The latter SEEMS to be easy as it only involves userspace (it's ok for me to start the whole thing as root as long as it drops privs, I don't need to give certain PCI devices to arbitrary users), but has its own issues. Namely, I'd like kvm to open disk image files and stuff like that as non-root too, since it's the only way to force read-only opens currently.
Comments?
Thanks!
/mjt
Quoted 34 lines · Michael Tokarev
Hello!
I'm - finally - experimenting with PCI device assignment in kvm-83, starting with something as simple as an internal dialup modem (not softmodem) which uses no DMA and does not share IRQ with other devices.
The thing works just fine, but only when run as root. When running as non-root, even after chmod'ing
/sys/bus/pci/.../configappropriately, it fails to activate the device in question:$ kvm ... -pcidevice host=03:06.0 ... Failed to assign irq for "03:06.0": Operation not permitted Perhaps you are assigning a device that shares an IRQ with another device?(No IRQ sharing here).
After looking at the source I found this in
x86/kvm_main.c:assigned_device_update_intx():if (!capable(CAP_SYS_RAWIO)) return -EPERM;So basically it wants the user to have
SYS_RAWIOcapability to assign the irq. That's probably right, but it effectively makes the whole thing root-only, because capability system is broken on linux (it's another long topic, what's relevant here is that one can't grant any given capability to a given non-root process). Even if it were solved and a non-root hasSYS_RAWIO, it's better to drop that capability after all the init stuff is done, following the very good principle of least privilege (this is why I want to run it as non-root to start with; it's more: on a production system I'll restore permissions of the sysfs files after startup).
Quoted 4 lines
So it looks like some other trick is needed here (not
cap_sys_rawiobut some traditional unix rwx thing), OR kvm binary has to be able to drop privileges after all the init is done.
Dropping privileges is easy (well, need to account for all threads) but will not play well with hotplug.
Quoted 7 lines
The latter SEEMS to be easy as it only involves userspace (it's ok for me to start the whole thing as root as long as it drops privs, I don't need to give certain PCI devices to arbitrary users), but has its own issues. Namely, I'd like kvm to open disk image files and stuff like that as non-root too, since it's the only way to force read-only opens currently.
Looks like we need -drive ...,access=readonly
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 1 line · Avi Kivity
Michael Tokarev wrote:
[]
Quoted 5 lines
Quoted 5 lines
After looking at the source I found this in
x86/kvm_main.c:assigned_device_update_intx():if (!capable(CAP_SYS_RAWIO)) return -EPERM;
[]
Quoted 6 lines
Quoted 3 lines
So it looks like some other trick is needed here (not
cap_sys_rawiobut some traditional unix rwx thing), OR kvm binary has to be able to drop privileges after all the init is done.Dropping privileges is easy (well, need to account for all threads) but will not play well with hotplug.
It's either one or another for sure. Personally I use kvm as a sort of security tool, to run various untrusted stuff inside guests. For that, hotplug, while sometimes useful to have, isn't at all required, and if there's a choice between hotplug and stronger security I'll definitely prefer the latter. And sure thing having a choice is good in any case -- now there's just no choice.
But maybe there's some other option to achieve similar effect, i.e. to be able to open and initialize some (PCI/USB/network) at startup without keeping root (or various CAP_*) all the time?
Quoted 8 lines
Quoted 6 lines
The latter SEEMS to be easy as it only involves userspace (it's ok for me to start the whole thing as root as long as it drops privs, I don't need to give certain PCI devices to arbitrary users), but has its own issues. Namely, I'd like kvm to open disk image files and stuff like that as non-root too, since it's the only way to force read-only opens currently.
Looks like we need -drive ...,access=readonly
Yeah, that'd be good too.
Speaking of which, there's still a bug somewhere that causes a guest to hang in case it tries to write to a virtual drive open in read-only mode. It *is* a bug, because it's pretty normal for various real drives to be read-only (trivial example is write-protected floppy drive; many scsi drives has read-only flag which can be turned on/off using hdparm or sdparm), and with real drives on real hardware there's no hangs of this sort, the system correctly recognizes read-only media without hanging on an attempt to write.
Thanks!
/mjt