On 1/16/2026 8:32 AM, Ján Tomko wrote:
On a Thursday in 2026, Pavel Hrdina via Devel wrote:
On Tue, Jan 06, 2026 at 06:49:37PM -0800, Nathan Chen via Devel wrote:
From: Nathan Chen <nathanc@nvidia.com>
When launching a qemu VM with the iommufd feature enabled for VFIO hostdevs: - Do not allow cgroup, namespace, and seclabel access to VFIO paths (/dev/vfio/vfio and /dev/vfio/<iommugroup>) - Allow access to iommufd paths (/dev/iommu and /dev/vfio/devices/vfio*) for AppArmor, SELinux, and DAC
Signed-off-by: Nathan Chen <nathanc@nvidia.com> --- src/qemu/qemu_cgroup.c | 26 +++++++------- src/qemu/qemu_namespace.c | 16 +++++---- src/security/security_apparmor.c | 32 +++++++++++++---- src/security/security_dac.c | 59 ++++++++++++++++++++++++++------ src/security/security_selinux.c | 57 ++++++++++++++++++++++++------ src/security/virt-aa-helper.c | 33 ++++++++++++++---- 6 files changed, 170 insertions(+), 53 deletions(-)
diff --git a/src/security/security_apparmor.c b/src/security/ security_apparmor.c index 68ac39611f..362ca09562 100644 --- a/src/security/security_apparmor.c +++ b/src/security/security_apparmor.c @@ -848,14 +848,32 @@ AppArmorSetSecurityHostdevLabel(virSecurityManager *mgr, goto done;
source.subsys.u.pci.addr, &vfiofdDev) < 0) + return -1;
if (pcisrc->driver.name == VIR_DEVICE_HOSTDEV_PCI_DRIVER_NAME_VFIO) { - char *vfioGroupDev = virPCIDeviceGetIOMMUGroupDev(pci); - - if (!vfioGroupDev) { - virPCIDeviceFree(pci); - goto done; + if (dev->source.subsys.u.pci.driver.iommufd != VIR_TRISTATE_BOOL_YES) { + char *vfioGroupDev = virPCIDeviceGetIOMMUGroupDev(pci); + + if (!vfioGroupDev) { + virPCIDeviceFree(pci); + goto done; + } + ret = AppArmorSetSecurityPCILabel(pci, vfioGroupDev, ptr); + VIR_FREE(vfioGroupDev); + } else { + g_autofree char *vfiofdDev = NULL; + + if (virPCIDeviceGetVfioPath(&dev- + + if (!virIOMMUFDSupported()) + return -1;
Move this check before we try to get vfio path as there is no need to construct the path if iommufd is not supported. We should also report error here, if virIOMMUFDSupported() fails it only sets errno.
I don't think we should get here at all without IOMMUFD being supported.
Per Pavel's suggestion to patch 4/7, moving the qemuProcessOpenVfioFds call to qemuProcessPrepareHost would mean we hit that function before attempting to set security labels.
I think we can remove virIOMMUFDSupported() altogether as it is only used in the security labeling changes. As you mention, if qemuProcessOpenVfioFds() gets called in qemuProcessPrepareHost(), it will call qemuProcessOpenIommuFd() which returns -1 if the open() call to /dev/iommu fails. Then we wouldn't reach the seclabel lines here. Nathan