[PATCH RFC 09/10] qemu: Enable SCHED_CORE for domains and helper processes

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

 



Despite all mitigations, side channel attacks when two processes
run at two Hyper Threads of the same core are still possible.
Fortunately, the Linux kernel came up with a solution: userspace
can create so called trusted groups, which are sets of processes
and only processes of the same group can run on sibling Hyper
Threads. Of course, two processes of different groups can run on
different cores, because there's no known side channel attack.
It's only Hyper Threads that are affected.

Having said that, it's a clear security win for users when
enabled for QEMU.

Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
---
 src/qemu/qemu_process.c  | 5 +++++
 src/qemu/qemu_security.c | 4 ++++
 src/qemu/qemu_virtiofs.c | 3 +++
 3 files changed, 12 insertions(+)

diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index b0b00eb0a2..0a49008124 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -2923,6 +2923,9 @@ qemuProcessStartManagedPRDaemon(virDomainObj *vm)
      * qemu (so that it shares the same view of the system). */
     virCommandSetPreExecHook(cmd, qemuProcessStartPRDaemonHook, vm);
 
+    if (cfg->schedCore && vm->pid != -1)
+        virCommandRunAmong(cmd, vm->pid);
+
     if (virCommandRun(cmd, NULL) < 0)
         goto cleanup;
 
@@ -7472,6 +7475,8 @@ qemuProcessLaunch(virConnectPtr conn,
         virCommandSetMaxProcesses(cmd, cfg->maxProcesses);
     if (cfg->maxFiles > 0)
         virCommandSetMaxFiles(cmd, cfg->maxFiles);
+    if (cfg->schedCore)
+        virCommandRunAlone(cmd);
 
     /* In this case, however, zero means that core dumps should be
      * disabled, and so we always need to set the limit explicitly */
diff --git a/src/qemu/qemu_security.c b/src/qemu/qemu_security.c
index 3be1766764..0fe1555406 100644
--- a/src/qemu/qemu_security.c
+++ b/src/qemu/qemu_security.c
@@ -683,6 +683,8 @@ qemuSecurityCommandRun(virQEMUDriver *driver,
                        int *exitstatus,
                        int *cmdret)
 {
+    g_autoptr(virQEMUDriverConfig) cfg = virQEMUDriverGetConfig(driver);
+
     if (virSecurityManagerSetChildProcessLabel(driver->securityManager,
                                                vm->def, cmd) < 0)
         return -1;
@@ -691,6 +693,8 @@ qemuSecurityCommandRun(virQEMUDriver *driver,
         virCommandSetUID(cmd, uid);
     if (gid != (gid_t) -1)
         virCommandSetGID(cmd, gid);
+    if (cfg->schedCore && vm->pid != -1)
+        virCommandRunAmong(cmd, vm->pid);
 
     if (virSecurityManagerPreFork(driver->securityManager) < 0)
         return -1;
diff --git a/src/qemu/qemu_virtiofs.c b/src/qemu/qemu_virtiofs.c
index b3a2d2990a..0a3548065f 100644
--- a/src/qemu/qemu_virtiofs.c
+++ b/src/qemu/qemu_virtiofs.c
@@ -248,6 +248,9 @@ qemuVirtioFSStart(virQEMUDriver *driver,
     virCommandNonblockingFDs(cmd);
     virCommandDaemonize(cmd);
 
+    if (cfg->schedCore && vm->pid != -1)
+        virCommandRunAmong(cmd, vm->pid);
+
     if (qemuExtDeviceLogCommand(driver, vm, cmd, "virtiofsd") < 0)
         goto error;
 
-- 
2.35.1




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux