From nobody Sun May 24 19:33:40 2026 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CF12B330B11 for ; Sat, 23 May 2026 09:37:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779529059; cv=none; b=XIQ5m0gzaOtnBP3/9fpKPM27VLhphdGXHsm7b1QFJTbIRtON/yP7xrg7FLsmEKx6P/5TYkEAPxmZnwX65+NgzY1QydWtql2jCVvfpfogW52kxCXwd3do5jysyuTUMJNcgX3+RuoJbHVGqDBiQSzGd3C98gf+8sBpdRg7HT7wzX4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779529059; c=relaxed/simple; bh=wQI8DEuwxrBG2bVVJtkvggk8S4Wjsq2ybUn/1imR07s=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition; b=BGSNJ4nlrc8yMlpqmnhfeG1bWFjC1UsmlXIm2E/6HmmiKhKwVH2kGAE6UiBMFaFa4wtcOHyFGSvdbcIjDAHjvqguDcEa82k7bb0Ib8CgK4QQCZx0bN12IVlSjueBtv+EKXwX7/+xsEStRZiVUFgrz+EBDKDFgSQ846Twa+zryvo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=F2MFPtlY; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=H30wEn4L; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="F2MFPtlY"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="H30wEn4L" Date: Sat, 23 May 2026 11:37:34 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1779529055; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=Kmr3KveSTxTPHHuetgCIshAqmIBaWFqL2H8hTNbqQug=; b=F2MFPtlYSThCEucoy6oblTKBjZguS0eAlfo3onAmHmxBcc4jsVu0W0QwcPnxEfgPfEQ6eb Y0Ku96rXOvFFsJSJ4zaGhI3UBqMAEn3u/IvRwIYd4DXS1KxoldWAd8tkyG+ONoWWUMh0ZL 0aasgGxX8lJsmJ/fwCI0CNQJtn/L9ULfP/49iqTUFFhQaXfslV5KTV1AN1J5AGZegpc7T2 1MFCJnmLl3fJuStRlqzva6EQpjSkEEh7N2Mo0RzcB2EijUZSwitgqyNIpFI6UHY5vFiRBB jpcW7H3b1AxNBwc9BXeDlcEDpONSR6dj0RKzSbJDtEj129o+RH6T4eqKznG3xQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1779529055; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=Kmr3KveSTxTPHHuetgCIshAqmIBaWFqL2H8hTNbqQug=; b=H30wEn4LPQKnWqoZUKxhREagYoTxSQ0AFMr20dDEUAF6yHLpwjDhR0u8hXH9asDmqE7T3C v7O9xcAxDxYOemCg== From: Sebastian Andrzej Siewior To: linux-kernel@vger.kernel.org, x86@kernel.org Cc: "H. Peter Anvin" , Borislav Petkov , Dave Hansen , Ingo Molnar , Jonathan Corbet , Thomas Gleixner Subject: [PATCH] x86: Start removing X86_X32_ABI Message-ID: <20260523093734.A3AR7reJ@linutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 last syscall for x86_64 is currently at 471. The first x32 starts at 512 which leaves 40 new syscalls in between. Without the x32 ABI, those syscalls could be used since x32 wouldn't be an option and therefore reserved. Since there is practically no real use for x32, start removing it by removing the symbol first, not allowing to enable it. Should nothing happening within the next half year, lets remove code bits around August after the summer break. Signed-off-by: Sebastian Andrzej Siewior --- arch/x86/Kconfig | 14 -------------- 1 file changed, 14 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index f3f7cb01d69d0..2b246a6125768 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -3143,20 +3143,6 @@ config IA32_EMULATION_DEFAULT_DISABLED processes and access to 32-bit syscalls. If unsure, leave it to its default value. =20 -config X86_X32_ABI - bool "x32 ABI for 64-bit mode" - depends on X86_64 - # 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 - # https://github.com/ClangBuiltLinux/linux/issues/1141 - depends on $(success,$(OBJCOPY) --version | head -n1 | grep -qv llvm) - help - Include code to run binaries for the x32 native 32-bit ABI - for 64-bit processors. An x32 process gets access to the - full 64-bit register file and wide data path while leaving - pointers at 32 bits for smaller memory footprint. - config COMPAT_32 def_bool y depends on IA32_EMULATION || X86_32 --=20 2.53.0