anthraxx
use 48-bit address space via 4 level page tables on arm64 by default
Linux kernel defaults to 39-bit address space, providing far weaker ASLR entropy than x86_64 and also making it incompatible with hardened_malloc in the default configuration since there's not enough space. It also weakens other mitigations based on using large PROT_NONE gaps.
https://github.com/GrapheneOS/hardened_malloc
We change this in the defconfigs for Android Generic Kernel Images, but the defaults can be changed in the configuration setup instead:
https://github.com/GrapheneOS/kernel_common-5.15/commit/82c2afeb59b52d08f9f72b6c917703d3ffbabec2 https://github.com/GrapheneOS/kernel_common-5.15/commit/5a4ec3db69061aada94009b177154ce743ce5993
We needed to develop https://github.com/GrapheneOS/kernel_common-5.15/commit/ff8f099e45334978ae34564c79f20c61e90b0f77 with a user-facing per-app toggle to work around certain apps (mostly games) being incompatible with the larger address space. I don't think that's going to be an issue anywhere else. It's almost entirely an issue with games and mostly with older versions of Unity. I think it was fixed in newer Unity. Some other games seem to have the same issue. I doubt that it's an issue for any widely used server software in practice especially since many servers are likely already using 48 bit or larger address space.
Is there any way to probe address space compatibility from within the kernel to conditionally set ELF_ET_DYN_BASE dependent on the userspace caller's ability handle the 48B address space? Alternatively, is it feasible to perform these checks at the alloc/libc levels to then request the correct base from ring0?
No, but nearly everything does work with a 48-bit address space. The issue is that some apps have integer overflows or try to use the "unused" bits for tagging points.
Very few applications still have this compatibility issue since we got Unity to fix it years ago.