1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
<think>
Okay, so I'm trying to classify this bug report as part of QEMU. The user mentioned that when using execveat with an empty filename and AT_EMPTY_PATH flag on different architectures like arm64, arm, riscv64, etc., it returns ENOENT (No such file or directory). However, for x86_64 and x86, it works fine.
First, I need to understand what's happening here. execveat is a system call that allows executing a program from a file descriptor. The AT_EMPTY_PATH flag tells the kernel that the filename is empty, meaning the path comes from the file descriptor provided. On some architectures, this isn't working as expected.
The user also mentioned using binfmt_misc which is used to register interpreters for different binary formats (like QEMU for running foreign binaries). When binfmt_misc is enabled, it allows these foreign binaries to run by translating them on-the-fly.
Looking at the test cases:
- For x86_64 and x86, everything works fine when using execveat with AT_EMPTY_PATH.
- For other architectures (aarch64, riscv64), it fails with ENOENT when using AT_EMPTY_PATH but works if they use /proc/self/fd/%d as the pathname.
The error seems to be happening in how the system call is handled for different architectures. Since execveat is a syscall and this behavior varies across architectures, especially when using QEMU's binfmt_misc setup, it points towards an issue with how the system handles foreign binaries or specific syscalls under QEMU.
The possible categories given are instruction, syscall, runtime. The problem here isn't about faulty instructions in the code (so not 'instruction'). It also doesn't seem to be a general runtime error unrelated to system calls. Instead, it's specifically about the execveat system call failing under certain conditions when running different architectures with QEMU.
Therefore, this bug falls under the 'syscall' category because it's related to how the execveat system call is being handled or emulated by QEMU for foreign architectures.
</think>
The issue arises from how the `execveat` system call is being processed for different architectures within QEMU. The error occurs specifically when using this syscall with an empty path and AT_EMPTY_PATH flag, which works for some arches but not others. This indicates a problem in handling syscalls across various architectures.
**Answer:** syscall
|