On Sun, 2016-08-21 at 11:42 +0100, Leif Lindholm wrote: > 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 I already read that. I don't see the contradiction. > 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. What new code path would be used? Ben. -- Ben Hutchings It's easier to fight for one's principles than to live up to them.
Attachment:
signature.asc
Description: This is a digitally signed message part