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.
~Andrew
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@citrix.com mailto:andrew.cooper3@citrix.com> wrote:
Hello, 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 boundary. Is this something you care about? Thanks, ~Andrew -- coreboot mailing list: coreboot@coreboot.org <mailto:coreboot@coreboot.org> https://mail.coreboot.org/mailman/listinfo/coreboot