patacongo commented on issue #1329: URL: https://github.com/apache/nuttx/issues/1329#issuecomment-6276535763
Yes, certainly we must never use pointers from user space within the kernel. Nor should be ever attempt access other user stuff in the kernel like semaphores, file descriptors, anything that is specific to a task group. It won't work in kernel mode That would be the moral equivalent of accessing user process data directly directly in the Linux kernel (without going through any special Linux user space access functions. This id because a context switch can occur at any time making the user data inaccessible or worse. The typical fix is to move things like user data, semaphores, etc. into TLS and not carry them inside the kernel. TLS resides in the task group user space and doesn't cause a problems like this. ________________________________ From: Marco Casaroli ***@***.***> Sent: Monday, October 19, 2026 11:08 AM To: apache/nuttx ***@***.***> Cc: patacongo ***@***.***>; Author ***@***.***> Subject: Re: [apache/nuttx] System calls require address checks (#1329) [https://avatars.githubusercontent.com/u/3879784?s=20&v=4]casaroli left a comment (apache/nuttx#1329)<https://github.com/apache/nuttx/issues/1329#issuecomment-6272780607> I reviewed and tested the four open PRs of @royzah<https://github.com/royzah> that address this issue, and I want to keep the points that concern all of them in one place. PR What it does State #20412<https://github.com/apache/nuttx/pull/20412> Helpers that refuse kernel addresses from user space in a kernel build (uaccess_ok(), uaccess_check(), uaccess_fault()), page-table walkers for riscv and x86_64 Open; nothing calls the checks yet, the others use them #20418<https://github.com/apache/nuttx/pull/20418> Copies in the ioctls and calls that carry user pointers, and refuses kernel pointers Draft, on top of #20412<https://github.com/apache/nuttx/pull/20412> #20415<https://github.com/apache/nuttx/pull/20415> Keeps user semaphores in the kernel Draft, on top of #20412<https://github.com/apache/nuttx/pull/20412> #20425<https://github.com/apache/nuttx/pull/20425> Signalling or rescheduling another process needs PR_CAP_ADMIN Draft; independent of #20412<https://github.com/apache/nuttx/pull/20412> (#20417<https://github.com/apache/nuttx/pull/20417> is merged) All four rebase cleanly on master (<https://github.com/apache/nuttx/commit/c7cba680a10a735317bb2cddb6a12914a55e8d58> c7cba68<https://github.com/apache/nuttx/commit/c7cba680a10a735317bb2cddb6a12914a55e8d58> ), build, and pass ostest on qemu-armv8a:knsh and :nsh. My reviews: #20412 (review)<https://github.com/apache/nuttx/pull/20412#pullrequestreview-5575023201>, #20418 (review)<https://github.com/apache/nuttx/pull/20418#pullrequestreview-5575023672>, #20415 (review)<https://github.com/apache/nuttx/pull/20415#pullrequestreview-5575024174>, #20425 (review)<https://github.com/apache/nuttx/pull/20425#pullrequestreview-5575024560>. Merge order. #20412<https://github.com/apache/nuttx/pull/20412> first: it is the base and it is closest to merge. Then #20418<https://github.com/apache/nuttx/pull/20418> and #20415<https://github.com/apache/nuttx/pull/20415>, each as one commit on top of it. #20425<https://github.com/apache/nuttx/pull/20425> can go at any time. Open design point. #20418<https://github.com/apache/nuttx/pull/20418> (and #20415<https://github.com/apache/nuttx/pull/20415>) still generate per-call checks in tools/mksyscall.c, which xiaoxiang asked to keep out of the general stub/proxy creator in the #20412<https://github.com/apache/nuttx/pull/20412> review. #20425<https://github.com/apache/nuttx/pull/20425> puts its checks into the functions instead. Can we agree on one place before the next round? Gap that none of the four closes yet. The checks accept any address inside the user window, also an address that is not mapped. Then the kernel faults on it at EL1, and on arm64 a kernel fault is a panic. So any program in a kernel build can stop the system: read(fd, (void *)0xF0000000, 1); /* in the user window, not mapped */ On master, and with all four PRs, this panics the kernel (arm64_fatal.c:696). A kernel pointer (0x1000) is refused with #20418<https://github.com/apache/nuttx/pull/20418>, which is good. To close the gap, the kernel must recover from a fault on a user address during a system call: either a fixup table for the user-access code (as copy_from_user() does on Linux), or a rule that a fault at EL1 on a user address in a system call ends the caller instead of the system. Small, older point. ARCH_ADDRENV_VEND and ARCH_SHM_VEND are inclusive, but arm64_uservaddr(), riscv_uservaddr(), the armv7-a copy and the new x86_64 up_addrenv_user_vaddr() test vaddr < VEND, so the last byte of each window counts as "not user". It is older than these PRs; a small separate cleanup would fix it. I am happy to test new versions. — Reply to this email directly, view it on GitHub<https://github.com/apache/nuttx/issues/1329?email_source=notifications&email_token=ABFUG6RYQJGOY33MM43CZ5L5UZDADA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMRXGI3TQMBWGA32M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-6272780607>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABFUG6WY2WKE5BHI3RURIQD5UZDADAVCNFSNUABEKJSXA33TNF2G64TZHMZDEOBRGAZTENZTHNEXG43VMU5TMNBXGY4DMMBZGCQXMAQ>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/ABFUG6UUPN6SUMKKIOEVCEL5UZDADA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMRXGI3TQMBWGA32M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android<https://github.com/notifications/mobile/android/ABFUG6T5DIJCVKRLDTVFIE35UZDADA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMRXGI3TQMBWGA32M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***> -- 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]
