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.coop...@citrix.com <mailto:andrew.coop...@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 >
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot