Bug#834505: arm64 boot failure with large physical memory range
X-Debbugs-CC: ard.biesheuvel@linaro.org
On Sun, Aug 21, 2016 at 02:46:06PM +0100, Ben Hutchings wrote:
> > > 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.
OK, as per my reply to Ian's comment, I now understand your point here.
If this is true, then that does reduce the scope of the problem.
> > 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?
Looking at the code, apparently none other than the one that sets
/proc/sys/vm/mmap_rnd_bits, so fair enough. But this still scares me,
as it still relies on software that has been proven to not be sane
being sane.
I would be much less nervous with an approach like the one suggested
by Ard at: https://patchwork.kernel.org/patch/9292139/
But then maybe I'm just being too nervous.
/
Leif
Reply to: