1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
<think>
Okay, so I need to figure out whether this QEMU bug is user-mode related or system-mode related. The user provided a detailed report where using the -runas option along with the -sandbox option causes QEMU to hang in futex after setgid. They also included some debug output showing process IDs and system calls like tgkill, nanosleep, setgid, futex, etc.
First, I remember that QEMU can run in two modes: user-mode and system-mode (also known as full virtualization). User-mode emulates the CPU instructions so the guest runs on top of the host's kernel. System-mode uses KVM to directly use hardware acceleration for better performance, which requires higher privileges because it interacts more deeply with the system.
Looking at the bug report, the issue occurs when using -runas and -sandbox together. The process is hanging after setgid(), which suggests something related to privilege dropping. In user-mode, QEMU runs as a regular application without needing kernel-level access beyond what's typical for an app. However, in system-mode with KVM, it might require more complex handling of privileges because it interacts with hardware and virtual devices.
The strace output shows the process trying to setgid but then getting stuck in a futex wait. Futexes are used for user-space concurrency primitives, so this seems like an issue within QEMU's own threading or synchronization. But why does combining -runas and -sandbox cause this?
I think about how -runas makes QEMU drop privileges after starting, which is more involved when running in a sandbox. The sandbox might restrict certain system calls that are needed for proper privilege dropping. In user-mode, maybe the seccomp filters aren't set up correctly to allow these operations, leading to hangs.
The link provided points to a discussion about adding syscalls for runas and chroot to the seccomp sandbox. That suggests that without allowing specific syscalls like setuid or setgid in the seccomp filter, QEMU can't perform them and thus hangs when it tries.
So considering all this, since the issue is about dropping privileges within a seccomp sandbox and involves user-space threading primitives (futex), I think this is more related to user-mode. The problem arises from how QEMU interacts with the host's user-space environment under these constraints rather than any direct interaction with kernel-level hardware or devices.
Therefore, the classification should be 'user'.
</think>
user
|