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