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 <mpriv...@redhat.com>
---
 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 771a623ef7..86c058316f 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -2919,6 +2919,9 @@ qemuProcessStartManagedPRDaemon(virDomainObj *vm)
      * qemu (so that it shares the same view of the system). */
     virCommandSetPreExecHook(cmd, qemuProcessStartPRDaemonHook, vm);
 
+    if (cfg->schedCore == QEMU_SCHED_CORE_FULL && vm->pid != 0)
+        virCommandSetRunAmong(cmd, vm->pid);
+
     if (virCommandRun(cmd, NULL) < 0)
         goto cleanup;
 
@@ -7634,6 +7637,8 @@ qemuProcessLaunch(virConnectPtr conn,
         virCommandSetMaxProcesses(cmd, cfg->maxProcesses);
     if (cfg->maxFiles > 0)
         virCommandSetMaxFiles(cmd, cfg->maxFiles);
+    if (cfg->schedCore != QEMU_SCHED_CORE_NONE)
+        virCommandSetRunAlone(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..badb8fc8ba 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 == QEMU_SCHED_CORE_FULL && vm->pid != 0)
+        virCommandSetRunAmong(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 2fd4b9f987..faf8fedc0c 100644
--- a/src/qemu/qemu_virtiofs.c
+++ b/src/qemu/qemu_virtiofs.c
@@ -252,6 +252,9 @@ qemuVirtioFSStart(virQEMUDriver *driver,
     virCommandNonblockingFDs(cmd);
     virCommandDaemonize(cmd);
 
+    if (cfg->schedCore == QEMU_SCHED_CORE_FULL && vm->pid != 0)
+        virCommandSetRunAmong(cmd, vm->pid);
+
     if (qemuExtDeviceLogCommand(driver, vm, cmd, "virtiofsd") < 0)
         goto error;
 
-- 
2.35.1

Reply via email to