Fwd: Anyway to change BIOSWE, BLE, SMM_BWP & PR0-5 protection bits?

[Alan K.L. Mok]

Hi Nico,

Sorry for this late report. I am still fiddling with the coreboot code to
setup the SMM_BWP bit you suggested but with not much progress.

Beside the SMM_BWP, I followed your recommendation and was able to
successfully turn on the PR0 & FLOCKDN protections. I can confirm these by
running chipsec against the compiled image.
[chipsec_main@Controller_locked.txt]

I think I am fine at the moment and am somehow confident to put my X1
Carbon onto the internet. I will further explore coreboot codes for
additional flash memory write protections on my own.

I just want to express my gratitude for your help and towards the people
who make this project even possible and freely available to the whole
world, Thank you!!

My warmest regards,
Alan

---------- Forwarded message ---------
From: Alan K.L. Mok 
Date: Sat, Jun 6, 2020 at 5:35 PM
Subject: Fwd: [coreboot] Anyway to change BIOSWE, BLE, SMM_BWP & PR0-5
protection bits?
To: ,

Hello Nico,

Just a quick update that the platform I rely on (Debian 11 testing live)
for Coreboot compilation messed up itself after package updates and my
progress is retarded.
[Debian.jpg]

I had some readings on the PRx registers and now I understand that those
are registers accepting base, limit & range of address in memory to protect
from read/write and is provided and enforced by the SPI controller. I
completely agree with you that the protection bits I asked in my previous
email are not effective security measures since SMM code is privileged
enough to freely change those bits anytime and as you mentioned there is
presently not yet any secure SMM implementation (I think that the UEFI spec
makes everyones' life more difficult.....).

I will report back in next week on the menu makeconfig options you
mentioned in your previous email.

Thanks for your help,
Alan

---------- Forwarded message ---------
From: Alan K.L. Mok 
Date: Sun, May 31, 2020 at 11:56 PM
Subject: Re: [coreboot] Anyway to change BIOSWE, BLE, SMM_BWP & PR0-5
protection bits?
To: Nico Huber 
Cc:

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  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