On October 10, 2026 9:28:30 AM GMT+02:00, John Paul Adrian Glaubitz <[email protected]> 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 <[email protected]> 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/[email protected]/), >> > 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.
