On Fri, 5 Jul 2024 at 04:25, Will Deacon <will@xxxxxxxxxx> wrote: > > we'd probably want to use an address that lives between the two TTBRs > (i.e. in the "guard region" you mentioned above), just in case somebody > has fscked around with /proc/sys/vm/mmap_min_addr. Yes, I don't want to use a NULL pointer and rely on mmap_min_addr. For x86-64, we have two "guard regions" that can be used to generate an address that is guaranteed to fault: - the kernel always lives in the "top bit set" part of the address space (and any address tagging bits don't touch that part), and does not map the highest virtual address because that's used for error pointers, so the "all bits set" address always faults - the region between valid user addresses and kernel addresses is also always going to fault, and we don't have them adjacent to each other (unlike, for example, 32-bit i386, where the kernel address space is directly adjacent to the top of user addresses) So on x86-64, the simple solution is to just say "we know if the top bit is clear, it cannot ever touch kernel code, and if the top bit is set we have to make the address fault". So just duplicating the top bit (with an arithmetic shift) and or'ing it with the low bits, we get exactly what we want. But my knowledge of arm64 is weak enough that while I am reading assembly language and I know that instead of the top bit, it's bit55, I don't know what the actual rules for the translation table registers are. If the all-bits-set address is guaranteed to always trap, then arm64 could just use the same thing x86 does (just duplicating bit 55 instead of the sign bit)? Linus