blob: 69eadcc4f0c705fe7e098a016b1638dc228b3212 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<think>
Okay, so I'm trying to figure out whether this QEMU bug is a user-mode issue or a system-mode one. Let me break down the information given.
The problem mentioned is that in QEMU's Linux-user mode, it doesn't check if a page has PROT_EXEC permissions before translating it. Instead, it only verifies if the page is readable. That could be an issue because not checking for execution permissions might lead to unexpected behavior when pages are supposed to be executable but aren't.
I know that in user-mode emulation, QEMU runs applications as regular users and doesn't have the same level of privilege as system-mode. System-mode usually deals with higher-privilege operations, like handling hardware devices or emulating an entire OS with kernel-level access.
The test case mentioned works across architectures but has been tested on x86_64 and aarch64. Since it's about page permissions during translation, which relates to how user processes interact with memory, this seems more related to the user space rather than system or hardware-level operations.
So, putting it all together, the issue is likely in the user-mode emulation part of QEMU because it's dealing with application-level memory permissions and not higher-privilege or device-related tasks.
</think>
user
|