casaroli opened a new pull request, #19798: URL: https://github.com/apache/nuttx/pull/19798
## Summary A kernel build on the ESP32-S3 gave each process its own address environment, but it gave the unprivileged world no permissions. PMS was programmed only from `esp32s3_userspace.c`, which is built for a protected build alone, so a kernel build never programmed the split lines, never entered World 1, and never installed the monitor interrupt. A user process could read and write kernel memory, and could reach the registers that control the memory mapping. This adds the privilege boundary that a kernel build needs, on top of the address separation it already had. The world split moves out of `esp32s3_userspace.c` into `esp32s3_isolation.c`, which is built for any build that is not flat. `esp32s3_start()` programs the worlds and the permissions before `nx_start()`, so the unprivileged world has its vector table and its permissions before the first user process runs. An access that no MMU entry translates is now reported as well. The PMS grants and refuses physical addresses, so it never sees an untranslated access: the cache answered it with zeros and the task carried on with a value it never should have had. `EXTMEM_MMU_ENTRY_FAULT` is enabled and the Cache Invalid Access interrupt goes to the same handler. The handler reads the cause before it clears the latch, so the log separates the two: a PMS violation is a refused translation, an MMU entry fault is an access that was never translated. An unprivileged task that makes either access is terminated with SIGSEGV. A privileged one still panics. ## Impact A flat build does not change. A protected build keeps the same permissions; the code that sets them moved. A kernel build on the ESP32-S3 now isolates a user process, which it did not do before. ## Testing Board: ESP32-S3-DevKitC with an ESP32-S3-WROOM-2 N32R8V, 32 MB octal flash and 8 MB PSRAM. Host: macOS 15 on Apple Silicon, `xtensa-esp32s3-elf-gcc` 12.2.0. Configuration: `esp32s3-devkit:kernel_oct`. Every target of `examples/sandbox` carries the outcome it expects, so the test fails a build that refuses everything as well as one that permits everything. ``` sandbox: target self -- this process's own data, expecting success sandbox: PASS - the allowed access completed sandbox: target kernel -- kernel memory at 0x3fc98000, expecting a fault pms_violation_isr: SIGSEGV (PMS) task /system/bin/sandbox sandbox: PASS - the offending process was terminated sandbox: target periph -- a peripheral register at 0x600c5000, expecting a fault pms_violation_isr: SIGSEGV (PMS) task /system/bin/sandbox sandbox: PASS - the offending process was terminated sandbox: target unmapped -- an address with no mapping at 0x3d800000, expecting a fault pms_violation_isr: SIGSEGV (MMU entry) task /system/bin/sandbox sandbox: PASS - the offending process was terminated sandbox: CONTAINED - 4 target(s), every check passed ``` `0x600c5000` is `DR_REG_MMU_TABLE`, the registers that hold the mapping itself. The offending process holds 64 KiB of written memory and an open descriptor when it dies. ``` sandbox: memory 1441792 -> 2162688 -> 1441792 sandbox: PASS - 3 descriptor(s) open, none after ``` The count rises while the offender lives and returns to the same value after it is reaped. The test reports a failure if the count never rises, because a number that does not move proves nothing. The run was made three times, which is twelve process deaths, with the same result each time. `ostest` runs to the end on the same image. ``` vfork_test: Child 41 ran and exited before the parent resumed fork_test: Child running independently (child) fork_test: Parent and child had independent memory ostest_main: Exiting with status 0 ``` `tools/checkpatch.sh -c -u -m -g` reports no errors. depends-on: apache/nuttx-apps/pull/3721 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
