Re: armv8 does not respect personality ADDR_LIMIT_3GB

[Arnd Bergmann <arnd@arndb.de>]

On Mon, Oct 4, 2021 at 7:38 PM Camm Maguire <camm@maguirefamily.org> wrote:
>
> Greetings!  There seems to be a subarchitecture within the current 32bit
> Debian arm universes and buildds.  armv8 processors will leave the C
> stack start at 0xffffffff even when personality ADDR_LIMIT_3GB is set,
> whereas on armv7 the address starts at 0xbfffffff, as on other 32bit
> linux machines.
>
> Is this a bug?  Are there other (perhaps gcc?) switches which can match
> the armv7 behavior on armv8 machines (e.g. running a armel or armhf
> chroot?)
>
> Right now gcl binaries compiled on armv7 will not run on armv8 in a
> 32bit chroot because of this.  Only workaround I see at the moment is to
> cripple all gcl 32bit arm binaries and remove immediate fixnum addresses
> which should go above 0xc0000000.

Hi Camm,

This is a complex topic, a few notes on this:

- Just to clarify, this is unrelated to armv7 vs armv8 processors, only the
  kernel running on them. Running a 32-bit kernel on an armv8 CPU
  has the same limit as on an armv7 CPU. The generally recommendation
  however is to run 64-bit kernels on these CPUs anyway, so this is
  indeed a problem in compat mode.

- PER_LINUX32_3GB is technically an x86-only feature, none of the
  other architectures with compat mode support (powerpc, s390, sparc,
  mips, parisc and arm64) implement this. Unfortunately, there is no
  check for invalid arguments to the personality() syscall, so passing this
  flag on architectures other than x86 will just silently ignore it. Most of
  these will use a 4GB address space here.

- There is ongoing work by Linus Walleij and others to extend 32-bit
   arm kernels to also have a wider address space, allowing up to
   3.75GB of user space addresses (and also up to 3.75GB of
   lowmem). When this is implemented, the application will stop
   working on native 32-bit kernels as well.

- It would probably be possible to implement PER_LINUX32_3GB on
  all architectures, including native 32-bit ones, if there is demand.
  More generally, we have previously discussed adding a kernel
  interface to pick an arbitrary maximum user space address limit
  per process, which would solve other problems as well. I don't
  think anyone is working on that at the moment.

       Arnd