[QUERY]: Block region to mmap

["Lad, Prabhakar" <prabhakar.csengg@gmail.com>]

Hi All,

Renesas RZ/Five RISC-V SoC has Instruction local memory and Data local
memory (ILM & DLM) mapped between region 0x30000 - 0x4FFFF. When a
virtual address falls within this range, the MMU doesn't trigger a
page fault; it assumes the virtual address is a physical address which
can cause undesired behaviours.

To avoid this the ILM/DLM memory regions are now added to the root
domain region of the PMPU with permissions set to 0x0 for S/U modes so
that any access to these regions gets blocked and for M-mode we grant
full access (R/W/X). This prevents any users from accessing these
regions by triggering an unhandled signal 11 in S/U modes.

This works as expected but for applications say for example when doing
mmap to this region would still succeed and later down the path when
doing a read/write to this location would cause unhandled signal 11.
To handle this case gracefully we might want mmap() itself to fail if
the addr/offset falls in this local memory region.

Tracing through the mmap call we have arch_mmap_check() if implemented
by architectures this callback gets called and it can be used as a
validator to make sure mmap() to the local memory region fails. (Note
maybe this callback can be implemented using ALTERNATIVX() macro so
that other RISC-V SoCs do nop() to this callback). This approach seems
reasonable but isn't a generic approach. For other platforms with
similar issues will have to go through similar implementation. Instead
if we define the memory regions in the device tree that aren't to be
allowed to be mmaped with this approach the implementation can be
generic and can be used on other archs/platforms.

Looking at the kernel code SPARC architecture (UltraSPARC T1) also has
a hole in the virtual memory address space (relevant commit-id to fix
this issue 8bcd17411643beb9a601e032d0cf1016909a81d3).
As this VA hole “support” has been added a long time ago now, and
maybe simply replicating their approach is not acceptable anymore
hence the proposed approach.

Is there any better approach which I am missing, any pointers comments welcome.

Cheers,
Prabhakar