For a security boundary, the question is "what can an OS potentially
do", not "what do we expect it to do".
Modification of the APIC_ID register is model specific, but prohibited
by the x2APIC spec. I presume that the SMM entry straps disambiguate by
the initial APIC ID, which is fixed, but I don't know for sure.
Since sending this email, I've come to the conclusion that deriving the
stack from the entry strap is probably a safer option than trying to
use/parse/modify the APIC.
As for x2APIC, any system with >254 cpus needs x2APIC (and Interrupt
Remapping) for the OS to be able to perform symmetric interrupt
handling, but OSes will turn it on if available, because it has a better
programming model (no waiting on status bits), and is easier to virtualise.
On 28/08/18 19:37, Lance Zhao wrote:
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 <mailto:firstname.lastname@example.org>> wrote:
While looking at some code, I noticed that twice (once in asm, and
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
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
x2apic mode (which is surely easier than switching APIC mode, as
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