<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">For a security boundary, the question
is "what can an OS potentially do", not "what do we expect it to
do".<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
~Andrew<br>
<br>
On 28/08/18 19:37, Lance Zhao wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAO1KNFhKAjv+o2DmwOUfd9xag7Mbxbi6W6+K8rigY5rq7M31Og@mail.gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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"
moz-do-not-send="true">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" moz-do-not-send="true">coreboot@coreboot.org</a><br>
<a href="https://mail.coreboot.org/mailman/listinfo/coreboot"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://mail.coreboot.org/mailman/listinfo/coreboot</a><br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>