[RFC PATCH v1 0/2] fix: don't add SELinux MCS categories to IOMMU device
Hi, This patchset proposes a fix for what I believe is a bug in libvirt when using iommufd under SELinux enforcing. It is an RFC because I cannot yet vouch for its correctness -- the goal is not to merge this code as is, but rather start a discussion on how we should go about things. When using iommufd, libvirt opens the vfio cdev corresponding to the device (e.g. /dev/vfio/devices/{n}) and the IOMMU device (/dev/iommu) and passes the file descriptors to qemu. The cdev is a device-specific resource, and thus a per-domain resource. The IOMMU on the other hand is a shared resource between all domains. Using the SELinux driver, libvirt relabels and assigns MCS categories to domain-specific devices to isolate from other domains. However, it also incorrectly assigns these categories to the IOMMU device. This can make subsequent domains unable to create DMA mappings. On my s390x host, I've repeatedly observed this problem showing up as PCI error events that show a DMA attempt to a non-present page. This problem is reproducible by running `setenforce 1` and then starting two domains, each with a PCI passthrough device using iommufd, and then performing actions that initiate PCI DMA transactions from within the guests. Launching qemu manually from the command-line does not produce these errors. There is also an additional cleanup problem that is not addressed in libvirt today, nor in my patches. When libvirt relabels a device, it doesn't restore the default label after the domain is destroyed. This is fine for the vfio cdevs, because they will disappear anyway as they get unbound from the vfio driver and rebind their default driver, but again is problematic for /dev/iommu because the inode is never unlinked. For example, the good state before starting a domain: root in ~/libvirt λ matchpathcon /dev/iommu /dev/iommu system_u:object_r:iommu_device_t:s0 root in ~/libvirt λ ls -Z /dev/iommu system_u:object_r:iommu_device_t:s0 /dev/iommu After starting and ending all domains (without my patches): root in ~/libvirt λ ls -Z /dev/iommu system_u:object_r:svirt_image_t:s0:c614,c980 /dev/iommu My patches remove the per-domain MCS categories (i.e., c614,c980) from the IOMMU, but they do NOT clean up the inode relabel. For the domain's lifetime, a relabel from iommu_device_t to svirt_image_t is correct. But I'm skeptical of whether we should clean that up at all when no domains are running, so that's another point I hope to get sorted out. I'd be happy to hear any feedback or thoughts on resolving this issue. If there's more questions or anyone needs more details, I'm available to answer those too. Thanks in advance. Omar Elghoul (2): security: add SetSharedImageFDLabel() for shared image FDs qemu: drop per-domain MCS categories from IOMMU device src/libvirt_private.syms | 1 + src/qemu/qemu_process.c | 4 +- src/qemu/qemu_security.h | 1 + src/security/security_apparmor.c | 1 + src/security/security_dac.c | 1 + src/security/security_driver.h | 4 ++ src/security/security_manager.c | 16 ++++++++ src/security/security_manager.h | 3 ++ src/security/security_nop.c | 1 + src/security/security_selinux.c | 63 ++++++++++++++++++++++++++++++++ src/security/security_stack.c | 18 +++++++++ 11 files changed, 111 insertions(+), 2 deletions(-) -- 2.55.0
On the SELinux driver, image FD labeling applies the domain imagelabel, which includes the per-domain MCS categories. This is correct behavior for exclusive resources, but not for host devices that are shared by multiple domains (e.g. an iommufd). Add virSecurityManagerSetSharedImageFDLabel() to address this issue. Reuse the imagelabel type in the SELinux driver, but strip the MCS categories so that the range is sensitivity-only. Preserve the pre- existing behavior in all other security drivers. Signed-off-by: Omar Elghoul <oelghoul@linux.ibm.com> --- src/libvirt_private.syms | 1 + src/security/security_apparmor.c | 1 + src/security/security_dac.c | 1 + src/security/security_driver.h | 4 ++ src/security/security_manager.c | 16 ++++++++ src/security/security_manager.h | 3 ++ src/security/security_nop.c | 1 + src/security/security_selinux.c | 63 ++++++++++++++++++++++++++++++++ src/security/security_stack.c | 18 +++++++++ 9 files changed, 108 insertions(+) diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index 6c6cc7b4ff..c67e808b13 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -1895,6 +1895,7 @@ virSecurityManagerSetChildProcessLabel; virSecurityManagerSetDaemonSocketLabel; virSecurityManagerSetHostdevLabel; virSecurityManagerSetImageFDLabel; +virSecurityManagerSetSharedImageFDLabel; virSecurityManagerSetImageLabel; virSecurityManagerSetInputLabel; virSecurityManagerSetMemoryLabel; diff --git a/src/security/security_apparmor.c b/src/security/security_apparmor.c index a66382fbac..5d292d7feb 100644 --- a/src/security/security_apparmor.c +++ b/src/security/security_apparmor.c @@ -1174,6 +1174,7 @@ virSecurityDriver virAppArmorSecurityDriver = { .domainRestoreSecurityNetdevLabel = AppArmorRestoreNetdevLabel, .domainSetSecurityImageFDLabel = AppArmorSetFDLabel, + .domainSetSecuritySharedImageFDLabel = AppArmorSetFDLabel, .domainSetSecurityTapFDLabel = AppArmorSetFDLabel, .domainGetSecurityMountOptions = AppArmorGetMountOptions, diff --git a/src/security/security_dac.c b/src/security/security_dac.c index e7cffa8e59..2da0af3336 100644 --- a/src/security/security_dac.c +++ b/src/security/security_dac.c @@ -2711,6 +2711,7 @@ virSecurityDriver virSecurityDriverDAC = { .domainRestoreSecurityHostdevLabel = virSecurityDACRestoreHostdevLabel, .domainSetSecurityImageFDLabel = virSecurityDACSetImageFDLabel, + .domainSetSecuritySharedImageFDLabel = virSecurityDACSetImageFDLabel, .domainSetSecurityTapFDLabel = virSecurityDACSetTapFDLabel, .domainGetSecurityMountOptions = virSecurityDACGetMountOptions, diff --git a/src/security/security_driver.h b/src/security/security_driver.h index b8c5b416e3..874e2f1d8e 100644 --- a/src/security/security_driver.h +++ b/src/security/security_driver.h @@ -107,6 +107,9 @@ typedef int (*virSecurityDomainSecurityVerify) (virSecurityManager *mgr, typedef int (*virSecurityDomainSetImageFDLabel) (virSecurityManager *mgr, virDomainDef *def, int fd); +typedef int (*virSecurityDomainSetSharedImageFDLabel) (virSecurityManager *mgr, + virDomainDef *def, + int fd); typedef int (*virSecurityDomainSetTapFDLabel) (virSecurityManager *mgr, virDomainDef *def, int fd); @@ -225,6 +228,7 @@ struct _virSecurityDriver { virSecurityDomainRestoreSavedStateLabel domainRestoreSavedStateLabel; virSecurityDomainSetImageFDLabel domainSetSecurityImageFDLabel; + virSecurityDomainSetSharedImageFDLabel domainSetSecuritySharedImageFDLabel; virSecurityDomainSetTapFDLabel domainSetSecurityTapFDLabel; virSecurityDomainGetMountOptions domainGetSecurityMountOptions; diff --git a/src/security/security_manager.c b/src/security/security_manager.c index bef9863799..baa6094f2e 100644 --- a/src/security/security_manager.c +++ b/src/security/security_manager.c @@ -977,6 +977,22 @@ virSecurityManagerSetImageFDLabel(virSecurityManager *mgr, } +int +virSecurityManagerSetSharedImageFDLabel(virSecurityManager *mgr, + virDomainDef *vm, + int fd) +{ + VIR_LOCK_GUARD lock = virObjectLockGuard(mgr); + + if (!mgr->drv->domainSetSecuritySharedImageFDLabel) { + virReportUnsupportedError(); + return -1; + } + + return mgr->drv->domainSetSecuritySharedImageFDLabel(mgr, vm, fd); +} + + int virSecurityManagerSetTapFDLabel(virSecurityManager *mgr, virDomainDef *vm, diff --git a/src/security/security_manager.h b/src/security/security_manager.h index 068ca4e290..0c1828a20d 100644 --- a/src/security/security_manager.h +++ b/src/security/security_manager.h @@ -156,6 +156,9 @@ int virSecurityManagerVerify(virSecurityManager *mgr, int virSecurityManagerSetImageFDLabel(virSecurityManager *mgr, virDomainDef *def, int fd); +int virSecurityManagerSetSharedImageFDLabel(virSecurityManager *mgr, + virDomainDef *def, + int fd); int virSecurityManagerSetTapFDLabel(virSecurityManager *mgr, virDomainDef *vm, int fd); diff --git a/src/security/security_nop.c b/src/security/security_nop.c index e6e337a49d..d918455acb 100644 --- a/src/security/security_nop.c +++ b/src/security/security_nop.c @@ -302,6 +302,7 @@ virSecurityDriver virSecurityDriverNop = { .domainRestoreSecurityHostdevLabel = virSecurityDomainRestoreHostdevLabelNop, .domainSetSecurityImageFDLabel = virSecurityDomainSetFDLabelNop, + .domainSetSecuritySharedImageFDLabel = virSecurityDomainSetFDLabelNop, .domainSetSecurityTapFDLabel = virSecurityDomainSetFDLabelNop, .domainGetSecurityMountOptions = virSecurityDomainGetMountOptionsNop, diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c index 423dcd0bd9..14e210000a 100644 --- a/src/security/security_selinux.c +++ b/src/security/security_selinux.c @@ -607,6 +607,50 @@ virSecuritySELinuxContextAddRange(const char *src, } +static char * +virSecuritySELinuxContextStripMCS(const char *label) +{ + g_autoptr(context_s_t) ctx = NULL; + g_autofree char *range = NULL; + const char *r; + const char *str; + char *tmp; + + if (!(ctx = context_new(label))) { + virReportSystemError(errno, + _("unable to parse SELinux context '%1$s'"), + label); + return NULL; + } + + r = context_range_get(ctx); + if (!r) + r = "s0"; + + range = g_strdup(r); + + if ((tmp = strchr(range, ':'))) + *tmp = '\0'; + if ((tmp = strchr(range, '-'))) + *tmp = '\0'; + + if (context_range_set(ctx, range) != 0) { + virReportSystemError(errno, + _("unable to set SELinux context rnge '%1$s'"), + range); + return NULL; + } + + if (!(str = context_str(ctx))) { + virReportSystemError(errno, "%s", + _("unable to format SELinux context")); + return NULL; + } + + return g_strdup(str); +} + + static char * virSecuritySELinuxContextSetFromFile(const char *origLabel, const char *binaryPath) @@ -3492,6 +3536,24 @@ virSecuritySELinuxSetImageFDLabel(virSecurityManager *mgr G_GNUC_UNUSED, return virSecuritySELinuxFSetFilecon(fd, secdef->imagelabel); } +static int +virSecuritySELinuxSetSharedImageFDLabel(virSecurityManager *mgr G_GNUC_UNUSED, + virDomainDef *def, + int fd) +{ + virSecurityLabelDef *secdef; + g_autofree char *label = NULL; + + secdef = virDomainDefGetSecurityLabelDef(def, SECURITY_SELINUX_NAME); + if (!secdef || !secdef->imagelabel) + return 0; + + if (!(label = virSecuritySELinuxContextStripMCS(secdef->imagelabel))) + return -1; + + return virSecuritySELinuxFSetFilecon(fd, label); +} + static int virSecuritySELinuxSetTapFDLabel(virSecurityManager *mgr, virDomainDef *def, @@ -3844,6 +3906,7 @@ virSecurityDriver virSecurityDriverSELinux = { .domainRestoreSavedStateLabel = virSecuritySELinuxRestoreSavedStateLabel, .domainSetSecurityImageFDLabel = virSecuritySELinuxSetImageFDLabel, + .domainSetSecuritySharedImageFDLabel = virSecuritySELinuxSetSharedImageFDLabel, .domainSetSecurityTapFDLabel = virSecuritySELinuxSetTapFDLabel, .domainGetSecurityMountOptions = virSecuritySELinuxGetSecurityMountOptions, diff --git a/src/security/security_stack.c b/src/security/security_stack.c index a55e94e764..e6dc64332e 100644 --- a/src/security/security_stack.c +++ b/src/security/security_stack.c @@ -590,6 +590,23 @@ virSecurityStackSetImageFDLabel(virSecurityManager *mgr, return rc; } +static int +virSecurityStackSetSharedImageFDLabel(virSecurityManager *mgr, + virDomainDef *vm, + int fd) +{ + virSecurityStackData *priv = virSecurityManagerGetPrivateData(mgr); + virSecurityStackItem *item = priv->itemsHead; + int rc = 0; + + for (; item; item = item->next) { + if (virSecurityManagerSetSharedImageFDLabel(item->securityManager, vm, fd) < 0) + rc = -1; + } + + return rc; +} + static int virSecurityStackSetTapFDLabel(virSecurityManager *mgr, virDomainDef *vm, @@ -1072,6 +1089,7 @@ virSecurityDriver virSecurityDriverStack = { .domainRestoreSavedStateLabel = virSecurityStackRestoreSavedStateLabel, .domainSetSecurityImageFDLabel = virSecurityStackSetImageFDLabel, + .domainSetSecuritySharedImageFDLabel = virSecurityStackSetSharedImageFDLabel, .domainSetSecurityTapFDLabel = virSecurityStackSetTapFDLabel, .domainGetSecurityMountOptions = virSecurityStackGetMountOptions, -- 2.55.0
The /dev/iommu device is shared between all domains. Relabeling it with qemuSecuritySetImageFDLabel() can incorrectly add one domain's MCS categories onto that inode, blocking other domains' access. Call qemuSecuritySetSharedImageFDLabel() instead when an iommufd is opened or inherited, which sets the desired labels while omitting the MCS categories. Signed-off-by: Omar Elghoul <oelghoul@linux.ibm.com> --- src/qemu/qemu_process.c | 4 ++-- src/qemu/qemu_security.h | 1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index b2506edce0..e085a50a33 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -7693,7 +7693,7 @@ qemuProcessOpenIommuFd(virDomainObj *vm) if ((iommufd = virIOMMUFDOpenDevice(priv->driver->privileged)) < 0) return -1; - if (qemuSecuritySetImageFDLabel(priv->driver->securityManager, vm->def, iommufd) < 0) + if (qemuSecuritySetSharedImageFDLabel(priv->driver->securityManager, vm->def, iommufd) < 0) return -1; priv->iommufd = qemuFDPassDirectNew("iommufd", &iommufd); @@ -7733,7 +7733,7 @@ qemuProcessGetPassedIommuFd(virDomainObj *vm) iommufd = dup(fdt->fds[0]); - if (qemuSecuritySetImageFDLabel(priv->driver->securityManager, vm->def, iommufd) < 0) + if (qemuSecuritySetSharedImageFDLabel(priv->driver->securityManager, vm->def, iommufd) < 0) return -1; priv->iommufd = qemuFDPassDirectNew("iommufd", &iommufd); diff --git a/src/qemu/qemu_security.h b/src/qemu/qemu_security.h index 36663cffde..882babf2e9 100644 --- a/src/qemu/qemu_security.h +++ b/src/qemu/qemu_security.h @@ -148,6 +148,7 @@ int qemuSecurityCommandRun(virQEMUDriver *driver, #define qemuSecuritySetChildProcessLabel virSecurityManagerSetChildProcessLabel #define qemuSecuritySetDaemonSocketLabel virSecurityManagerSetDaemonSocketLabel #define qemuSecuritySetImageFDLabel virSecurityManagerSetImageFDLabel +#define qemuSecuritySetSharedImageFDLabel virSecurityManagerSetSharedImageFDLabel #define qemuSecuritySetSavedStateLabel virSecurityManagerSetSavedStateLabel #define qemuSecuritySetSocketLabel virSecurityManagerSetSocketLabel #define qemuSecuritySetTapFDLabel virSecurityManagerSetTapFDLabel -- 2.55.0
On Tue, Aug 18, 2026 at 12:21:03PM -0400, Omar Elghoul wrote:
Hi,
This patchset proposes a fix for what I believe is a bug in libvirt when using iommufd under SELinux enforcing. It is an RFC because I cannot yet vouch for its correctness -- the goal is not to merge this code as is, but rather start a discussion on how we should go about things.
When using iommufd, libvirt opens the vfio cdev corresponding to the device (e.g. /dev/vfio/devices/{n}) and the IOMMU device (/dev/iommu) and passes the file descriptors to qemu. The cdev is a device-specific resource, and thus a per-domain resource. The IOMMU on the other hand is a shared resource between all domains.
Using the SELinux driver, libvirt relabels and assigns MCS categories to domain-specific devices to isolate from other domains. However, it also incorrectly assigns these categories to the IOMMU device. This can make subsequent domains unable to create DMA mappings. On my s390x host, I've repeatedly observed this problem showing up as PCI error events that show a DMA attempt to a non-present page.
This problem is reproducible by running `setenforce 1` and then starting two domains, each with a PCI passthrough device using iommufd, and then performing actions that initiate PCI DMA transactions from within the guests. Launching qemu manually from the command-line does not produce these errors.
There is also an additional cleanup problem that is not addressed in libvirt today, nor in my patches. When libvirt relabels a device, it doesn't restore the default label after the domain is destroyed. This is fine for the vfio cdevs, because they will disappear anyway as they get unbound from the vfio driver and rebind their default driver, but again is problematic for /dev/iommu because the inode is never unlinked.
For example, the good state before starting a domain:
root in ~/libvirt λ matchpathcon /dev/iommu /dev/iommu system_u:object_r:iommu_device_t:s0 root in ~/libvirt λ ls -Z /dev/iommu system_u:object_r:iommu_device_t:s0 /dev/iommu
After starting and ending all domains (without my patches):
root in ~/libvirt λ ls -Z /dev/iommu system_u:object_r:svirt_image_t:s0:c614,c980 /dev/iommu
My patches remove the per-domain MCS categories (i.e., c614,c980) from the IOMMU, but they do NOT clean up the inode relabel. For the domain's lifetime, a relabel from iommu_device_t to svirt_image_t is correct. But I'm skeptical of whether we should clean that up at all when no domains are running, so that's another point I hope to get sorted out.
I'd be happy to hear any feedback or thoughts on resolving this issue. If there's more questions or anyone needs more details, I'm available to answer those too.
It "makes sense" what libvirt does, or rather "why" it does it, but you are correct it is not correct. Sure, there are many ways this could get fixed, but what I immediately thought of was a completely different solution. I am also not sure what all the implications are and whether it is correct or not, but similarly to NFS, I feel like there could be a SELinux boolean (NFS access from virtual machines has virt_use_nfs) which would allow svirt_t to access ipmmu_device_t and with that we could stop labelling the /dev/iommu file. That would solve both of the reported issues. On the other hand, I must say I am not sure what else it would allow.
Thanks in advance.
Omar Elghoul (2): security: add SetSharedImageFDLabel() for shared image FDs qemu: drop per-domain MCS categories from IOMMU device
src/libvirt_private.syms | 1 + src/qemu/qemu_process.c | 4 +- src/qemu/qemu_security.h | 1 + src/security/security_apparmor.c | 1 + src/security/security_dac.c | 1 + src/security/security_driver.h | 4 ++ src/security/security_manager.c | 16 ++++++++ src/security/security_manager.h | 3 ++ src/security/security_nop.c | 1 + src/security/security_selinux.c | 63 ++++++++++++++++++++++++++++++++ src/security/security_stack.c | 18 +++++++++ 11 files changed, 111 insertions(+), 2 deletions(-)
-- 2.55.0
On 8/19/26 3:35 AM, Martin Kletzander via Devel wrote:
On Tue, Aug 18, 2026 at 12:21:03PM -0400, Omar Elghoul wrote:
Hi,
This patchset proposes a fix for what I believe is a bug in libvirt when using iommufd under SELinux enforcing. It is an RFC because I cannot yet vouch for its correctness -- the goal is not to merge this code as is, but rather start a discussion on how we should go about things.
When using iommufd, libvirt opens the vfio cdev corresponding to the device (e.g. /dev/vfio/devices/{n}) and the IOMMU device (/dev/iommu) and passes the file descriptors to qemu. The cdev is a device-specific resource, and thus a per-domain resource. The IOMMU on the other hand is a shared resource between all domains.
Using the SELinux driver, libvirt relabels and assigns MCS categories to domain-specific devices to isolate from other domains. However, it also incorrectly assigns these categories to the IOMMU device. This can make subsequent domains unable to create DMA mappings. On my s390x host, I've repeatedly observed this problem showing up as PCI error events that show a DMA attempt to a non-present page.
This problem is reproducible by running `setenforce 1` and then starting two domains, each with a PCI passthrough device using iommufd, and then performing actions that initiate PCI DMA transactions from within the guests. Launching qemu manually from the command-line does not produce these errors.
There is also an additional cleanup problem that is not addressed in libvirt today, nor in my patches. When libvirt relabels a device, it doesn't restore the default label after the domain is destroyed. This is fine for the vfio cdevs, because they will disappear anyway as they get unbound from the vfio driver and rebind their default driver, but again is problematic for /dev/iommu because the inode is never unlinked.
For example, the good state before starting a domain:
root in ~/libvirt λ matchpathcon /dev/iommu /dev/iommu system_u:object_r:iommu_device_t:s0 root in ~/libvirt λ ls -Z /dev/iommu system_u:object_r:iommu_device_t:s0 /dev/iommu
After starting and ending all domains (without my patches):
root in ~/libvirt λ ls -Z /dev/iommu system_u:object_r:svirt_image_t:s0:c614,c980 /dev/iommu
My patches remove the per-domain MCS categories (i.e., c614,c980) from the IOMMU, but they do NOT clean up the inode relabel. For the domain's lifetime, a relabel from iommu_device_t to svirt_image_t is correct. But I'm skeptical of whether we should clean that up at all when no domains are running, so that's another point I hope to get sorted out.
I'd be happy to hear any feedback or thoughts on resolving this issue. If there's more questions or anyone needs more details, I'm available to answer those too.
It "makes sense" what libvirt does, or rather "why" it does it, but you are correct it is not correct. Sure, there are many ways this could get fixed, but what I immediately thought of was a completely different solution. I am also not sure what all the implications are and whether it is correct or not, but similarly to NFS, I feel like there could be a SELinux boolean (NFS access from virtual machines has virt_use_nfs) which would allow svirt_t to access ipmmu_device_t and with that we could stop labelling the /dev/iommu file. That would solve both of the reported issues. On the other hand, I must say I am not sure what else it would allow.
I actually thought of this and did exactly that as an experiment to verify my hypothesis prior to writing up these patches. I tested it by making a SELinux module to override the default policy, letting svirt_t access iommu_device_t with the relevant syscalls/ioctls/etc. That said, I personally didn't like that approach because I feel like making a change to SELinux policy is much more likely to raise eyebrows, and rightfully so especially when it requires a libvirt change anyway to drop the relabeling. Not to mention the relabeling to svirt_image_t on its own makes sense and is consistent with how libvirt labels other devices. I also feel like this can potentially leave us with weird cases where qemu cannot access the IOMMU at all, e.g. on a system where the IOMMU doesn't have the iommu_device_t label at all by default and then libvirt doesn't add it. Thanks
Thanks in advance.
Omar Elghoul (2): security: add SetSharedImageFDLabel() for shared image FDs qemu: drop per-domain MCS categories from IOMMU device
src/libvirt_private.syms | 1 + src/qemu/qemu_process.c | 4 +- src/qemu/qemu_security.h | 1 + src/security/security_apparmor.c | 1 + src/security/security_dac.c | 1 + src/security/security_driver.h | 4 ++ src/security/security_manager.c | 16 ++++++++ src/security/security_manager.h | 3 ++ src/security/security_nop.c | 1 + src/security/security_selinux.c | 63 ++++++++++++++++++++++++++++++++ src/security/security_stack.c | 18 +++++++++ 11 files changed, 111 insertions(+), 2 deletions(-)
-- 2.55.0
On Wed, Aug 19, 2026 at 09:53:31AM -0400, Omar Elghoul wrote:
On 8/19/26 3:35 AM, Martin Kletzander via Devel wrote:
On Tue, Aug 18, 2026 at 12:21:03PM -0400, Omar Elghoul wrote:
Hi,
This patchset proposes a fix for what I believe is a bug in libvirt when using iommufd under SELinux enforcing. It is an RFC because I cannot yet vouch for its correctness -- the goal is not to merge this code as is, but rather start a discussion on how we should go about things.
When using iommufd, libvirt opens the vfio cdev corresponding to the device (e.g. /dev/vfio/devices/{n}) and the IOMMU device (/dev/iommu) and passes the file descriptors to qemu. The cdev is a device-specific resource, and thus a per-domain resource. The IOMMU on the other hand is a shared resource between all domains.
Using the SELinux driver, libvirt relabels and assigns MCS categories to domain-specific devices to isolate from other domains. However, it also incorrectly assigns these categories to the IOMMU device. This can make subsequent domains unable to create DMA mappings. On my s390x host, I've repeatedly observed this problem showing up as PCI error events that show a DMA attempt to a non-present page.
This problem is reproducible by running `setenforce 1` and then starting two domains, each with a PCI passthrough device using iommufd, and then performing actions that initiate PCI DMA transactions from within the guests. Launching qemu manually from the command-line does not produce these errors.
There is also an additional cleanup problem that is not addressed in libvirt today, nor in my patches. When libvirt relabels a device, it doesn't restore the default label after the domain is destroyed. This is fine for the vfio cdevs, because they will disappear anyway as they get unbound from the vfio driver and rebind their default driver, but again is problematic for /dev/iommu because the inode is never unlinked.
For example, the good state before starting a domain:
root in ~/libvirt λ matchpathcon /dev/iommu /dev/iommu system_u:object_r:iommu_device_t:s0 root in ~/libvirt λ ls -Z /dev/iommu system_u:object_r:iommu_device_t:s0 /dev/iommu
After starting and ending all domains (without my patches):
root in ~/libvirt λ ls -Z /dev/iommu system_u:object_r:svirt_image_t:s0:c614,c980 /dev/iommu
My patches remove the per-domain MCS categories (i.e., c614,c980) from the IOMMU, but they do NOT clean up the inode relabel. For the domain's lifetime, a relabel from iommu_device_t to svirt_image_t is correct. But I'm skeptical of whether we should clean that up at all when no domains are running, so that's another point I hope to get sorted out.
I'd be happy to hear any feedback or thoughts on resolving this issue. If there's more questions or anyone needs more details, I'm available to answer those too.
It "makes sense" what libvirt does, or rather "why" it does it, but you are correct it is not correct. Sure, there are many ways this could get fixed, but what I immediately thought of was a completely different solution. I am also not sure what all the implications are and whether it is correct or not, but similarly to NFS, I feel like there could be a SELinux boolean (NFS access from virtual machines has virt_use_nfs) which would allow svirt_t to access ipmmu_device_t and with that we could stop labelling the /dev/iommu file. That would solve both of the reported issues. On the other hand, I must say I am not sure what else it would allow.
I actually thought of this and did exactly that as an experiment to verify my hypothesis prior to writing up these patches. I tested it by making a SELinux module to override the default policy, letting svirt_t access iommu_device_t with the relevant syscalls/ioctls/etc.
That said, I personally didn't like that approach because I feel like making a change to SELinux policy is much more likely to raise eyebrows,
Which is not a bad thing, hopefully more people will chime in if that is needed.
and rightfully so especially when it requires a libvirt change anyway to drop the relabeling. Not to mention the relabeling to svirt_image_t on
Sure, but I'm sure we can check whether the SELinux boolean exists and behave based on that.
its own makes sense and is consistent with how libvirt labels other devices. I also feel like this can potentially leave us with weird cases where qemu cannot access the IOMMU at all, e.g. on a system where the IOMMU doesn't have the iommu_device_t label at all by default and then libvirt doesn't add it.
What we have currently is not only multiple VMs not being able to have a hostdev. But also other tools/programs that might require access might be cut off. This is yet another thing that would be fixed.
Thanks
Thanks in advance.
Omar Elghoul (2): security: add SetSharedImageFDLabel() for shared image FDs qemu: drop per-domain MCS categories from IOMMU device
src/libvirt_private.syms | 1 + src/qemu/qemu_process.c | 4 +- src/qemu/qemu_security.h | 1 + src/security/security_apparmor.c | 1 + src/security/security_dac.c | 1 + src/security/security_driver.h | 4 ++ src/security/security_manager.c | 16 ++++++++ src/security/security_manager.h | 3 ++ src/security/security_nop.c | 1 + src/security/security_selinux.c | 63 ++++++++++++++++++++++++++++++++ src/security/security_stack.c | 18 +++++++++ 11 files changed, 111 insertions(+), 2 deletions(-)
-- 2.55.0
On Fri, Aug 21, 2026 at 12:50:23PM +0200, Martin Kletzander via Devel wrote:
On Wed, Aug 19, 2026 at 09:53:31AM -0400, Omar Elghoul wrote:
On 8/19/26 3:35 AM, Martin Kletzander via Devel wrote:
On Tue, Aug 18, 2026 at 12:21:03PM -0400, Omar Elghoul wrote:
Hi,
This patchset proposes a fix for what I believe is a bug in libvirt when using iommufd under SELinux enforcing. It is an RFC because I cannot yet vouch for its correctness -- the goal is not to merge this code as is, but rather start a discussion on how we should go about things.
When using iommufd, libvirt opens the vfio cdev corresponding to the device (e.g. /dev/vfio/devices/{n}) and the IOMMU device (/dev/iommu) and passes the file descriptors to qemu. The cdev is a device-specific resource, and thus a per-domain resource. The IOMMU on the other hand is a shared resource between all domains.
Using the SELinux driver, libvirt relabels and assigns MCS categories to domain-specific devices to isolate from other domains. However, it also incorrectly assigns these categories to the IOMMU device. This can make subsequent domains unable to create DMA mappings. On my s390x host, I've repeatedly observed this problem showing up as PCI error events that show a DMA attempt to a non-present page.
This problem is reproducible by running `setenforce 1` and then starting two domains, each with a PCI passthrough device using iommufd, and then performing actions that initiate PCI DMA transactions from within the guests. Launching qemu manually from the command-line does not produce these errors.
There is also an additional cleanup problem that is not addressed in libvirt today, nor in my patches. When libvirt relabels a device, it doesn't restore the default label after the domain is destroyed. This is fine for the vfio cdevs, because they will disappear anyway as they get unbound from the vfio driver and rebind their default driver, but again is problematic for /dev/iommu because the inode is never unlinked.
For example, the good state before starting a domain:
root in ~/libvirt λ matchpathcon /dev/iommu /dev/iommu system_u:object_r:iommu_device_t:s0 root in ~/libvirt λ ls -Z /dev/iommu system_u:object_r:iommu_device_t:s0 /dev/iommu
After starting and ending all domains (without my patches):
root in ~/libvirt λ ls -Z /dev/iommu system_u:object_r:svirt_image_t:s0:c614,c980 /dev/iommu
My patches remove the per-domain MCS categories (i.e., c614,c980) from the IOMMU, but they do NOT clean up the inode relabel. For the domain's lifetime, a relabel from iommu_device_t to svirt_image_t is correct. But I'm skeptical of whether we should clean that up at all when no domains are running, so that's another point I hope to get sorted out.
I'd be happy to hear any feedback or thoughts on resolving this issue. If there's more questions or anyone needs more details, I'm available to answer those too.
It "makes sense" what libvirt does, or rather "why" it does it, but you are correct it is not correct. Sure, there are many ways this could get fixed, but what I immediately thought of was a completely different solution. I am also not sure what all the implications are and whether it is correct or not, but similarly to NFS, I feel like there could be a SELinux boolean (NFS access from virtual machines has virt_use_nfs) which would allow svirt_t to access ipmmu_device_t and with that we could stop labelling the /dev/iommu file. That would solve both of the reported issues. On the other hand, I must say I am not sure what else it would allow.
I actually thought of this and did exactly that as an experiment to verify my hypothesis prior to writing up these patches. I tested it by making a SELinux module to override the default policy, letting svirt_t access iommu_device_t with the relevant syscalls/ioctls/etc.
That said, I personally didn't like that approach because I feel like making a change to SELinux policy is much more likely to raise eyebrows,
Which is not a bad thing, hopefully more people will chime in if that is needed.
Hi, I've looked into this issue and IMHO we probably need to change SELinux policy and to the same as for `/dev/vfio/(vfio)?[0-9]*`.
and rightfully so especially when it requires a libvirt change anyway to drop the relabeling. Not to mention the relabeling to svirt_image_t on
Sure, but I'm sure we can check whether the SELinux boolean exists and behave based on that.
I don't think there is a need to introduce new boolean.
its own makes sense and is consistent with how libvirt labels other devices. I also feel like this can potentially leave us with weird cases where qemu cannot access the IOMMU at all, e.g. on a system where the IOMMU doesn't have the iommu_device_t label at all by default and then libvirt doesn't add it.
What we have currently is not only multiple VMs not being able to have a hostdev. But also other tools/programs that might require access might be cut off. This is yet another thing that would be fixed.
Agreed, and that's why I think we should update SELinux policy. Pavel
Thanks
Thanks in advance.
Omar Elghoul (2): security: add SetSharedImageFDLabel() for shared image FDs qemu: drop per-domain MCS categories from IOMMU device
src/libvirt_private.syms | 1 + src/qemu/qemu_process.c | 4 +- src/qemu/qemu_security.h | 1 + src/security/security_apparmor.c | 1 + src/security/security_dac.c | 1 + src/security/security_driver.h | 4 ++ src/security/security_manager.c | 16 ++++++++ src/security/security_manager.h | 3 ++ src/security/security_nop.c | 1 + src/security/security_selinux.c | 63 ++++++++++++++++++++++++++++++++ src/security/security_stack.c | 18 +++++++++ 11 files changed, 111 insertions(+), 2 deletions(-)
-- 2.55.0
On 8/24/26 5:55 AM, Pavel Hrdina via Devel wrote:
On Fri, Aug 21, 2026 at 12:50:23PM +0200, Martin Kletzander via Devel wrote:
On Wed, Aug 19, 2026 at 09:53:31AM -0400, Omar Elghoul wrote:
On 8/19/26 3:35 AM, Martin Kletzander via Devel wrote:
On Tue, Aug 18, 2026 at 12:21:03PM -0400, Omar Elghoul wrote:
Hi,
This patchset proposes a fix for what I believe is a bug in libvirt when using iommufd under SELinux enforcing. It is an RFC because I cannot yet vouch for its correctness -- the goal is not to merge this code as is, but rather start a discussion on how we should go about things.
When using iommufd, libvirt opens the vfio cdev corresponding to the device (e.g. /dev/vfio/devices/{n}) and the IOMMU device (/dev/iommu) and passes the file descriptors to qemu. The cdev is a device-specific resource, and thus a per-domain resource. The IOMMU on the other hand is a shared resource between all domains.
Using the SELinux driver, libvirt relabels and assigns MCS categories to domain-specific devices to isolate from other domains. However, it also incorrectly assigns these categories to the IOMMU device. This can make subsequent domains unable to create DMA mappings. On my s390x host, I've repeatedly observed this problem showing up as PCI error events that show a DMA attempt to a non-present page.
This problem is reproducible by running `setenforce 1` and then starting two domains, each with a PCI passthrough device using iommufd, and then performing actions that initiate PCI DMA transactions from within the guests. Launching qemu manually from the command-line does not produce these errors.
There is also an additional cleanup problem that is not addressed in libvirt today, nor in my patches. When libvirt relabels a device, it doesn't restore the default label after the domain is destroyed. This is fine for the vfio cdevs, because they will disappear anyway as they get unbound from the vfio driver and rebind their default driver, but again is problematic for /dev/iommu because the inode is never unlinked.
For example, the good state before starting a domain:
root in ~/libvirt λ matchpathcon /dev/iommu /dev/iommu system_u:object_r:iommu_device_t:s0 root in ~/libvirt λ ls -Z /dev/iommu system_u:object_r:iommu_device_t:s0 /dev/iommu
After starting and ending all domains (without my patches):
root in ~/libvirt λ ls -Z /dev/iommu system_u:object_r:svirt_image_t:s0:c614,c980 /dev/iommu
My patches remove the per-domain MCS categories (i.e., c614,c980) from the IOMMU, but they do NOT clean up the inode relabel. For the domain's lifetime, a relabel from iommu_device_t to svirt_image_t is correct. But I'm skeptical of whether we should clean that up at all when no domains are running, so that's another point I hope to get sorted out.
I'd be happy to hear any feedback or thoughts on resolving this issue. If there's more questions or anyone needs more details, I'm available to answer those too.
It "makes sense" what libvirt does, or rather "why" it does it, but you are correct it is not correct. Sure, there are many ways this could get fixed, but what I immediately thought of was a completely different solution. I am also not sure what all the implications are and whether it is correct or not, but similarly to NFS, I feel like there could be a SELinux boolean (NFS access from virtual machines has virt_use_nfs) which would allow svirt_t to access ipmmu_device_t and with that we could stop labelling the /dev/iommu file. That would solve both of the reported issues. On the other hand, I must say I am not sure what else it would allow.
I actually thought of this and did exactly that as an experiment to verify my hypothesis prior to writing up these patches. I tested it by making a SELinux module to override the default policy, letting svirt_t access iommu_device_t with the relevant syscalls/ioctls/etc.
That said, I personally didn't like that approach because I feel like making a change to SELinux policy is much more likely to raise eyebrows,
Which is not a bad thing, hopefully more people will chime in if that is needed.
Hi, I've looked into this issue and IMHO we probably need to change SELinux policy and to the same as for `/dev/vfio/(vfio)?[0-9]*`.
Changing the SELinux policy for the iommu device makes sense, but why would we need a change regarding the vfio cdevs if they're per-domain resources? Thanks
and rightfully so especially when it requires a libvirt change anyway to drop the relabeling. Not to mention the relabeling to svirt_image_t on
Sure, but I'm sure we can check whether the SELinux boolean exists and behave based on that.
I don't think there is a need to introduce new boolean.
its own makes sense and is consistent with how libvirt labels other devices. I also feel like this can potentially leave us with weird cases where qemu cannot access the IOMMU at all, e.g. on a system where the IOMMU doesn't have the iommu_device_t label at all by default and then libvirt doesn't add it.
What we have currently is not only multiple VMs not being able to have a hostdev. But also other tools/programs that might require access might be cut off. This is yet another thing that would be fixed.
Agreed, and that's why I think we should update SELinux policy.
Pavel
Thanks
Thanks in advance.
Omar Elghoul (2): security: add SetSharedImageFDLabel() for shared image FDs qemu: drop per-domain MCS categories from IOMMU device
src/libvirt_private.syms | 1 + src/qemu/qemu_process.c | 4 +- src/qemu/qemu_security.h | 1 + src/security/security_apparmor.c | 1 + src/security/security_dac.c | 1 + src/security/security_driver.h | 4 ++ src/security/security_manager.c | 16 ++++++++ src/security/security_manager.h | 3 ++ src/security/security_nop.c | 1 + src/security/security_selinux.c | 63 ++++++++++++++++++++++++++++++++ src/security/security_stack.c | 18 +++++++++ 11 files changed, 111 insertions(+), 2 deletions(-)
-- 2.55.0
On Mon, Aug 24, 2026 at 09:45:46AM -0400, Omar Elghoul wrote:
On 8/24/26 5:55 AM, Pavel Hrdina via Devel wrote:
On Fri, Aug 21, 2026 at 12:50:23PM +0200, Martin Kletzander via Devel wrote:
On Wed, Aug 19, 2026 at 09:53:31AM -0400, Omar Elghoul wrote:
On 8/19/26 3:35 AM, Martin Kletzander via Devel wrote:
On Tue, Aug 18, 2026 at 12:21:03PM -0400, Omar Elghoul wrote:
Hi,
This patchset proposes a fix for what I believe is a bug in libvirt when using iommufd under SELinux enforcing. It is an RFC because I cannot yet vouch for its correctness -- the goal is not to merge this code as is, but rather start a discussion on how we should go about things.
When using iommufd, libvirt opens the vfio cdev corresponding to the device (e.g. /dev/vfio/devices/{n}) and the IOMMU device (/dev/iommu) and passes the file descriptors to qemu. The cdev is a device-specific resource, and thus a per-domain resource. The IOMMU on the other hand is a shared resource between all domains.
Using the SELinux driver, libvirt relabels and assigns MCS categories to domain-specific devices to isolate from other domains. However, it also incorrectly assigns these categories to the IOMMU device. This can make subsequent domains unable to create DMA mappings. On my s390x host, I've repeatedly observed this problem showing up as PCI error events that show a DMA attempt to a non-present page.
This problem is reproducible by running `setenforce 1` and then starting two domains, each with a PCI passthrough device using iommufd, and then performing actions that initiate PCI DMA transactions from within the guests. Launching qemu manually from the command-line does not produce these errors.
There is also an additional cleanup problem that is not addressed in libvirt today, nor in my patches. When libvirt relabels a device, it doesn't restore the default label after the domain is destroyed. This is fine for the vfio cdevs, because they will disappear anyway as they get unbound from the vfio driver and rebind their default driver, but again is problematic for /dev/iommu because the inode is never unlinked.
For example, the good state before starting a domain:
root in ~/libvirt λ matchpathcon /dev/iommu /dev/iommu system_u:object_r:iommu_device_t:s0 root in ~/libvirt λ ls -Z /dev/iommu system_u:object_r:iommu_device_t:s0 /dev/iommu
After starting and ending all domains (without my patches):
root in ~/libvirt λ ls -Z /dev/iommu system_u:object_r:svirt_image_t:s0:c614,c980 /dev/iommu
My patches remove the per-domain MCS categories (i.e., c614,c980) from the IOMMU, but they do NOT clean up the inode relabel. For the domain's lifetime, a relabel from iommu_device_t to svirt_image_t is correct. But I'm skeptical of whether we should clean that up at all when no domains are running, so that's another point I hope to get sorted out.
I'd be happy to hear any feedback or thoughts on resolving this issue. If there's more questions or anyone needs more details, I'm available to answer those too.
It "makes sense" what libvirt does, or rather "why" it does it, but you are correct it is not correct. Sure, there are many ways this could get fixed, but what I immediately thought of was a completely different solution. I am also not sure what all the implications are and whether it is correct or not, but similarly to NFS, I feel like there could be a SELinux boolean (NFS access from virtual machines has virt_use_nfs) which would allow svirt_t to access ipmmu_device_t and with that we could stop labelling the /dev/iommu file. That would solve both of the reported issues. On the other hand, I must say I am not sure what else it would allow.
I actually thought of this and did exactly that as an experiment to verify my hypothesis prior to writing up these patches. I tested it by making a SELinux module to override the default policy, letting svirt_t access iommu_device_t with the relevant syscalls/ioctls/etc.
That said, I personally didn't like that approach because I feel like making a change to SELinux policy is much more likely to raise eyebrows,
Which is not a bad thing, hopefully more people will chime in if that is needed.
Hi, I've looked into this issue and IMHO we probably need to change SELinux policy and to the same as for `/dev/vfio/(vfio)?[0-9]*`.
Changing the SELinux policy for the iommu device makes sense, but why would we need a change regarding the vfio cdevs if they're per-domain resources?
There was a typo, it should have been `do the same as for...`. No need to change it for vfio, that is already part of SELinux policy, we just need to do the same for iommu. Pavel
Thanks
and rightfully so especially when it requires a libvirt change anyway to drop the relabeling. Not to mention the relabeling to svirt_image_t on
Sure, but I'm sure we can check whether the SELinux boolean exists and behave based on that.
I don't think there is a need to introduce new boolean.
its own makes sense and is consistent with how libvirt labels other devices. I also feel like this can potentially leave us with weird cases where qemu cannot access the IOMMU at all, e.g. on a system where the IOMMU doesn't have the iommu_device_t label at all by default and then libvirt doesn't add it.
What we have currently is not only multiple VMs not being able to have a hostdev. But also other tools/programs that might require access might be cut off. This is yet another thing that would be fixed.
Agreed, and that's why I think we should update SELinux policy.
Pavel
Thanks
Thanks in advance.
Omar Elghoul (2): security: add SetSharedImageFDLabel() for shared image FDs qemu: drop per-domain MCS categories from IOMMU device
src/libvirt_private.syms | 1 + src/qemu/qemu_process.c | 4 +- src/qemu/qemu_security.h | 1 + src/security/security_apparmor.c | 1 + src/security/security_dac.c | 1 + src/security/security_driver.h | 4 ++ src/security/security_manager.c | 16 ++++++++ src/security/security_manager.h | 3 ++ src/security/security_nop.c | 1 + src/security/security_selinux.c | 63 ++++++++++++++++++++++++++++++++ src/security/security_stack.c | 18 +++++++++ 11 files changed, 111 insertions(+), 2 deletions(-)
-- 2.55.0
On 8/24/26 9:51 AM, Pavel Hrdina wrote:
On Mon, Aug 24, 2026 at 09:45:46AM -0400, Omar Elghoul wrote:
On 8/24/26 5:55 AM, Pavel Hrdina via Devel wrote:
On Fri, Aug 21, 2026 at 12:50:23PM +0200, Martin Kletzander via Devel wrote:
On Wed, Aug 19, 2026 at 09:53:31AM -0400, Omar Elghoul wrote:
On 8/19/26 3:35 AM, Martin Kletzander via Devel wrote:
On Tue, Aug 18, 2026 at 12:21:03PM -0400, Omar Elghoul wrote: > Hi, > > This patchset proposes a fix for what I believe is a bug in libvirt when > using iommufd under SELinux enforcing. It is an RFC because I cannot yet > vouch for its correctness -- the goal is not to merge this code as is, > but rather start a discussion on how we should go about things. > > When using iommufd, libvirt opens the vfio cdev corresponding to the > device (e.g. /dev/vfio/devices/{n}) and the IOMMU device (/dev/iommu) > and passes the file descriptors to qemu. The cdev is a device-specific > resource, and thus a per-domain resource. The IOMMU on the other hand is > a shared resource between all domains. > > Using the SELinux driver, libvirt relabels and assigns MCS categories to > domain-specific devices to isolate from other domains. However, it also > incorrectly assigns these categories to the IOMMU device. This can make > subsequent domains unable to create DMA mappings. On my s390x host, I've > repeatedly observed this problem showing up as PCI error events that > show a DMA attempt to a non-present page. > > This problem is reproducible by running `setenforce 1` and then starting > two domains, each with a PCI passthrough device using iommufd, and then > performing actions that initiate PCI DMA transactions from within the > guests. Launching qemu manually from the command-line does not produce > these errors. > > There is also an additional cleanup problem that is not addressed in > libvirt today, nor in my patches. When libvirt relabels a device, it > doesn't restore the default label after the domain is destroyed. This is > fine for the vfio cdevs, because they will disappear anyway as they get > unbound from the vfio driver and rebind their default driver, but again > is problematic for /dev/iommu because the inode is never unlinked. > > For example, the good state before starting a domain: > > root in ~/libvirt λ matchpathcon /dev/iommu > /dev/iommu system_u:object_r:iommu_device_t:s0 > root in ~/libvirt λ ls -Z /dev/iommu > system_u:object_r:iommu_device_t:s0 /dev/iommu > > After starting and ending all domains (without my patches): > > root in ~/libvirt λ ls -Z /dev/iommu > system_u:object_r:svirt_image_t:s0:c614,c980 /dev/iommu > > My patches remove the per-domain MCS categories (i.e., c614,c980) from > the IOMMU, but they do NOT clean up the inode relabel. For the domain's > lifetime, a relabel from iommu_device_t to svirt_image_t is correct. But > I'm skeptical of whether we should clean that up at all when no domains > are running, so that's another point I hope to get sorted out. > > I'd be happy to hear any feedback or thoughts on resolving this issue. > If there's more questions or anyone needs more details, I'm available > to answer those too. >
It "makes sense" what libvirt does, or rather "why" it does it, but you are correct it is not correct. Sure, there are many ways this could get fixed, but what I immediately thought of was a completely different solution. I am also not sure what all the implications are and whether it is correct or not, but similarly to NFS, I feel like there could be a SELinux boolean (NFS access from virtual machines has virt_use_nfs) which would allow svirt_t to access ipmmu_device_t and with that we could stop labelling the /dev/iommu file. That would solve both of the reported issues. On the other hand, I must say I am not sure what else it would allow.
I actually thought of this and did exactly that as an experiment to verify my hypothesis prior to writing up these patches. I tested it by making a SELinux module to override the default policy, letting svirt_t access iommu_device_t with the relevant syscalls/ioctls/etc.
That said, I personally didn't like that approach because I feel like making a change to SELinux policy is much more likely to raise eyebrows,
Which is not a bad thing, hopefully more people will chime in if that is needed.
Hi, I've looked into this issue and IMHO we probably need to change SELinux policy and to the same as for `/dev/vfio/(vfio)?[0-9]*`.
Changing the SELinux policy for the iommu device makes sense, but why would we need a change regarding the vfio cdevs if they're per-domain resources?
There was a typo, it should have been `do the same as for...`. No need to change it for vfio, that is already part of SELinux policy, we just need to do the same for iommu.
Right, I should've inferred that much. I guess in that case, for the libvirt portion, should we simply leave the iommu label untouched or should we do something like what this RFC does?
Pavel
Thanks
and rightfully so especially when it requires a libvirt change anyway to drop the relabeling. Not to mention the relabeling to svirt_image_t on
Sure, but I'm sure we can check whether the SELinux boolean exists and behave based on that.
I don't think there is a need to introduce new boolean.
its own makes sense and is consistent with how libvirt labels other devices. I also feel like this can potentially leave us with weird cases where qemu cannot access the IOMMU at all, e.g. on a system where the IOMMU doesn't have the iommu_device_t label at all by default and then libvirt doesn't add it.
What we have currently is not only multiple VMs not being able to have a hostdev. But also other tools/programs that might require access might be cut off. This is yet another thing that would be fixed.
Agreed, and that's why I think we should update SELinux policy.
Pavel
Thanks
> Thanks in advance. > > Omar Elghoul (2): > security: add SetSharedImageFDLabel() for shared image FDs > qemu: drop per-domain MCS categories from IOMMU device > > src/libvirt_private.syms | 1 + > src/qemu/qemu_process.c | 4 +- > src/qemu/qemu_security.h | 1 + > src/security/security_apparmor.c | 1 + > src/security/security_dac.c | 1 + > src/security/security_driver.h | 4 ++ > src/security/security_manager.c | 16 ++++++++ > src/security/security_manager.h | 3 ++ > src/security/security_nop.c | 1 + > src/security/security_selinux.c | 63 ++++++++++++++++++++++++++++++++ > src/security/security_stack.c | 18 +++++++++ > 11 files changed, 111 insertions(+), 2 deletions(-) > > -- > 2.55.0 >
participants (3)
-
Martin Kletzander -
Omar Elghoul -
Pavel Hrdina