Public bug reported:
[ Impact ]
* In Kernels with commit ec9aedb2aa1a (6.7) CPUs can be enumerated in the order
which violates ACPI specification that states:
"OSPM should initialize processors in the order that they appear in the
MADT"
* The problematic commit parses all LAPIC entries before any x2APIC
entries, aiming to ignore x2APIC entries with APIC ID < 255 when valid
LAPIC entries exist. However, it disrupts the CPU enumeration order on
systems where x2APIC entries precede LAPIC entries in the MADT.
* In scenarios with strict CPU pinning this behavior might introduce
performance degradation or hyperthreading related side-channel
vulnerabilities
* Issue has been fixed upstream with commit 0141978ae75
[ Test Plan ]
* Issue reproduces only in specific ACPI MADT configurations with
mixed LAPIC and x2APIC entries. An example of it would be AMD Genoa CPUs.
* Easiest way to reproduce it locally is to replace x2APIC entry
before LAPIC in MADT table.
Steps to reproduce (local VM):
1. Set up a VM with 288 vCPUs
sudo qemu-system-x86_64 -enable-kvm \
-M q35,accel=kvm,kernel-irqchip=split \
-device intel-iommu,intremap=on \
-smp 288,cores=144,threads=1,sockets=2 \
-m 20G \
-cpu host \
-object memory-backend-ram,id=mem0,size=10G \
-object memory-backend-ram,id=mem1,size=10G \
-numa node,cpus=0-143,nodeid=0,memdev=mem0 \
-numa node,cpus=144-287,nodeid=1,memdev=mem1 \
-drive file=/var/lib/libvirt/images/ubuntu24.04.qcow2,format=qcow2 \
-boot d
2. Dump acpi apic/madt tables from VM
acpidump > acpidump.dat
acpixtract -a acpidump.dat
iasl -d apic.dat
----
apic.dsl file will be generated.
3. Craft apic.dsl and switch order of CPUs
4. Compile apic.dsl to aml file
iasl -tc apic.dsl
5. Inject new table to VM
sudo qemu-system-x86_64 -enable-kvm \
-M q35,accel=kvm,kernel-irqchip=split \
-device intel-iommu,intremap=on \
-smp 288,cores=144,threads=1,sockets=2 \
-acpitable file=apic.aml \
-m 20G \
-cpu host \
-object memory-backend-ram,id=mem0,size=10G \
-object memory-backend-ram,id=mem1,size=10G \
-numa node,cpus=0-143,nodeid=0,memdev=mem0 \
-numa node,cpus=144-287,nodeid=1,memdev=mem1 \
-drive file=/var/lib/libvirt/images/ubuntu24.04.qcow2,format=qcow2 \
-boot d
Results:
Depending on MADT changes. For following example I have moved single x2APIC
entry
after the first LAPIC.
Incorrect enumeration present on 6.8 Kernels:
NUMA node(s): 2
NUMA node0 CPU(s): 0-143
NUMA node1 CPU(s): 144-287
Enumeration on 6.8 Kernel with applied fixes:
NUMA node(s): 2
NUMA node0 CPU(s): 0,2-144
NUMA node1 CPU(s): 1,145-287
[ Where problems could occur ]
* Fix has been tested using alocal VM with a modified MADT table.
* MADT table can have multiple possible configurations, making it hard to
fully test the fix.
* Potential regression with CPU enumeration can be hard to detect as was in
case of
patch that introduced the issue.
[ Other Info ]
* Patch which introduced an issue: ec9aedb2aa1ab7ac420c00b31f5edc5be15ec167
* Patch fixing the issue: 0141978ae75bd48bac13fca6de131a5071c32011
* Originally issue has been reported for AMD Genoa CPU with following
enumeration:
6.5.0
NUMA node(s): 2
NUMA node0 CPU(s): 0-89,180-269
NUMA node1 CPU(s): 90-179,270-359
6.8.0
NUMA node(s): 2
NUMA node0 CPU(s): 0-179
NUMA node1 CPU(s): 180-359
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Affects: linux (Ubuntu Noble)
Importance: Undecided
Status: New
** Affects: linux (Ubuntu Oracular)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Noble)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Oracular)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2097455
Title:
Incorrect LAPIC/x2APIC parsing order
Status in linux package in Ubuntu:
New
Status in linux source package in Noble:
New
Status in linux source package in Oracular:
New
Bug description:
[ Impact ]
* In Kernels with commit ec9aedb2aa1a (6.7) CPUs can be enumerated in the
order
which violates ACPI specification that states:
"OSPM should initialize processors in the order that they appear in the
MADT"
* The problematic commit parses all LAPIC entries before any x2APIC
entries, aiming to ignore x2APIC entries with APIC ID < 255 when valid
LAPIC entries exist. However, it disrupts the CPU enumeration order on
systems where x2APIC entries precede LAPIC entries in the MADT.
* In scenarios with strict CPU pinning this behavior might introduce
performance degradation or hyperthreading related side-channel
vulnerabilities
* Issue has been fixed upstream with commit 0141978ae75
[ Test Plan ]
* Issue reproduces only in specific ACPI MADT configurations with
mixed LAPIC and x2APIC entries. An example of it would be AMD Genoa CPUs.
* Easiest way to reproduce it locally is to replace x2APIC entry
before LAPIC in MADT table.
Steps to reproduce (local VM):
1. Set up a VM with 288 vCPUs
sudo qemu-system-x86_64 -enable-kvm \
-M q35,accel=kvm,kernel-irqchip=split \
-device intel-iommu,intremap=on \
-smp 288,cores=144,threads=1,sockets=2 \
-m 20G \
-cpu host \
-object memory-backend-ram,id=mem0,size=10G \
-object memory-backend-ram,id=mem1,size=10G \
-numa node,cpus=0-143,nodeid=0,memdev=mem0 \
-numa node,cpus=144-287,nodeid=1,memdev=mem1 \
-drive file=/var/lib/libvirt/images/ubuntu24.04.qcow2,format=qcow2 \
-boot d
2. Dump acpi apic/madt tables from VM
acpidump > acpidump.dat
acpixtract -a acpidump.dat
iasl -d apic.dat
----
apic.dsl file will be generated.
3. Craft apic.dsl and switch order of CPUs
4. Compile apic.dsl to aml file
iasl -tc apic.dsl
5. Inject new table to VM
sudo qemu-system-x86_64 -enable-kvm \
-M q35,accel=kvm,kernel-irqchip=split \
-device intel-iommu,intremap=on \
-smp 288,cores=144,threads=1,sockets=2 \
-acpitable file=apic.aml \
-m 20G \
-cpu host \
-object memory-backend-ram,id=mem0,size=10G \
-object memory-backend-ram,id=mem1,size=10G \
-numa node,cpus=0-143,nodeid=0,memdev=mem0 \
-numa node,cpus=144-287,nodeid=1,memdev=mem1 \
-drive file=/var/lib/libvirt/images/ubuntu24.04.qcow2,format=qcow2 \
-boot d
Results:
Depending on MADT changes. For following example I have moved single
x2APIC entry
after the first LAPIC.
Incorrect enumeration present on 6.8 Kernels:
NUMA node(s): 2
NUMA node0 CPU(s): 0-143
NUMA node1 CPU(s): 144-287
Enumeration on 6.8 Kernel with applied fixes:
NUMA node(s): 2
NUMA node0 CPU(s): 0,2-144
NUMA node1 CPU(s): 1,145-287
[ Where problems could occur ]
* Fix has been tested using alocal VM with a modified MADT table.
* MADT table can have multiple possible configurations, making it hard to
fully test the fix.
* Potential regression with CPU enumeration can be hard to detect as was in
case of
patch that introduced the issue.
[ Other Info ]
* Patch which introduced an issue: ec9aedb2aa1ab7ac420c00b31f5edc5be15ec167
* Patch fixing the issue: 0141978ae75bd48bac13fca6de131a5071c32011
* Originally issue has been reported for AMD Genoa CPU with following
enumeration:
6.5.0
NUMA node(s): 2
NUMA node0 CPU(s): 0-89,180-269
NUMA node1 CPU(s): 90-179,270-359
6.8.0
NUMA node(s): 2
NUMA node0 CPU(s): 0-179
NUMA node1 CPU(s): 180-359
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2097455/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
