Fw: xAPIC deprecation plan - concerns from a bootloader/OS developer

[mintsuki]

Forwarding to LKML after sending it to x86@xxxxxxxxxx for wider visibility.

------- Forwarded Message -------
From: mintsuki <mintsuki@xxxxxxxxxxxxxx>
Date: On Wednesday, February 18th, 2026 at 11:30 AM
Subject: xAPIC deprecation plan - concerns from a bootloader/OS developer
To: x86@xxxxxxxxxx <x86@xxxxxxxxxx>


> Hi all,
> 
> I'm the author of Limine, a multiprotocol bootloader that handles SMP bring-up across a wide range of x86 hardware. I wanted to raise some concerns about Intel's xAPIC deprecation plan and its real-world impact on the x86 ecosystem.
> 
> The deprecation is apparently motivated by AEPIC Leak (CVE-2022-21233), where reads to undefined offsets in the xAPIC MMIO page return stale data from the cache hierarchy. This is a serious issue for SGX, since the SGX threat model assumes a hostile OS that can freely access MMIO. The recommended mitigation is to use x2APIC mode, which replaces the MMIO interface with MSR-based access.
> 
> However, this vulnerability is specific to Intel's microarchitectural implementation. It is not an architectural flaw in the xAPIC specification itself. AMD implements xAPIC MMIO correctly and has no equivalent vulnerability, no deprecation plan, and no intention of removing xAPIC support. The bug was also fixed in silicon starting with Sapphire Rapids. So the deprecation is not addressing a fundamental design problem - it is using an Intel-specific implementation bug as justification for an architecture-wide compatibility break.
> 
> One could have argued that the xAPIC deprecation was a stepping stone toward X86S, Intel's proposal to strip legacy modes from the architecture entirely, but X86S was killed in December 2024 after the formation of the x86 Ecosystem Advisory Group, which now requires Intel and AMD to collaborate on ISA changes. With X86S off the table, the xAPIC deprecation no longer serves any broader architectural simplification goal - it's just a standalone compatibility break with no clear endgame beyond itself.
> 
> The practical consequences are already causing problems. On Phase 2a platforms (Arrow Lake, Lunar Lake), motherboard vendors have introduced BIOS toggles to "disable x2APIC" for compatibility with older operating systems. But because of the one-way lock mechanism (IA32_XAPIC_DISABLE_STATUS), these toggles don't just boot the system in xAPIC mode with the option to switch to x2APIC later - they lock the system out of x2APIC entirely. The OS cannot enable x2APIC at runtime because the BIOS hides the capability (likely via CPUID masking or DMAR opt-out flags). So instead of a graceful "xAPIC by default, x2APIC available," users get a binary choice between "x2APIC locked on forever" and "x2APIC hidden forever".
> 
> This creates a situation where:
> 
> - Operating systems that don't support x2APIC (Windows Vista and older, Windows Server 2008 and older, or Linux kernels before 2.6.28) simply cannot boot on locked x2APIC hardware, since their MMIO-based APIC access silently fails.
> - Bootloaders have to detect whether firmware has already locked x2APIC and adjust their SMP trampoline accordingly, since APs preserve x2APIC mode across INIT.
> - The BIOS "compatibility" toggle doesn't actually provide compatibility - it just trades one problem for another.
> 
> I think the right approach would have been to fix the silicon (which Intel already did), mandate x2APIC for SGX/TDX platforms specifically (which makes sense), and leave the rest of the ecosystem alone. Instead, the deprecation plan marches toward Phase 4 (Nova Lake / Diamond Rapids) where xAPIC is removed from the processor entirely, breaking backward compatibility for every OS and bootloader that hasn't been updated, for no clear architectural reason.
> 
> I'd be interested to hear whether there has been any discussion within the x86 EAG or the kernel community about pushing back on this, or whether this is considered a settled matter. From where I sit, the ecosystem is paying a real cost for an Intel-specific bug that has already been fixed.
> 
> Thanks for your time.