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 <nic...@gmx.de> wrote:
> Hello Alan,
>
> On 31.05.20 06:20, Alan K.L. Mok wrote:
> > 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
>
> 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.
>
> > 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)?
>
> 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
>
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
