mirror of
https://github.com/apache/nuttx.git
synced 2026-10-16 18:49:05 +00:00
f17c74c626
Two problems in the same path make a contained user fault look like a kernel failure. arm64_el1_undef() dumps the words around ELR. For an exception taken from EL0, ELR is a user address, and the words around it can be in a page that is not mapped. Then the memcpy faults inside the fatal handler. That nested exception trips the DEBUGASSERT in arm64_fatal_handler(), and the fault that the user took is not reported. The ESR that tells what happened is lost. Skip the dump when the exception came from EL0. At EL1 the address is kernel code that was just fetched, so keep the dump there. arm64_fatal_handler() then reports the fault that it recovers from as "PANIC: Unhandled user exception", followed by a full register dump. But there is no panic: it sets TCB_FLAG_FORCED_CANCEL, changes ELR to _exit(SIGSEGV), and the system continues without the offending task. Print "Segmentation fault in <process> (PID n: <thread>)" instead, the same message as risc-v, and keep the register dump for the PANIC_WITH_REGS() path, which is fatal. Tested on QEMU qemu-armv8a:knsh with examples/sandbox and ostest. A user read or write of kernel memory (0x40000000) now prints: arm64_exception_handler: ESR_ELn: 0x9200000e arm64_fatal_handler: Segmentation fault in sandbox (PID 10: sandbox) arm64_fatal_handler: Reason: DABT (lower EL) - Data Abort from a ... sandbox: the offender exited with status 2816 Before this change it printed "PANIC: Unhandled user exception" and a register dump for the same recovered fault. An undefined instruction at EL0 now prints "Undefined instruction at <ELR>" without the dump, then the same segmentation fault message. The shell survives in all cases, and ostest exits with status 0 before and after this change. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com> |
||
|---|---|---|
| .. | ||
| include | ||
| src | ||
| CMakeLists.txt | ||
| Kconfig | ||