blob: 76334dc92f39299a2f15359da345a2f38a3b1f9b (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Alright, so I'm trying to classify this bug report as either 'user-mode' or 'system-mode'. Let's see what the issue is about.
The problem occurs when using `*-linux-user` as binfmt_misc. That immediately tells me it's related to user-mode emulation because that's what `-linux-user` binaries are used for—emulating a different architecture in user space without full system virtualization.
Looking at the steps to reproduce, they involve setting up QEMU with the `--credential` flag, which enables open-binary mode. The issue arises when file descriptor 0 is closed before running the executable. It seems that QEMU isn't correctly handling AT_EXECFD when it's set to 0, leading to unexpected behavior where the executable ends up as stdin.
The user mentions that in native execution, closing stdin results in an error about a bad file descriptor. But with QEMU, the executable itself is read from stdin instead. This suggests a problem in how QEMU handles auxv values and file descriptors during process startup in user-mode.
They also refer to specific lines in `linux-user/main.c`, indicating that this issue is within the user-mode code where QEMU loads the binary and sets up file descriptors. The discussion about modifying `qemu_getauxval` to correctly distinguish between AT_EXECFD not found and being zero further points towards an issue in how auxiliary values are handled during user-mode execution.
Since all these components—binfmt_misc setup, handling of auxv, and file descriptor management—are part of the user-mode emulation within QEMU, this bug is definitely related to user-mode. There's no mention of system-level issues like device emulation or higher privileges, which would point towards system-mode.
</think>
user
|