Yuriy Bulygin and Oleksandr Bazhaniuk's coreboot presentation at REcon Montreal 2017:
https://recon.cx/2017/montreal/resources/slides/RECON-MTL-2017-DiggingIntoTh...
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
Are there active reviews for the GNVS or VGA issues? I don't see any on review.coreoot.org.
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?
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-DiggingIntoTh...
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
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@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-DiggingIntoTh...
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@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
-
Nico Huber -
ron minnich -
Trammell Hudson