use 48-bit address space via 4 level page tables on arm64 by default

[thestinger]

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

[thestinger]

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.

[sempervictus]

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?

[thestinger]

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.

[thestinger]

Very few applications still have this compatibility issue since we got Unity to fix it years ago.