[coreboot] REcon MTL 2017 talk on coreboot

[ron minnich]

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.

On Wed, Jul 26, 2017 at 1:42 PM Nico Huber <nico.h at gmx.de> wrote:

> 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
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170726/f302bf57/attachment.html>