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

[H. Peter Anvin]

On October 10, 2026 9:28:30 AM GMT+02:00, John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx> wrote:
>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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx/), 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
>

That is why I said it also needs to be in the commit message. That way someone can figure out why it is marked BROKEN.

This is a last warning.