<div dir="ltr">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.<div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 28, 2018 at 7:50 AM Andrew Cooper <<a href="mailto:andrew.cooper3@citrix.com">andrew.cooper3@citrix.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
While looking at some code, I noticed that twice (once in asm, and again<br>
later in C), the SMM handler assumes that 0xfee00020 is the APIC_ID<br>
reigster in the xAPIC MMIO window.<br>
<br>
This isn't true if the OS has moved the MMIO window, or switched to<br>
x2apic mode (on supporting hardware).<br>
<br>
As a result, it looks like its rather easy to feed a kernel-controlled<br>
value into Coreboot's idea of its Local APIC id, which can either be the<br>
same on all cores (reuse of the same stack) or wildly out of range<br>
(albeit, at least bounded to 255).<br>
<br>
To fix, I'd expect Coreboot to read MSR_APIC_BASE, and either cope with<br>
x2apic mode (which is surely easier than switching APIC mode, as you've<br>
got to cycle through off to switch back to xAPIC mode), or<br>
save/remap/restore the APIC MMIO window.<br>
<br>
Without paging, you can't address an APIC MMIO window above the 4G boundary.<br>
<br>
Is this something you care about?<br>
<br>
Thanks,<br>
<br>
~Andrew<br>
<br>
-- <br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
<a href="https://mail.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://mail.coreboot.org/mailman/listinfo/coreboot</a><br>
</blockquote></div>