On Wed, May 29, 2024 at 9:50 AM 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. > > In that case, I think we should ask the OP why they would like to access the TIME and TIMEH CSRs from userland. If I'm reading the original question correctly, it's to achieve a speed optimization. The relevant questions then are: (1) Why is an optimization needed here? (2) If code is calling timer_gettime() in a tight loop, causing a problem where the execution time is too long, then can the OP's software be re-architected to avoid doing this? Nathan
