Hi all,
Can someone give me some hints or point me to some instructions please?
Machine: Lenovo X1 Carbon 1st Gen (2012, no Boot Guard) Flashing tool: CH341A USB programmer + Debian Linux
I am trying to replace the OEM firmware with Coreboot 4.12 and then install OpenBSD into the machine and set it up as an internet facing firewall. I ran me_cleaner against the dumped SPI image already.
1. Can anyone please tell let me know how can I achieve the captioned objectives? I looked into ifdtool & uefitool but found nothing related to my goal. I also tried the "lock ME/TXE" option during make menuconfig but Intel chipsec is still reporting the captioned bits not set on my Coreboot-flashed X1 Carbon
2. Is it correct to say that once the PR0-5 bits are set and Coreboot flashed into the machine, the values of the PR registers will be configured accordingly after machine boot up (when OS is having control)?
Thank you very much for looking into my questions!
Hello Alan,
On 31.05.20 06:20, Alan K.L. Mok wrote:
- Can anyone please tell let me know how can I achieve the captioned
objectives? I looked into ifdtool & uefitool but found nothing related to my goal. I also tried the "lock ME/TXE" option during make menuconfig but Intel chipsec is still reporting the captioned bits not set on my Coreboot-flashed X1 Carbon
this option sets access permissions in the Flash Descriptor (IFD). They act like the PR0-5 registers but on top of them.
The default settings (only valid ones as by Intel for production machines) will write-protect the IFD, read- and write-protect the ME region.
- Is it correct to say that once the PR0-5 bits are set and Coreboot
flashed into the machine, the values of the PR registers will be configured accordingly after machine boot up (when OS is having control)?
I'm not sure if I follow. Why do you call PR0-5 bits? those are registers that may or may not be filled with a flash range to protect. It is the host firmware's (coreboot's) responsibility to write these registers. But what values are to be written is up to you.
Chipsec is a nice tool to check what things are configured and how. But the user still has to know how these things work. Otherwise they might make wrong assumptions about security. One good example is the FLOCKDN (flash lockdown) bit. When it's set, one cannot change the flash controller's configuration (including PR0-5 ranges) anymore until the next reboot. But it doesn't tell you if the locked confi- guration is secure, only that it can't be changed.
BIOSWE, BLE, SMM_BWP & PR0-5 protection bits
BIOSWE, BLE, and SMM_BWP shift the blame from the OS to SMM (which is supposed to be controlled by the firmware). However, to my knowledge, nobody has yet achieved a secure SMM implementation. So many people ignore this. And IMHO, any good security concept shouldn't treat SMM more privileged than the OS.
If you want to set these bits anyway, have a look at your south- bridge's code (src/southbridge/intel/bd82x6x/lpc.c), around pch_disable_smm_only_flashing(). This function clears SMM_BWP, I guess.
The PR0-5 ranges can protect your flash efficiently, AFAIK. Not even SMM should be able to get around these. If you just want to write protect your whole flash chip (you won't be able to flash internally anymore), have a look at "Boot media protection mechanism" in the "Security" config menu. If set to "Lock boot media using the con- troller", it should use one of the PR0-5 ranges.
FLOCKDN should be set when "Lock down chipset in coreboot" ("Chipset" menu) is enabled.
Hope that helps, Nico
Hello Nico,
Thank you very much for your reply, it is informative and helpful!
I will read more regarding the PRx registers and try to compile with the menuconfig options you mentioned. Will also scrutinize the southbridge C code and see if I can comprehend it. I will report back again within the next few days.
Hope this email finds you are having a wonderful day, Alan
On Sun, May 31, 2020 at 6:01 PM Nico Huber nico.h@gmx.de wrote:
Hello Alan,
On 31.05.20 06:20, Alan K.L. Mok wrote:
- Can anyone please tell let me know how can I achieve the captioned
objectives? I looked into ifdtool & uefitool but found nothing related to my goal. I also tried the "lock ME/TXE" option during make menuconfig but Intel chipsec is still reporting the captioned bits not set on my Coreboot-flashed X1 Carbon
this option sets access permissions in the Flash Descriptor (IFD). They act like the PR0-5 registers but on top of them.
The default settings (only valid ones as by Intel for production machines) will write-protect the IFD, read- and write-protect the ME region.
- Is it correct to say that once the PR0-5 bits are set and Coreboot
flashed into the machine, the values of the PR registers will be
configured
accordingly after machine boot up (when OS is having control)?
I'm not sure if I follow. Why do you call PR0-5 bits? those are registers that may or may not be filled with a flash range to protect. It is the host firmware's (coreboot's) responsibility to write these registers. But what values are to be written is up to you.
Chipsec is a nice tool to check what things are configured and how. But the user still has to know how these things work. Otherwise they might make wrong assumptions about security. One good example is the FLOCKDN (flash lockdown) bit. When it's set, one cannot change the flash controller's configuration (including PR0-5 ranges) anymore until the next reboot. But it doesn't tell you if the locked confi- guration is secure, only that it can't be changed.
BIOSWE, BLE, SMM_BWP & PR0-5 protection bits
BIOSWE, BLE, and SMM_BWP shift the blame from the OS to SMM (which is supposed to be controlled by the firmware). However, to my knowledge, nobody has yet achieved a secure SMM implementation. So many people ignore this. And IMHO, any good security concept shouldn't treat SMM more privileged than the OS.
If you want to set these bits anyway, have a look at your south- bridge's code (src/southbridge/intel/bd82x6x/lpc.c), around pch_disable_smm_only_flashing(). This function clears SMM_BWP, I guess.
The PR0-5 ranges can protect your flash efficiently, AFAIK. Not even SMM should be able to get around these. If you just want to write protect your whole flash chip (you won't be able to flash internally anymore), have a look at "Boot media protection mechanism" in the "Security" config menu. If set to "Lock boot media using the con- troller", it should use one of the PR0-5 ranges.
FLOCKDN should be set when "Lock down chipset in coreboot" ("Chipset" menu) is enabled.
Hope that helps, Nico
-
Alan K.L. Mok -
Nico Huber