On Sun, Aug 21, 2016 at 01:11:15AM +0100, Ben Hutchings wrote: > > > > I think this would be opening up a real can of worms. Not all sizes > > > > are supported by the architecture, and only certain VA_BITS/pagesize > > > > combinations work in the kernel. > > > > > > > > We could switch to 42-bit VA, but that would require switching to 64K > > > > pagesize, which would be an even huger can. > > > > > > I'm not suggesting using any unusual page table configuration. Just > > > reducing the ASLR range that is currently implied by a 48-bit VA. > > > > But would that help anything? > > Even if you don't allocate to the top bits, if they're used for > > tagging, you'll still segfault. > > I seem to remember that AArch64 has the ill-advised rule that VA bits > outside the range of the current page table format are ignored, so > presumably you're concerned that the code relies on this. But since > other 64-bit architectures (at least x86, PowerPC and SPARC) behave > otherwise, I would expect semi-portable code to mask out the tag bits.
You're not wrong, but unfortunately the ability to write semi-portable code left the planet over a decade ago. For clarification - the problem is not with regards to code written specifically for arm64 and not verified with different MMU-configurations, but with code written for x86 and never tested on anything else. See my post to cross-distro last week (and the subsequent thread): https://lists.linaro.org/pipermail/cross-distro/2016-August/000838.html So simply adjusting the mmap range on Debian would result in us using less verified code paths without it helping with the problem at hand. / Leif
