I'm working on a fix for a bug whereby apparmor permissions aren't
granted to allow a PCI SR-IOV virtual function to be used in a kvm guest
when the VF is defined via a forward type='hostdev' network (as per the
'hostdev' option documented here:
https://libvirt.org/formatnetwork.html#connectivity ).
Downstream bug here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993856
I'm not sure if the attached patches are sufficient. When I compare the
apparmor permissions file for a guest with a VF shared via forward
type='hostdev' vs. the same guest with a VF shared via a PCI hostdev
device, the latter has extra apparmor permissions for files like:
"/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/resource3_wc" rw,
"/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/resource0_wc" rw,
"/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/resource3" rw,
"/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/vendor" rw,
"/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/reset" rw,
"/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/resource" rw,
"/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/device" rw,
"/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/resource0" rw,
"/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/config" rw,
... however both guests appear to function in my test environment
(Debian 13, 6.12.22-amd64) - i.e. both with and without those entries.
So I don't know if those permissions are unneeded, or if they are
granted at runtime instead. If those permissions are needed, then I'd
appreciate any hints on how to modify virt-aa-helper to discover the PCI
address. I appreciate that might not actually be possible because that
is dynamically allocated, and so might race - so some other solution
might be required.
Many Thanks,
Tim.
Tim Small (2):
virt-aa-helper: refactor for readability
virt-aa-helper: Allow SR-IOV VF PCI for hostdev networks
.../apparmor/usr.lib.libvirt.virt-aa-helper.in | 3 +++
src/security/virt-aa-helper.c | 18 ++++++++++++++----
2 files changed, 17 insertions(+), 4 deletions(-)
--
2.47.2