[PATCH v2 8/9] qemu: Enable SCHED_CORE for domains and helper processes
Daniel P. Berrangé
berrange at redhat.com
Wed Jul 13 17:25:00 UTC 2022
On Mon, Jun 27, 2022 at 12:44:40PM +0200, Michal Privoznik wrote:
> 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.
The next patch deals with helper processes too. I guess the
difference in this patch is that it deals with helper processes
spawned /after/ QEMU, so they can inherit scheduling group at
startup easily, while the next patch has to apply the group
later in startup ?
>
> Having said that, it's a clear security win for users when
> enabled for QEMU.
>
> Signed-off-by: Michal Privoznik <mprivozn at 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
>
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
More information about the libvir-list
mailing list