Re: arm64 pointer tagging, VA-bits, the end of the world...
> Op 17 aug. 2016, om 16:39 heeft Leif Lindholm <leif.lindholm@linaro.org> het volgende geschreven:
>
> Hi all,
>
> (Sent to cross-distro with debian-arm on cc.)
>
> We have an 'interesting' situation ahead of us, or indeed some of us
> have already fallen into it:
>
> ARM64 platforms with > 512GB between the lowest and highest RAM
> addresses end up getting their amount of usable memory truncated if
> the kernel is built for 39-bit VA (which is what currently happens for
> Debian kernels). For 4.7, the arm64 defconfig was changed to enable
> 48-bit VA by default.
>
> While itself not a critical error (but really annoying), in
> combination with GRUB putting the initrd near the top of available
> RAM, we end up with systems not booting. We think we've also seen
> issues with ACPI tables above this waterline.
>
> Simple - all we need to do then is enable 48-bit VA in the arm64
> kernel config? Well, yes. I know Fedora are already doing this, and I
> have raised a bug[1] for Debian to do the same.
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834505
>
> The problem is - some pieces of software have had time to be written
> in a ... let's charitably call it a "focused on amd64" fasion ... with
> the embedded assumption that anything above virtual address bit 44 is
> a pointer-tag free-for-all.
>
> On the Debian-ish side, we're coming up on both Ubuntu 16.10 and the
> freeze for Stretch, leaving a pretty short window to resolve this
> unholy kernel->initrd->userland triangle.
>
> The applications we know are affected are luajit and mozjs (libv8 is
> not a problem). But this has a follow-on cost: both of these are used
> by other packages. Other jit/runtime packages could have their own
> issues.
>
> The mozjs bug is fixed on trunk, and will hopefully make it into
> release 49[2], but it remains to be seen if that's too late for some
> distributions.
Since mozjs is “special” when it comes to API, you have to depend on a specific version of it, so policykit hard-depends on mozjs17, which has no fixes available for the VA problem :( I’ve seen reports of systems unable to boot because of the systemd->polkit->mozjs chain. Is anyone working on fixing that?
regards,
Koen
Reply to: