Re: Question how to write protect flash

[Public Email Account]

Yes its sandy bridge. What is proper way to do this though. On flash descriptor (and if so, how?) or through coreboot option?

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, July 15, 2019 12:37 AM, [e-mail]  wrote:
> IIRC X220 uses Sandy Bridge. I think there is a flag somewhere in the descriptor where you can lock down your BIOS-region as read-only for the x86 host.
> I never have tried it but in theory this should lead to errors on every write attempt to the BIOS region therefore disabling write access to the flash from OS/flashrom.
>
> Werner

Question how to write protect flash

[Trammell Hudson]

There are several ways to lock the flash. Two are "permanent":

* Flash descriptor permission bits in the IFD
* SPI flash chip non-volatile Block Protect Bits and grounding the !WP pin

The IFD in the image that you're going to flash can be modified with ifdtool. I'm not sure of the best way to set the BP bits without an external programmer that exposes the SPI commands.

And some can be set at runtime during the boot:

* BIOS_CNTL.BIOSWE + BIOS_CNTL.BLE + BIOS_CNTL.SMM_BWP (SMM can still write parts of flash)
* Protected Range Registers (PRR, not even SMM can bypass them)

In the kconfig menu you can select "Protect flash regions" or "Flash write protect during lockdown", although I'm not positive which of the runtime features it enables.  Which version of coreboot are you building?

In any event, the x220 does not have Bootguard, so a proximate attacker could rewrite the flash chip contents with an external programmer regardless of these protections.  Hopefully that is compatible with your threat model.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, July 15, 2019 6:19 PM, Public Email Account via coreboot  wrote:
> Yes its sandy bridge. What is proper way to do this though. On flash descriptor (and if so, how?) or through coreboot option?
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, July 15, 2019 12:37 AM, [e-mail] [e-mail] wrote:
> > IIRC X220 uses Sandy Bridge. I think there is a flag somewhere in the descriptor where you can lock down your BIOS-region as read-only for the x86 host.
> > I never have tried it but in theory this should lead to errors on every write attempt to the BIOS region therefore disabling write access to the flash from OS/flashrom.
> > Werner
>
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

Question how to write protect flash

[Public Email Account]

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, July 15, 2019 1:45 PM, Trammell Hudson  wrote:
> There are several ways to lock the flash. Two are "permanent":

This is what I'm worried about. I dont want to break anything by preventing any future flashing. I just want to prevent internal flashing.
> In any event, the x220 does not have Bootguard, so a proximate attacker could rewrite the flash chip contents with an external programmer regardless of these protections. Hopefully that is compatible with your threat model.

This does not matter. I have physical tamper detection on the computer. So even if someone did use an external flasher I would detect it.

Question how to write protect flash

[Public Email Account]

> In the kconfig menu you can select "Protect flash regions" or "Flash write protect during lockdown", although I'm not positive which of the runtime features it enables. Which version of coreboot are you building?

I do not know what version of coreboot, probably latest version since I build from source. Could you explain what these two options do? Would this accomplish what I am wanting to do (prevent internal flashing but still allow external flashing)?

Thank you

Question how to write protect flash

You have to do it with the descriptor.

Have a look at the corresponding "SPI Programming Guide" (e.g. http://www.corus.pro/pilotes/CorusX/X37/XP/ME/SPI%20Programming%20Guide.pdf)
Here you can find how the sections are defined and how the section access is configurable. You can find details in chapter 4.1.4 where access to your BIOS region should be controlled in register "FLMSTR1—Flash Master 1 (Host CPU/ BIOS)". And as the descriptor has no data integrity checksum, you can just change the needed bits and give it  a try.

But make sure you still have a way to flash your device with the external programmer to have a way to recover.

I hope this helps.
Werner

-----Ursprüngliche Nachricht-----
Von: Public Email Account 
Gesendet: Montag, 15. Juli 2019 18:19
An: Zeh, Werner (DI MC MTS R&D HW 1) 
Cc: [e-mail]
Betreff: Re: AW: [coreboot] Re: Question how to write protect flash

Yes its sandy bridge. What is proper way to do this though. On flash descriptor (and if so, how?) or through coreboot option?

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, July 15, 2019 12:37 AM, [e-mail]  wrote:
> IIRC X220 uses Sandy Bridge. I think there is a flag somewhere in the descriptor where you can lock down your BIOS-region as read-only for the x86 host.
> I never have tried it but in theory this should lead to errors on every write attempt to the BIOS region therefore disabling write access to the flash from OS/flashrom.
>
> Werner

Question how to write protect flash

[Simon Newton]

On 16/07/2019 00:45, Public Email Account via coreboot wrote:
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, July 15, 2019 1:45 PM, Trammell Hudson  wrote:
> > There are several ways to lock the flash. Two are "permanent":
>
> This is what I'm worried about. I dont want to break anything by preventing any future flashing. I just want to prevent internal flashing.

Trammell knows his stuff in this regard. I did a lot of work on the x220 
as my threat model contained the presumption that an actor would persist 
via firmware where possible. This led me to Trammels heads firmware work 
(which, if your threat model is talking about firmware read only, I 
suggest you check out heads as its going to go that extra mile for you). 
I believe that the meaning of "permanent" here does not mean the chip is 
never usable again. Its "permanent" in the fact that only someone with 
physical access could get around it. Use IFDtool to lock the image down, 
flash it and ground the WP pin. nothing should be able to write to it then.

Something that is overlooked is, even when neutered, no one really knows 
if ME has write access to flash stuff. It shouldnt be a problem with WP 
grounded - but I do go a little bit further and use a hex editor to zero 
out the VSCC table in the firmware before flashing. The ME, or whats 
left of it, then has no idea which chip its working with and the intel 
docs imply ME will not communicate with chip. Folks testing show it also 
causes ME to not come up either.. 
https://github.com/corna/me_cleaner/issues/80
> >  In any event, the x220 does not have Bootguard, so a proximate attacker could rewrite the flash chip contents with an external programmer regardless of these protections. Hopefully that is compatible with your threat model.
>
> This does not matter. I have physical tamper detection on the computer. So even if someone did use an external flasher I would detect it.

Peronsally I use warranty seals with long unique serial numbers, to make 
the physical side tamper evident. Cheap and easy.
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]