[PATCH v4 0/2] Start removing X86_X32_ABI

[PATCH v4 0/2] Start removing X86_X32_ABI

[Sebastian Andrzej Siewior]

From: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>

Patch #2 prepares the removal of the X32 ABI and has the broader
reasoning. Patch #1 removes x32 from the selftests because it does not
have a depends on and assumes x32 to be always available on x64 and so
it breaks.
It is expected v7.3 to become LTS.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
v3…v4: https://patch.msgid.link/20260813-x32_removal-v3-0-e8f96cd15478@linutronix.de
  - Depend on BROKEN instead of removing it.

v2…v3: https://patch.msgid.link/20260707212252.bYk3-AlU@linutronix.de
  - added a nolibc-selftests patch to not break it in their setup since
    it does not depend on the symbol.

v1…v2: https://lore.kernel.org/r/20260523093734.A3AR7reJ@linutronix.de
  - reworded commit message

Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Bill Wendling <morbo@google.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: Jonathan Corbet <corbet@lwn.net>,
Cc: Justin Stitt <justinstitt@google.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Neal Gompa <neal@gompa.dev>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>                                                                                           
Cc: Sam James <sam@gentoo.org>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Thomas Gleixner <tglx@kernel.org>
Cc: Thomas Weißschuh <linux@weissschuh.net>
Cc: Tomas Glozar <tglozar@kernel.org>
Cc: Willy Tarreau <w@1wt.eu>
Cc: x86@kernel.org
To: linux-kernel@vger.kernel.org
To: linux-kselftest@vger.kernel.org

---
Sebastian Andrzej Siewior (1):
      x86: Start removing X86_X32_ABI

Thomas Weißschuh (1):
      selftests/nolibc: remove the x32 testcase

 arch/x86/Kconfig                               | 2 +-
 tools/testing/selftests/nolibc/Makefile.nolibc | 6 ------
 tools/testing/selftests/nolibc/run-tests.sh    | 7 +------
 3 files changed, 2 insertions(+), 13 deletions(-)
---
base-commit: 2ee859ebf156157609f71060ae472711c8cbc326
change-id: 20260706-x32_removal-28823498c4a2

Best regards,
--  
Sebastian Andrzej Siewior <sebastian@breakpoint.cc>

[PATCH v4 1/2] selftests/nolibc: remove the x32 testcase

[Sebastian Andrzej Siewior]

From: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>

From: Thomas Weißschuh <linux@weissschuh.net>

Support for the x32 ABI is about to be removed from the kernel itself.
This will break the nolibc x32 testcase.

Remove the testcase to avoid breaking the testsuite in general.

This also ends official support from nolibc proper for x32. But as there
is no clear x32-specific code in the nolibc codebase, there won't be a
removal patch for that.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 tools/testing/selftests/nolibc/Makefile.nolibc | 6 ------
 tools/testing/selftests/nolibc/run-tests.sh    | 7 +------
 2 files changed, 1 insertion(+), 12 deletions(-)

diff --git a/tools/testing/selftests/nolibc/Makefile.nolibc b/tools/testing/selftests/nolibc/Makefile.nolibc
index f70c8dfca0186..895a6ea7a8e45 100644
--- a/tools/testing/selftests/nolibc/Makefile.nolibc
+++ b/tools/testing/selftests/nolibc/Makefile.nolibc
@@ -47,7 +47,6 @@ XARCH_riscv      = riscv64
 XARCH            = $(or $(XARCH_$(ARCH)),$(ARCH))
 
 # map from user input variants to their kernel supported architectures
-ARCH_x32         = x86
 ARCH_armthumb    = arm
 ARCH_ppc         = powerpc
 ARCH_ppc64       = powerpc
@@ -70,7 +69,6 @@ ARCH            := $(or $(ARCH_$(XARCH)),$(XARCH))
 # kernel image names by architecture
 IMAGE_i386       = arch/x86/boot/bzImage
 IMAGE_x86_64     = arch/x86/boot/bzImage
-IMAGE_x32        = arch/x86/boot/bzImage
 IMAGE_x86        = arch/x86/boot/bzImage
 IMAGE_arm64      = arch/arm64/boot/Image
 IMAGE_arm        = arch/arm/boot/zImage
@@ -106,7 +104,6 @@ DEFCONFIG_sh4        = rts7751r2dplus_defconfig
 DEFCONFIG_openrisc   = virt_defconfig
 DEFCONFIG            = $(or $(DEFCONFIG_$(XARCH)),defconfig)
 
-EXTRACONFIG_x32       = -e CONFIG_X86_X32_ABI
 EXTRACONFIG_arm       = -e CONFIG_NAMESPACES
 EXTRACONFIG_armthumb  = -e CONFIG_NAMESPACES
 EXTRACONFIG_sparc32   = -e CONFIG_TMPFS
@@ -119,7 +116,6 @@ EXTRACONFIG           = $(EXTRACONFIG_$(XARCH))
 TEST =
 
 # QEMU_ARCH: arch names used by qemu
-QEMU_ARCH_x32        = x86_64
 QEMU_ARCH_x86        = x86_64
 QEMU_ARCH_arm64      = aarch64
 QEMU_ARCH_armthumb   = arm
@@ -151,7 +147,6 @@ endif
 # QEMU_ARGS : some arch-specific args to pass to qemu
 QEMU_ARGS_i386       = -M pc -append "console=ttyS0,9600 i8042.noaux panic=-1 $(TEST:%=NOLIBC_TEST=%)"
 QEMU_ARGS_x86_64     = -M pc -append "console=ttyS0,9600 i8042.noaux panic=-1 $(TEST:%=NOLIBC_TEST=%)"
-QEMU_ARGS_x32        = -M pc -append "console=ttyS0,9600 i8042.noaux panic=-1 $(TEST:%=NOLIBC_TEST=%)"
 QEMU_ARGS_x86        = -M pc -append "console=ttyS0,9600 i8042.noaux panic=-1 $(TEST:%=NOLIBC_TEST=%)"
 QEMU_ARGS_arm64      = -M virt -cpu cortex-a53 -append "panic=-1 $(TEST:%=NOLIBC_TEST=%)"
 QEMU_ARGS_arm        = -M virt -append "panic=-1 $(TEST:%=NOLIBC_TEST=%)"
@@ -189,7 +184,6 @@ Q=@
 endif
 
 CFLAGS_i386 = $(call cc-option,-m32)
-CFLAGS_x32 = -mx32
 CFLAGS_arm = -marm
 CFLAGS_armthumb = -mthumb -march=armv6t2
 CFLAGS_parisc32 = -mfast-indirect-calls
diff --git a/tools/testing/selftests/nolibc/run-tests.sh b/tools/testing/selftests/nolibc/run-tests.sh
index dc0b1649c6419..20e0d2dc0e9b9 100755
--- a/tools/testing/selftests/nolibc/run-tests.sh
+++ b/tools/testing/selftests/nolibc/run-tests.sh
@@ -18,7 +18,7 @@ test_mode=system
 werror=1
 llvm=
 all_archs=(
-	i386 x86_64 x32
+	i386 x86_64
 	arm64 arm armthumb
 	mips32le mips32be mipsn32le mipsn32be mips64le mips64be
 	openrisc
@@ -119,7 +119,6 @@ crosstool_arch() {
 	mips*) echo mips;;
 	s390*) echo s390;;
 	sparc*) echo sparc64;;
-	x32*) echo x86_64;;
 	parisc32) echo hppa;;
 	*) echo "$1";;
 	esac
@@ -198,10 +197,6 @@ test_arch() {
 		echo "Unsupported configuration"
 		return
 	fi
-	if [ "$arch" = "x32" ] && [ "$test_mode" = "user" ]; then
-		echo "Unsupported configuration"
-		return
-	fi
 
 	mkdir -p "$build_dir"
 	swallow_output "${MAKE[@]}" defconfig

-- 
2.55.0

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

[Sebastian Andrzej Siewior]

From: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>

From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

The x32 ABI was introduced in v3.4 to leverage the additional registers
which were available on x86_64 but not on i386 while keeping the smaller
32bit pointers.

This did not take off. The memory usage usually knows no limit and the
better performance did not reach a point 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).

The syscall range >512 used by x32 can not be reused because on earlier
kernels (before v5.4 with x32 enabled, see commit 6365b842aae4
("x86/syscalls: Split the x32 syscalls into their own table") it is not
obvious if the syscall is for x86-64 and not implemented or meant for
x32.
What can be removed are the special compat cases due to different
alignment.

Since there is practically no real use for x32, start removing it by
marking the symbol as BROKEN so it is not possible to enable by default.
It will remain around in the last LTS kernel of this year and then it
will be removed.

Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 arch/x86/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 15fd9ec5ecacb..21a6863e14e7a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -3104,7 +3104,7 @@ config IA32_EMULATION_DEFAULT_DISABLED
 
 config X86_X32_ABI
 	bool "x32 ABI for 64-bit mode"
-	depends on X86_64
+	depends on X86_64 && BROKEN
 	# llvm-objcopy does not convert x86_64 .note.gnu.property or
 	# compressed debug sections to x86_x32 properly:
 	# https://github.com/ClangBuiltLinux/linux/issues/514

-- 
2.55.0

Re: [PATCH v4 1/2] selftests/nolibc: remove the x32 testcase

[H. Peter Anvin]

On October 8, 2026 11:07:42 AM GMT+02:00, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
>From: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
>
>From: Thomas Weißschuh <linux@weissschuh.net>
>
>Support for the x32 ABI is about to be removed from the kernel itself.
>This will break the nolibc x32 testcase.
>
>Remove the testcase to avoid breaking the testsuite in general.
>
>This also ends official support from nolibc proper for x32. But as there
>is no clear x32-specific code in the nolibc codebase, there won't be a
>removal patch for that.
>
>Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
>Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>---
> tools/testing/selftests/nolibc/Makefile.nolibc | 6 ------
> tools/testing/selftests/nolibc/run-tests.sh    | 7 +------
> 2 files changed, 1 insertion(+), 12 deletions(-)
>
>diff --git a/tools/testing/selftests/nolibc/Makefile.nolibc b/tools/testing/selftests/nolibc/Makefile.nolibc
>index f70c8dfca0186..895a6ea7a8e45 100644
>--- a/tools/testing/selftests/nolibc/Makefile.nolibc
>+++ b/tools/testing/selftests/nolibc/Makefile.nolibc
>@@ -47,7 +47,6 @@ XARCH_riscv      = riscv64
> XARCH            = $(or $(XARCH_$(ARCH)),$(ARCH))
> 
> # map from user input variants to their kernel supported architectures
>-ARCH_x32         = x86
> ARCH_armthumb    = arm
> ARCH_ppc         = powerpc
> ARCH_ppc64       = powerpc
>@@ -70,7 +69,6 @@ ARCH            := $(or $(ARCH_$(XARCH)),$(XARCH))
> # kernel image names by architecture
> IMAGE_i386       = arch/x86/boot/bzImage
> IMAGE_x86_64     = arch/x86/boot/bzImage
>-IMAGE_x32        = arch/x86/boot/bzImage
> IMAGE_x86        = arch/x86/boot/bzImage
> IMAGE_arm64      = arch/arm64/boot/Image
> IMAGE_arm        = arch/arm/boot/zImage
>@@ -106,7 +104,6 @@ DEFCONFIG_sh4        = rts7751r2dplus_defconfig
> DEFCONFIG_openrisc   = virt_defconfig
> DEFCONFIG            = $(or $(DEFCONFIG_$(XARCH)),defconfig)
> 
>-EXTRACONFIG_x32       = -e CONFIG_X86_X32_ABI
> EXTRACONFIG_arm       = -e CONFIG_NAMESPACES
> EXTRACONFIG_armthumb  = -e CONFIG_NAMESPACES
> EXTRACONFIG_sparc32   = -e CONFIG_TMPFS
>@@ -119,7 +116,6 @@ EXTRACONFIG           = $(EXTRACONFIG_$(XARCH))
> TEST =
> 
> # QEMU_ARCH: arch names used by qemu
>-QEMU_ARCH_x32        = x86_64
> QEMU_ARCH_x86        = x86_64
> QEMU_ARCH_arm64      = aarch64
> QEMU_ARCH_armthumb   = arm
>@@ -151,7 +147,6 @@ endif
> # QEMU_ARGS : some arch-specific args to pass to qemu
> QEMU_ARGS_i386       = -M pc -append "console=ttyS0,9600 i8042.noaux panic=-1 $(TEST:%=NOLIBC_TEST=%)"
> QEMU_ARGS_x86_64     = -M pc -append "console=ttyS0,9600 i8042.noaux panic=-1 $(TEST:%=NOLIBC_TEST=%)"
>-QEMU_ARGS_x32        = -M pc -append "console=ttyS0,9600 i8042.noaux panic=-1 $(TEST:%=NOLIBC_TEST=%)"
> QEMU_ARGS_x86        = -M pc -append "console=ttyS0,9600 i8042.noaux panic=-1 $(TEST:%=NOLIBC_TEST=%)"
> QEMU_ARGS_arm64      = -M virt -cpu cortex-a53 -append "panic=-1 $(TEST:%=NOLIBC_TEST=%)"
> QEMU_ARGS_arm        = -M virt -append "panic=-1 $(TEST:%=NOLIBC_TEST=%)"
>@@ -189,7 +184,6 @@ Q=@
> endif
> 
> CFLAGS_i386 = $(call cc-option,-m32)
>-CFLAGS_x32 = -mx32
> CFLAGS_arm = -marm
> CFLAGS_armthumb = -mthumb -march=armv6t2
> CFLAGS_parisc32 = -mfast-indirect-calls
>diff --git a/tools/testing/selftests/nolibc/run-tests.sh b/tools/testing/selftests/nolibc/run-tests.sh
>index dc0b1649c6419..20e0d2dc0e9b9 100755
>--- a/tools/testing/selftests/nolibc/run-tests.sh
>+++ b/tools/testing/selftests/nolibc/run-tests.sh
>@@ -18,7 +18,7 @@ test_mode=system
> werror=1
> llvm=
> all_archs=(
>-	i386 x86_64 x32
>+	i386 x86_64
> 	arm64 arm armthumb
> 	mips32le mips32be mipsn32le mipsn32be mips64le mips64be
> 	openrisc
>@@ -119,7 +119,6 @@ crosstool_arch() {
> 	mips*) echo mips;;
> 	s390*) echo s390;;
> 	sparc*) echo sparc64;;
>-	x32*) echo x86_64;;
> 	parisc32) echo hppa;;
> 	*) echo "$1";;
> 	esac
>@@ -198,10 +197,6 @@ test_arch() {
> 		echo "Unsupported configuration"
> 		return
> 	fi
>-	if [ "$arch" = "x32" ] && [ "$test_mode" = "user" ]; then
>-		echo "Unsupported configuration"
>-		return
>-	fi
> 
> 	mkdir -p "$build_dir"
> 	swallow_output "${MAKE[@]}" defconfig
>

Acked-by: H. Peter Anvin (Rosaic) <hpa@zytor.com>

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

[H. Peter Anvin]

On October 8, 2026 11:07:43 AM GMT+02:00, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
>From: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
>
>From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>
>The x32 ABI was introduced in v3.4 to leverage the additional registers
>which were available on x86_64 but not on i386 while keeping the smaller
>32bit pointers.
>
>This did not take off. The memory usage usually knows no limit and the
>better performance did not reach a point 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).
>
>The syscall range >512 used by x32 can not be reused because on earlier
>kernels (before v5.4 with x32 enabled, see commit 6365b842aae4
>("x86/syscalls: Split the x32 syscalls into their own table") it is not
>obvious if the syscall is for x86-64 and not implemented or meant for
>x32.
>What can be removed are the special compat cases due to different
>alignment.
>
>Since there is practically no real use for x32, start removing it by
>marking the symbol as BROKEN so it is not possible to enable by default.
>It will remain around in the last LTS kernel of this year and then it
>will be removed.
>
>Acked-by: Arnd Bergmann <arnd@arndb.de>
>Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>---
> arch/x86/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>index 15fd9ec5ecacb..21a6863e14e7a 100644
>--- a/arch/x86/Kconfig
>+++ b/arch/x86/Kconfig
>@@ -3104,7 +3104,7 @@ config IA32_EMULATION_DEFAULT_DISABLED
> 
> config X86_X32_ABI
> 	bool "x32 ABI for 64-bit mode"
>-	depends on X86_64
>+	depends on X86_64 && BROKEN
> 	# llvm-objcopy does not convert x86_64 .note.gnu.property or
> 	# compressed debug sections to x86_x32 properly:
> 	# https://github.com/ClangBuiltLinux/linux/issues/514
>

Acked-by: H. Peter Anvin (Rosaic) <hpa@zytor.com>

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

[Tancred]

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

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

[H. Peter Anvin]

On October 8, 2026 11:07:43 AM GMT+02:00, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
>From: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
>
>From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>
>The x32 ABI was introduced in v3.4 to leverage the additional registers
>which were available on x86_64 but not on i386 while keeping the smaller
>32bit pointers.
>
>This did not take off. The memory usage usually knows no limit and the
>better performance did not reach a point 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).
>
>The syscall range >512 used by x32 can not be reused because on earlier
>kernels (before v5.4 with x32 enabled, see commit 6365b842aae4
>("x86/syscalls: Split the x32 syscalls into their own table") it is not
>obvious if the syscall is for x86-64 and not implemented or meant for
>x32.
>What can be removed are the special compat cases due to different
>alignment.
>
>Since there is practically no real use for x32, start removing it by
>marking the symbol as BROKEN so it is not possible to enable by default.
>It will remain around in the last LTS kernel of this year and then it
>will be removed.
>
>Acked-by: Arnd Bergmann <arnd@arndb.de>
>Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>---
> arch/x86/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>index 15fd9ec5ecacb..21a6863e14e7a 100644
>--- a/arch/x86/Kconfig
>+++ b/arch/x86/Kconfig
>@@ -3104,7 +3104,7 @@ config IA32_EMULATION_DEFAULT_DISABLED
> 
> config X86_X32_ABI
> 	bool "x32 ABI for 64-bit mode"
>-	depends on X86_64
>+	depends on X86_64 && BROKEN
> 	# llvm-objcopy does not convert x86_64 .note.gnu.property or
> 	# compressed debug sections to x86_x32 properly:
> 	# https://github.com/ClangBuiltLinux/linux/issues/514
>

I want to make one change to this. 

The commit message states this as a fait accompli, but what it should say is: 

** If you have a legitimate use case for x32, this is your last chance to speak up. Otherwise it will... **

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

[H. Peter Anvin]

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.

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.

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.

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.)

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

[John Paul Adrian Glaubitz]

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

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@physik.fu-berlin.de> 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@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
>

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.