blob: c00c58789786dff470c8c6543163a73a0e1e76b1 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, so I'm trying to figure out whether this bug report is about user-mode or system-mode in QEMU. Let me start by reading the problem description carefully.
The issue mentions that the PACIASP instruction isn't acting as a BTI landing pad correctly when SCTLR_EL1.BT0 is set. It talks about how Linux sets this bit and expects QEMU-user to do so too. The sample program provided crashes with SIGILL if everything's working, otherwise it segfaults.
Looking at the code, they're using mmap and mprotect to create executable pages. They're copying a function into a mapped page and setting PROT_BTI on it. Then there's an assembly block that moves pointers into registers and uses blr (branch link register) to jump to this function via a shim. The expectation is that when the PACIASP is hit, it should trigger an illegal instruction (SIGILL), but if not handled correctly, it crashes with SIGSEGV.
Now, thinking about QEMU's modes: user-mode emulation runs unprivileged code and doesn't handle system calls directly in the same way as system-mode. Here, the issue seems to be about how user-space instructions are being emulated—specifically, handling PACIASP and branch target identification (BTI) correctly.
The bug report mentions that Linux sets SCTLR_EL1.BT0, which is a CPU register controlling BTI. QEMU's user mode should emulate this behavior accurately. The problem arises because the emulator isn't setting this bit correctly when it should be in user mode, leading to incorrect handling of the PACIASP instruction.
Since the issue pertains to how user-space code is being executed and how certain CPU registers are configured during emulation, it falls under user-mode. It's not about higher-privilege operations or system-level components like devices or peripherals, which would be more in line with system-mode issues.
Therefore, this bug is related to user-mode in QEMU.
</think>
user
|