Someone asked me about 64K pages and the AArch32 ABI again recently. It’s a question that has passed across my desk multiple times and even followed me through multiple companies. Given that long history, and the changes made to the Arm toolchains to ensure freshly built ELF binaries can be loaded, I was interested to see whether Debian 9 (Stretch) armhf userspace would on a machine with 64K pages. I also had access to a Developerbox to help me indulge my curiosity. The short answer is that it is *not* possible to boot Debian Stretch armhf container on a machine with 64k pages because the kernel cannot map the init process… but is only half the story; it really was very close to working!
I put together a fairly spartan Debian rootfs (console only, no build tools). The resulting OS has 709 executables in /bin, /usr/bin, /sbin and /usr/sbin, of which 571 are 32-bit ELF executables (the rest are scripts). I then tried loading each one using ldd; ldd works internally by performing dynamic linking and loading but it does not jump to the actual entry point and instead calls into to some post-analysis tool to show where the libraries came from. It is a good proxy to test whether the executable could work with 64K pages and is gives a consistent output that makes it easy to run from a script.
Of the 571 ELF executables, 46 cannot be mapped because they contain segments that are not (64K) page aligned. More interestingly the problems loading 46 executables boil down to just four libraries: libnfnetlink.so.0, libsystemd.so.0, libudev.so.1, and libXau.so.6. It is interesting that both libsystemd and libudev are part of systemd; makinng it likely there is just three packages left that prevent the use of 64K pages.
Anyhow, that about it, except to observe that all the above stats were gathered by running a 32-bit chroot with 64k pages. /sbin/init might be broken but bash, grep, cut, ldd and a bunch of other common shell tools needed to do the above analysis all worked just fine!