<div dir="ltr">There's a lot of interest in the work I'm doing now in turning SMM of completely. The 16-bit nature of the handler is a real issue. So I'd be very interested in seeing it disabled.</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 26, 2017 at 1:42 PM Nico Huber <<a href="mailto:nico.h@gmx.de">nico.h@gmx.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Trammell,<br>
<br>
On 26.07.2017 12:01, Trammell Hudson wrote:<br>
> Yuriy Bulygin and Oleksandr Bazhaniuk's coreboot presentation at REcon<br>
> Montreal 2017:<br>
><br>
> <a href="https://recon.cx/2017/montreal/resources/slides/RECON-MTL-2017-DiggingIntoTheCoreOfBoot.pdf" rel="noreferrer" target="_blank">https://recon.cx/2017/montreal/resources/slides/RECON-MTL-2017-DiggingIntoTheCoreOfBoot.pdf</a><br>
><br>
> They recap the MMIO BAR issue (previously disclosed at REcon Brussles),<br>
> and identified two new vulnerabilities (handling ACPI GNVS pointers<br>
> during S3 resume, and an SMI handler that reads from an unprotected<br>
> VGA MMIO register).<br>
><br>
> They also identify that the /WP bit is not set on most non-chromebook<br>
> coreboot installs and that PRR are not enabled by default.  They<br>
> summarize this configuration as "super crazy developer mode", which has<br>
> several drawbacks:<br>
><br>
> * SMM based firmware write protection is off<br>
> • SPI protected range registers are disabled<br>
> • TCO and Global SMI are not locked down<br>
> • SPI config is not locked<br>
> • SMRAM can be DMA’d into<br>
<br>
this "super crazy developer mode" is not intended, ofc. Though, also<br>
not documented how to not run into it. The chipset initialization for<br>
newer Intel chipsets (IIRC, since Sandy Bridge) has a finalization<br>
procedure in the SMI handler that does all the locking. coreboot only<br>
triggers this routine on the S3 resume path. Why? I suppose because the<br>
(cros) firmware isn't finished after coreboot run but only after the<br>
payload. So the payload is responsible to trigger the finalization on<br>
the non-resume path. It's a simple `outb(0xcb, APMC);`, IIRC.<br>
<br>
The finalization procedure usually doesn't lock the SPI flash. We added<br>
some options to Sandy/Ivy Bridge (mistakenly called LOCK_SPI_ON_RESUME_)<br>
but those were never ported to newer chipsets, AFAIK.<br>
<br>
><br>
> Are there active reviews for the GNVS or VGA issues?  I don't see any<br>
> on <a href="http://review.coreoot.org" rel="noreferrer" target="_blank">review.coreoot.org</a>.<br>
<br>
If Skylake is affected, I will have to tackle these if nobody beats me<br>
to it. But my solution might turn into disabling SMM altogether if I<br>
don't find any bug fixed in SMM that I'd care about. So nobody who de-<br>
pends on SMM would benefit from my solution.<br>
<br>
> For the non-chromebook configuration, what is the best practice?<br>
> I can set PRR, TSEG, etc in my Linux payload, but is that too late?<br>
<br>
Hmmm, good question. I usually advice against drawing Linux into the<br>
trusted computing base due to its large attack surface. OTOH, if you<br>
lock the platform before jumping into your Linux payload, how'd you<br>
ever update the firmware?<br>
<br>
Nico<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></blockquote></div>