Re: [PATCH v4 2/2] x86: Start removing X86_X32_ABI

[John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>]

On Sat, 2026-10-10 at 08:51 +0200, H. Peter Anvin wrote:
> On October 10, 2026 4:13:55 AM GMT+02:00, Tancred <alex@narraduct.com> wrote:
> > 
> > 
> > On 10/8/26 03:07, Sebastian Andrzej Siewior wrote:
> > > where certain workloads widely
> > > move to x32 and use it exclusively. In the meantime Debian introduced a
> > > patch to disable x32 by default (so it has to be enabled at boot time on
> > > the command line) because they are afraid of the increased attack
> > > surface. Fedora as far as I tell has X32 disabled (looking at 7.0-rc5
> > > rpm in rawhide).
> > > 
> > > Since there is practically no real use for x32
> > 
> > I only recently discovered x32 and built a Desktop (with all daemons and utilities running 10-30% smaller and some a bit faster, with 64 bit libraries for eg. Firefox.) My experiment should definitely not decide anything, but how much real-world use would be sufficient to justify continued presence (more complex compat code)?
> > 
> > If left behind a flag like Debian (like the 2014 proposal https://lore.kernel.org/lkml/1415245982.3398.53.camel@decadent.org.uk/), there are no security risks so I understand the benefit is reduced code complexity and maintenance burden. Older threads critiqued the implementation. What's the smallest kernel support which would keep 32-bit pointers possible? Could a small design (eg. just 32-bit pointers on x86-64 with i386's type layout, so no 3rd compat case (cf. MIPS n32 and o32)) work?
> > 
> > - Alex Alejandre
> 
> The thing is, we don't actually know. Therefore, if we are to keep x32, we need ***real users*** to speak up ***now*** and explain why they are using it and what the benefit to them is. With actual performance numbers.

Real users usually aren't subscribed to Linux kernel mailing lists. If you want
to figure out whether anyone is using a certain kernel feature, you have to ask
within the communities.

In any case, we're still building Debian unstable for x32:

https://buildd.debian.org/status/architecture.php?a=x32&suite=sid

> Otherwise it is not worth maintaining, partly because it apparently interferes with the convergence of the 32-bit ABIs, and the handful of x32-specific pieces of code do represent an additional attack surface.

Aren't the attack surfaces disabled when x32 ABI support is turned off?

> The desktop distros generally chafe under the 4 GB process limit, which means that an all-x32 desktop distro isn't very useful; having both x32 and x64 libraries defeats much of the x32 benefit, so the real use case is embedded or self-managed code bases.

Well, you can also run x32 code inside a chroot or containers, can't you?

> We are not going to go back in 2026 and redoing the *in retrospect* rather unfortunate choices made due to "Hinc Dictat Linus" early on (the original plan was to simply provide a fast way to access 32-bit syscalls from 64-bit mode and let the evolution of the compat ABI deal with things like time_t, but Linus objected to introducing a new ABI with 32-bit time_t, and at the time the time64_t interfaces were not yet there, so it ended up being an ad hoc implementation.)

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913