[PATCH 11/11] kernel/x86: enable x32 support for amd64

[Elliott Mitchell]

On Wed, Nov 15, 2023 at 05:35:11AM +0100, Stefan Lippers-Hollmann wrote:
> 
> On 2023-11-14, Elliott Mitchell wrote:
> > Date: Thu, 30 Mar 2023 16:30:49 -0700
> >
> > Full amd64 support isn't really appropriate for most situations
> > OpenWRT is deployed.  Whereas x86-x32 seems extremely appropriate for
> > these situations.  As such enable x86-x32 support.
> >
> > CONFIG_ARCH_MMAP_RND_COMPAT_BITS is required to follow along,
> > otherwise the kernel build breaks.
> >
> > Signed-off-by: Elliott Mitchell <ehem+openwrt at m5p.com>
> > ---
> >
> > I suggest OpenWRT should place some effort towards x86-x32.  x86-x32
> > seems a rather superior generic target for OpenWRT.  Only issue is
> > it could be valuable to have at least minimal amd64 userland support
> > alongside the x86-x32 version.
> >
> > Note, this simply enables kernel support.  Until userspace building
> > is added, this does almost nothing.
> 
> What would be the reason for enabling x32?
> There is very little upstream buy-in for x32, when this question came
> up for Debian, it was rejected to be enabled for -among other reasons-
> concerns about the the system call ABI and its security hardening, as
> well as concerns about the long term ABI compatibility (the later of
> which probably not that relevant for OpenWrt, the former however is).

What I see seems like x32 is still making progress on Debian.  I note
musl has a x32 target.  While it still isn't a release architecture for
Debian, I could see it becoming one.

> I do understand that this is a pet peeve among the high-density
> virtualization crowd, but anywhere else, x32 as a concept is dead (and
> never took off in the first place).

In my view x32 has some substantial use cases.  Have you ever seen `ls`,
`rm`, `grep`, `find`, or `test` needing more than 4GB of memory?  Any
of these needing that much memory would suggest something was wrong
(or perhaps someone was trying to abuse them in an impressive way).  For
quite a number of shell utilities being able to use more than 4GB of
memory is pointless.

This is speculation, but I suspect there would be substantial value in
having mixed systems where some utilities were x32 and some were amd64.

> *If* (and imho, again purely my own irrelevant opinion, that is a
> big IF) x32 would really be deemed worthwhile for OpenWrt, it still
> doesn't make sense to enable this whole userspace ABI for the x86_64
> kernel now, before your desired additional patches are available
> (and even then, you'd probably want a dedicated x32 subtarget instead
> of  killing off the pure64 target for OpenWrt - something I'd
> personally be even less in favour of).

Enabling the kernel support is always the first step.  How does one test
userspace if the kernel won't even load the executables?

> That aside, I may be confused by the config stacking order, but...
> If I read it correctly, you enable CONFIG_X86_X32 in
> target/linux/x86/config-*, while explicitly disabling it in the
> only subtarget config (target/linux/x86/64/config-*) where it
> would matter, is that really the intended way round and in line
> with the commit description?

Previously x32 was explicitly disabled in x86/64/config subtarget.  This
removes that, then enables it in x86/config target.


On Wed, Nov 15, 2023 at 05:41:54AM +0100, Stefan Lippers-Hollmann wrote:
> 
> On 2023-11-15, Stefan Lippers-Hollmann wrote:
> > What would be the reason for enabling x32?
> > There is very little upstream buy-in for x32, when this question came
> > up for Debian, it was rejected to be enabled for -among other reasons-
> > concerns about the the system call ABI and its security hardening, as
> > well as concerns about the long term ABI compatibility (the later of
> > which probably not that relevant for OpenWrt, the former however is).
> 
> Just to add some references to this:
> - Can we drop upstream Linux x32 support?
>   https://lkml.org/lkml/2018/12/10/1145
>   the whole thread is interesting and doesn't display too much
>   sympathy for x32

Yes, and did it get dropped?  No, it didn't.  At least some of the issues
brought up there have been fixed.

> - information about the never merged/ defunct x32 port proposed for
>   Debian
>   https://wiki.debian.org/X32Port

There are pointers to many bugs which were found and fixed.  There don't
appear to be that many unresolved ones.  Unfortunately I don't know
whether it is likely to be part of the next formal release.

I also note even the most extreme of the OpenWRT virtual machine
suggestions doesn't suggest more than 4GB of memory.

I don't know the future, but enabling kernel support is the first step.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445