Without x2apic mode, APIC_ID register will not be moved by OS. Those
address normally had been tagged as reserved and will not be touched. I
believe that x2apic will apply for processors number more than 255, so
majority cases in coreboot didn't touch that area yet.
On Tue, Aug 28, 2018 at 7:50 AM Andrew Cooper <andrew.cooper3(a)citrix.com>
While looking at some code, I noticed that twice (once in asm, and again
later in C), the SMM handler assumes that 0xfee00020 is the APIC_ID
reigster in the xAPIC MMIO window.
This isn't true if the OS has moved the MMIO window, or switched to
x2apic mode (on supporting hardware).
As a result, it looks like its rather easy to feed a kernel-controlled
value into Coreboot's idea of its Local APIC id, which can either be the
same on all cores (reuse of the same stack) or wildly out of range
(albeit, at least bounded to 255).
To fix, I'd expect Coreboot to read MSR_APIC_BASE, and either cope with
x2apic mode (which is surely easier than switching APIC mode, as you've
got to cycle through off to switch back to xAPIC mode), or
save/remap/restore the APIC MMIO window.
Without paging, you can't address an APIC MMIO window above the 4G
Is this something you care about?
coreboot mailing list: coreboot(a)coreboot.org