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 <[email protected]> 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: [email protected] > https://mail.coreboot.org/mailman/listinfo/coreboot
-- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
