[coreboot] REcon MTL 2017 talk on coreboot

[Nico Huber]

Hi Trammell,

On 26.07.2017 12:01, Trammell Hudson wrote:
> Yuriy Bulygin and Oleksandr Bazhaniuk's coreboot presentation at REcon
> Montreal 2017:
>
> https://recon.cx/2017/montreal/resources/slides/RECON-MTL-2017-DiggingIntoTheCoreOfBoot.pdf
>
> They recap the MMIO BAR issue (previously disclosed at REcon Brussles),
> and identified two new vulnerabilities (handling ACPI GNVS pointers
> during S3 resume, and an SMI handler that reads from an unprotected
> VGA MMIO register).
>
> They also identify that the /WP bit is not set on most non-chromebook
> coreboot installs and that PRR are not enabled by default.  They
> summarize this configuration as "super crazy developer mode", which has
> several drawbacks:
>
> * SMM based firmware write protection is off
> • SPI protected range registers are disabled
> • TCO and Global SMI are not locked down
> • SPI config is not locked
> • SMRAM can be DMA’d into

this "super crazy developer mode" is not intended, ofc. Though, also
not documented how to not run into it. The chipset initialization for
newer Intel chipsets (IIRC, since Sandy Bridge) has a finalization
procedure in the SMI handler that does all the locking. coreboot only
triggers this routine on the S3 resume path. Why? I suppose because the
(cros) firmware isn't finished after coreboot run but only after the
payload. So the payload is responsible to trigger the finalization on
the non-resume path. It's a simple `outb(0xcb, APMC);`, IIRC.

The finalization procedure usually doesn't lock the SPI flash. We added
some options to Sandy/Ivy Bridge (mistakenly called LOCK_SPI_ON_RESUME_)
but those were never ported to newer chipsets, AFAIK.

>
> Are there active reviews for the GNVS or VGA issues?  I don't see any
> on review.coreoot.org.

If Skylake is affected, I will have to tackle these if nobody beats me
to it. But my solution might turn into disabling SMM altogether if I
don't find any bug fixed in SMM that I'd care about. So nobody who de-
pends on SMM would benefit from my solution.

> For the non-chromebook configuration, what is the best practice?
> I can set PRR, TSEG, etc in my Linux payload, but is that too late?

Hmmm, good question. I usually advice against drawing Linux into the
trusted computing base due to its large attack surface. OTOH, if you
lock the platform before jumping into your Linux payload, how'd you
ever update the firmware?

Nico