I'll provide a bit of background on our configuration, as I've understandably caused some confusion.
We configure NuttX with CONFIG_BUILD_KERNEL, so we have a kernel with device drivers, and a set of userspace applications. The MMU for Litex is configured so kernel pages are only accessible while the core is in supervisor mode, user pages are accessible when the core is in usermode. It is not my intention to access, modify or read memory which belongs to, or is managed by the kernel. The CSRs I'm referring to are available in usermode, see section 2.2 of https://riscv.org/wp-content/uploads/2017/05/riscv-privileged-v1.10.pdf, and are currently used and defined in NuttX. Note that this is a CSR provided by the risc-v core, not a memory mapped peripheral or region. My original query was on providing a way to have a different proxy for a syscall. From what I understand, these are only generated by tools/mksyscall at build time, based on the information provided in syscall.csv. Sorry if I caused any misunderstanding. On Wed, 29 May 2024 at 23:50, Gregory Nutt <spudan...@gmail.com> wrote: > On 5/29/2024 6:10 AM, Nathan Hartman wrote: > > That's a security hole in the *hardware*, not in software, right? How can > > that be fixed (unless a new chip is made)? > > No, software. > > Disclaimer: I don't do RISC-V but I do understand ARM and MIPS MMUs > well. I have never looked at the RISC-V MMU management code. > > * If the MMU is enabled then in order to access any memory region, it > must be mapped by the MMU. Otherwise, you will get a segmentation > fault. > * When the memory region is mapped, access to the memory region is > then controlled by settings in the MMU mapping for that region. > This includes things like protections, cacheability, etc. > * The MMU must be set up by software as part of the power-on > initialization and process initialization (and perhaps later after a > page fault or sbrk). This includes setting of the memory region > protections. > * In order to permit user access to a memory region, the MMU must be > programmed to allow user space access to a memory region. Otherwise > attempts to access that region results in a segmentation fault. > > So it is software that determines what applications can access in user > mode code. > > In a secure system, all kernel resources must be setup to allow only > supervisor mode access. User code must be isolated; it must be > restricted so that it can only access memory in its process sandbox. > This prevents many types of attacks on system from any hostile code. > > The fix is relatively simple (if the description of the issue is > correct). In all places where kernel-only accessible memory is mapped by > the MMU, the protection bits must be set so that user space access is > prohibited. This might have side effects on any existing applications > that access kernel memory resources. > > -- *Kind regards,* *Stuart Ianna* *Firmware Engineer* -- *MoTeC Pty Ltd* 121 Merrindale Drive Croydon South 3136 Victoria Australia *T: *61 3 9761 5050 *W: *www.motec.com.au <https://www.motec.com.au/> -- <http://www.facebook.com/motec.global> <http://www.youtube.com/user/MoTeCAustralia> <https://www.instagram.com/motec_global/> <https://www.linkedin.com/company/motec-global> -- <https://www.thebatteryshow.eu/en/home.html> -- Disclaimer Notice: This message, including any attachments, contains confidential information intended for a specific individual and purpose and is protected by law. If you are not the intended recipient you should delete this message. Any disclosure, copying, or distribution of this message or the taking of any action based on it is strictly prohibited.
