Bug#834505: arm64 boot failure with large physical memory range
On Sun, 21 Aug 2016 01:11:15 +0100 Ben Hutchings <ben@decadent.org.uk> wrote:
> On Fri, 2016-08-19 at 13:42 +0100, Leif Lindholm wrote:
> > On Fri, Aug 19, 2016 at 12:50:49PM +0100, Ben Hutchings wrote:
> > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > everything using mozilla-js).
> > > > > [...]
> > > > >
> > > > > Could we possibly work around that by reducing
> > > > > CONFIG_ARCH_MMAP_RND_BITS_MAX? Â (That's not directly configurable; it
> > > > > requires patching arch/arm64/Kconfig.)
> > > >
> > > > 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.
>
Indeed. The most likely failure mode (but we'd need to check to be
sure) is that the JITs 'clean up' the addresses before dereferencing
them by masking bits that have a special meaning to them, and
inadvertently clear upper address bits in the process.
My concern with changing CONFIG_ARCH_MMAP_RND_BITS_MAX is that it is
not a guarantee that mmap() will not be called with explicit addr
values in the problematic range. (In some cases, munmap() is used to
detect the VA range, given that munmap() turns out to succeed for
non-existent mappings unless the address value exceeds the VA size).
It's unlikely that an affected JIT would do both things at the same
time, i.e., steal upper address bits and perform mmap() allocations in
the problematic range, but we'd need to confirm it nonetheless.
--
Ard.
Reply to: