[coreboot] SPI controller and Lock bits

[Youness Alaoui]

Hi,

I'm trying to add a way to lock the SPI flash to be read-only via
software *after* coreboot boots. The scenario is basically with using
Heads, you could authenticate to it (with a yubikey/nitrokey/librem
key) then be able to flash a new rom (update your BIOS), but once you
boot an OS, Heads would first lock the flash so it can't be written
to.
This should add some security to avoid any malware writing to the
flash, or someone booting into a USB stick and using that to flash a
malicious BIOS, but still gives the user the freedom of updating their
flash whenever they want to.

The problem is that I can't make the flash read-only because the SPI
interface is already locked down by coreboot (see
src/soc/intel/skylake/lockdown.c and
src/soc/intel/common/block/fast_spi/fast_spi.c).

There's a couple of things happening here :
First, the FLOCKDN bit is set which prevents us from enabling the
write protection. the BIOS Interface lock down is controlled by the
chipset_lockdown config variable, but the FLOCKDN is not behind a
config variable.
The second thing is that if I wanted to use the protected ranges
feature to lock specific regions, they are all getting locked using
the discrete lock register even while being unused. The locking of the
protected ranges was added in this change :
https://review.coreboot.org/c/coreboot/+/21064 and it passed without
notice among the move that the commit was supposed to do.

The commit states that the lockdown is meant to "support platform
security guidelines", but I think that this is not actually good
because coreboot leaves everything read-write and locks down the
registers so we can't make it read-only. I think that the security
guidelines would say to disable the write protection before locking
the registers down.

Either way, I'm going to need to add a way to make this configurable,
so my main questions here are :
- Should I create a new config variable to decide on whether or not to
lock the spi registers and another one to decide on whether or not to
lock the protected ranges ?
- Should I make the chipset_lockdown (currently used for locking the
BIOS CNTL register from LPC and SPI controllers) into an OR-ed flags
variable where we can say : chipset_lockdown = LOCKDOWN_COREBOOT |
LOCKDOWN_SPI | LOCKDOWN_PROTECTED_RANGES ?
- Should I make a single new config variable to decide what to
lockdown (LPC_BIOS, SPI_BIOS, SPI_BAR, SPI_PROTECTED_RANGES) and only
set them if the CHIPSET_LOCKDOWN_COREBOOT is set ? And if
chipset_lockdown is set to CHIPSET_LOCKDOWN_FSP not lockdown anything
at all ?
- Do we want to keep the protected ranges locked down at all, have
them configurable or completely remove that as I don't see the point
in using the discrete lock register ?

Once I see a consensus on what's the best way to move forward, I'll
implement it and push it for review.

Note: I think these only affect hardware sequencing though so I assume
someone could always use software sequencing to do the writes. As long
as the FLOCKDN bit isn't set though, I could remove all write-related
opcodes from the software sequencing register, which would also
prevent someone using swseq to do writes.

Thanks,
Youness.

[Patrick Rudolph]

Hi Youness,

Post by Youness Alaoui
Hi,
I'm trying to add a way to lock the SPI flash to be read-only via
software *after* coreboot boots. The scenario is basically with using
Heads, you could authenticate to it (with a yubikey/nitrokey/librem
key) then be able to flash a new rom (update your BIOS), but once you
boot an OS, Heads would first lock the flash so it can't be written
to.
This should add some security to avoid any malware writing to the
flash, or someone booting into a USB stick and using that to flash a
malicious BIOS, but still gives the user the freedom of updating their
flash whenever they want to.
The problem is that I can't make the flash read-only because the SPI
interface is already locked down by coreboot (see
src/soc/intel/skylake/lockdown.c and
src/soc/intel/common/block/fast_spi/fast_spi.c).
First, the FLOCKDN bit is set which prevents us from enabling the
write protection. the BIOS Interface lock down is controlled by the
chipset_lockdown config variable, but the FLOCKDN is not behind a
config variable.
The second thing is that if I wanted to use the protected ranges
feature to lock specific regions, they are all getting locked using
the discrete lock register even while being unused. The locking of the
https://review.coreboot.org/c/coreboot/+/21064 and it passed without
notice among the move that the commit was supposed to do.
The commit states that the lockdown is meant to "support platform
security guidelines", but I think that this is not actually good
because coreboot leaves everything read-write and locks down the
registers so we can't make it read-only. I think that the security
guidelines would say to disable the write protection before locking
the registers down.

Feel free to propose a new "security guideline", but document it in the
tree.

A similar mechanism is already implemented on Intel:
https://review.coreboot.org/#/c/coreboot/+/21327/

Feel free to make it configurable on intel/soc, too.

Post by Youness Alaoui
Either way, I'm going to need to add a way to make this configurable,
- Should I create a new config variable to decide on whether or not to
lock the spi registers and another one to decide on whether or not to
lock the protected ranges ?
- Should I make the chipset_lockdown (currently used for locking the
BIOS CNTL register from LPC and SPI controllers) into an OR-ed flags
variable where we can say : chipset_lockdown = LOCKDOWN_COREBOOT |
LOCKDOWN_SPI | LOCKDOWN_PROTECTED_RANGES ?
- Should I make a single new config variable to decide what to
lockdown (LPC_BIOS, SPI_BIOS, SPI_BAR, SPI_PROTECTED_RANGES) and only
set them if the CHIPSET_LOCKDOWN_COREBOOT is set ? And if
chipset_lockdown is set to CHIPSET_LOCKDOWN_FSP not lockdown anything
at all ?
- Do we want to keep the protected ranges locked down at all, have
them configurable or completely remove that as I don't see the point
in using the discrete lock register ?

The protected ranges will be used on non Chromeos devices to support
vboot. A common interface is being worked on right now, but it'll take
some time.

Post by Youness Alaoui
Once I see a consensus on what's the best way to move forward, I'll
implement it and push it for review.
Note: I think these only affect hardware sequencing though so I assume
someone could always use software sequencing to do the writes. As long
as the FLOCKDN bit isn't set though, I could remove all write-related
opcodes from the software sequencing register, which would also
prevent someone using swseq to do writes.
Thanks,
Youness.

[Nico Huber]

Post by Patrick Rudolph
Hi Youness,

Post by Youness Alaoui
Hi,
I'm trying to add a way to lock the SPI flash to be read-only via
software *after* coreboot boots. The scenario is basically with using
Heads, you could authenticate to it (with a yubikey/nitrokey/librem
key) then be able to flash a new rom (update your BIOS), but once you
boot an OS, Heads would first lock the flash so it can't be written
to.
This should add some security to avoid any malware writing to the
flash, or someone booting into a USB stick and using that to flash a
malicious BIOS, but still gives the user the freedom of updating their
flash whenever they want to.
The problem is that I can't make the flash read-only because the SPI
interface is already locked down by coreboot (see
src/soc/intel/skylake/lockdown.c and
src/soc/intel/common/block/fast_spi/fast_spi.c).
First, the FLOCKDN bit is set which prevents us from enabling the
write protection. the BIOS Interface lock down is controlled by the
chipset_lockdown config variable, but the FLOCKDN is not behind a
config variable.
The second thing is that if I wanted to use the protected ranges
feature to lock specific regions, they are all getting locked using
the discrete lock register even while being unused. The locking of the
https://review.coreboot.org/c/coreboot/+/21064 and it passed without
notice among the move that the commit was supposed to do.
The commit states that the lockdown is meant to "support platform
security guidelines", but I think that this is not actually good
because coreboot leaves everything read-write and locks down the
registers so we can't make it read-only. I think that the security
guidelines would say to disable the write protection before locking
the registers down.

Feel free to propose a new "security guideline", but document it in the
tree.
https://review.coreboot.org/#/c/coreboot/+/21327/

Please note this is about having the whole chip protected. But not about
the decision whether or not to lock this configuration. It reminds me of
something, though: If you want to do such configuration in the payload,
both coreboot and payload code/configuration have to be kept in sync
if you have suspend-to-ram. Because coreboot has to do the same confi-
guration as the payload on the resume path (where the payload is not
executed).

One way would be to let coreboot decide, e.g. prepare the configuration
and don't lock it, and let the payload lock. The payload could validate
this configuration before locking (and issue a warning if coreboot
didn't set the expected bits).

Nico

[Lance Zhao]

I am reading the "flash security recommendation" from PCH BIOS writer
guide now, it did say strongly recommend to take those actions. The EISS
feature to ensure BIOS region can only get modfiyed from SMM.

Post by Nico Huber

Post by Patrick Rudolph
Hi Youness,

Post by Youness Alaoui
Hi,
I'm trying to add a way to lock the SPI flash to be read-only via
software *after* coreboot boots. The scenario is basically with using
Heads, you could authenticate to it (with a yubikey/nitrokey/librem
key) then be able to flash a new rom (update your BIOS), but once you
boot an OS, Heads would first lock the flash so it can't be written
to.
This should add some security to avoid any malware writing to the
flash, or someone booting into a USB stick and using that to flash a
malicious BIOS, but still gives the user the freedom of updating their
flash whenever they want to.
The problem is that I can't make the flash read-only because the SPI
interface is already locked down by coreboot (see
src/soc/intel/skylake/lockdown.c and
src/soc/intel/common/block/fast_spi/fast_spi.c).
First, the FLOCKDN bit is set which prevents us from enabling the
write protection. the BIOS Interface lock down is controlled by the
chipset_lockdown config variable, but the FLOCKDN is not behind a
config variable.
The second thing is that if I wanted to use the protected ranges
feature to lock specific regions, they are all getting locked using
the discrete lock register even while being unused. The locking of the
https://review.coreboot.org/c/coreboot/+/21064 and it passed without
notice among the move that the commit was supposed to do.
The commit states that the lockdown is meant to "support platform
security guidelines", but I think that this is not actually good
because coreboot leaves everything read-write and locks down the
registers so we can't make it read-only. I think that the security
guidelines would say to disable the write protection before locking
the registers down.

Feel free to propose a new "security guideline", but document it in the
tree.
https://review.coreboot.org/#/c/coreboot/+/21327/

Please note this is about having the whole chip protected. But not about
the decision whether or not to lock this configuration. It reminds me of
something, though: If you want to do such configuration in the payload,
both coreboot and payload code/configuration have to be kept in sync
if you have suspend-to-ram. Because coreboot has to do the same confi-
guration as the payload on the resume path (where the payload is not
executed).
One way would be to let coreboot decide, e.g. prepare the configuration
and don't lock it, and let the payload lock. The payload could validate
this configuration before locking (and issue a warning if coreboot
didn't set the expected bits).
Nico
--
https://mail.coreboot.org/mailman/listinfo/coreboot

[Nico Huber]

Post by Lance Zhao
I am reading the "flash security recommendation" from PCH BIOS writer
guide now, it did say strongly recommend to take those actions. The EISS
feature to ensure BIOS region can only get modfiyed from SMM.

The EISS bit is a highly questionable feature. It's part of the lost
cause of security by treating SMM more privileged than the OS. AFAIK,
coreboot vendors have secured flash access properly in the past without
SMM features and never failed [1]. OTOH, UEFI vendors often granted SMM
full flash access in the past and failed to secure SMM [2].

To my knowledge, EISS is incompatible to vboot btw. (not by design but
to the current implementation).

So I "strongly recommend" to ignore Intel's SMM recommendations wrt.
flash access and recommend instead to never grant SMM more privileges
than the OS.

Nico

[1] At least since the introduction of SPI flash chips. Earlier there
were possible race conditions regarding the BIOS Write Enable bit
where you needed SMM for protection, or had to use the flash chip's
own security features. But that was before/maybe why EISS became a
feature.
[2] e.g. https://github.com/Cr4sh/ThinkPwn (the list of vulnerable
systems is long and incomplete)

[Lance Zhao]

Okay, then I believe we should leave the decision on CONFIG instead of
force lockdown blindly. As of now, that's still optional I believe.

Post by Nico Huber

Post by Lance Zhao
I am reading the "flash security recommendation" from PCH BIOS writer
guide now, it did say strongly recommend to take those actions. The EISS
feature to ensure BIOS region can only get modfiyed from SMM.

The EISS bit is a highly questionable feature. It's part of the lost
cause of security by treating SMM more privileged than the OS. AFAIK,
coreboot vendors have secured flash access properly in the past without
SMM features and never failed [1]. OTOH, UEFI vendors often granted SMM
full flash access in the past and failed to secure SMM [2].
To my knowledge, EISS is incompatible to vboot btw. (not by design but
to the current implementation).
So I "strongly recommend" to ignore Intel's SMM recommendations wrt.
flash access and recommend instead to never grant SMM more privileges
than the OS.
Nico
[1] At least since the introduction of SPI flash chips. Earlier there
were possible race conditions regarding the BIOS Write Enable bit
where you needed SMM for protection, or had to use the flash chip's
own security features. But that was before/maybe why EISS became a
feature.
[2] e.g. https://github.com/Cr4sh/ThinkPwn (the list of vulnerable
systems is long and incomplete)

[Dhaval Sharma]

"but once you boot an OS, Heads would first lock the flash so it can't be
written to'. Is this some kind of a OS driver? The typical usage of all
locking register which are write once is to have them locked up within BIOS
itself which is within the most trusted boundary. Best we could do it push
out the locking part to the latest stages but not completely out IMHO.

Post by Lance Zhao
Okay, then I believe we should leave the decision on CONFIG instead of
force lockdown blindly. As of now, that's still optional I believe.

Post by Nico Huber

Post by Lance Zhao
I am reading the "flash security recommendation" from PCH BIOS writer
guide now, it did say strongly recommend to take those actions. The EISS
feature to ensure BIOS region can only get modfiyed from SMM.

The EISS bit is a highly questionable feature. It's part of the lost
cause of security by treating SMM more privileged than the OS. AFAIK,
coreboot vendors have secured flash access properly in the past without
SMM features and never failed [1]. OTOH, UEFI vendors often granted SMM
full flash access in the past and failed to secure SMM [2].
To my knowledge, EISS is incompatible to vboot btw. (not by design but
to the current implementation).
So I "strongly recommend" to ignore Intel's SMM recommendations wrt.
flash access and recommend instead to never grant SMM more privileges
than the OS.
Nico
[1] At least since the introduction of SPI flash chips. Earlier there
were possible race conditions regarding the BIOS Write Enable bit
where you needed SMM for protection, or had to use the flash chip's
own security features. But that was before/maybe why EISS became a
feature.
[2] e.g. https://github.com/Cr4sh/ThinkPwn (the list of vulnerable
systems is long and incomplete)

--
https://mail.coreboot.org/mailman/listinfo/coreboot

[Youness Alaoui]

Thanks everyone for the responses.
So far my understanding on the task at hand is :
- Add a CONFIG to decide if we set FLOCKDN or not (and one to decide
if we lock it on the resume path?)
- Remove the chipset_lockdown devicetree config and change the code to
always assume it's LOCKDOWN_COREBOOT (this applies to all platforms,
right?)
- remove the call to fast_spi_pr_dlock() and fix the comment above
that function to be more accurate
- Add .config CONFIG options or maybe optional devicetree configs for
how to setup the registers so coreboot can prepare them (due to the
resume path) ?

Can you please confirm the ones with question marks? Is there some
rule on "add as little CONFIG options as possible" ?

Post by Nico Huber
AIUI, FLOCKDN always locks the PRRs.

Actually from what I can see, the FLOCKDN will lock a few registers,
among which it will lock the "discrete PR locks" register, and it will
lock the PR 0, 1 and 2, but there's also a PRR34_LOCKDN bit to
separately lock the PRR 3 and 4. So technically, I could leave FLOCKDN
set, and in the payload, just set protected range in PRR3 or PRR4,
then set the PRR34_LOCKDN. Unfortunately, I can't do that because the
PRR3 and 4 were already locked with the discrete lock register (if I
remove the call to fast_spi_pr_dlock(), it should be fine for my needs
though I think, since you said swseq would also fail for protected
ranges).

Post by Nico Huber
"but once you boot an OS, Heads would first lock the flash so it can't be written to'. Is this some kind of a OS driver? The typical usage of all locking register which are write once is to have them locked up within BIOS itself which is within the most trusted boundary. Best we could do it push out the locking part to the latest stages but not completely out IMHO.

The problem is we want to allow users to update their flash and
coreboot doesn't have a "flash update utility" integrated, so it has
to happen in the payload, which is why coreboot needs to not lock
anything then let the payload do the locking for us instead. Heads is
the linux-based payload we're using, and the idea is that Heads would
lock the flash before it actually boots any OS (from HDD or from USB),
this way you can only update your flash from within Heads itself and
Heads will ensure that the image you're trying to flash is properly
signed, or that you authenticate first before it would allow you to do
that (prevents someone from booting into a live USB and flash a
malicious bios).

Post by Nico Huber
You can have write opcodes in the menu, they won't work on protected regions. But if you have
a partially protected flash (e.g. vboot), they are still useful.

Ok, that's interesting. I was actually thinking of just completely
disabling writing to any region, but maybe I can use the PRR instead.

Post by Nico Huber
Also note that swseq is not an option anymore since Skylake (IIRC, the
ME protects the flash-cycle go bit in its default configuration). With
only hwseq, you can only access the flash chip's first status register
which makes many security features unusable. So we have to rely on the
protected regions :-/ I hope Intel is going to fix that for future plat-
forms (or with an ME update if that could add more hwseq commands).

Well, I saw the opmenu/optypes/etc.. registers still being set in
skylake (their offsets were not in the datasheet though), so I figured
swseq is still there, just undocumented. It might work on systems
where the ME is disabled. I'd have to test. I was thinking of using
swseq and add the write-register-2 opcode and use it to set SPR1 and
lock the entire flash until it gets power cycled. I don't know if that
would work during suspend, but if it does, it might help with the
resume path at least (but would prevent updating flash after a reboot
and would force user to shut down and boot). I guess I have some
trial-error to do.
Actually, if status register remains the same through a
reboot/suspend/resume, and swseq doesn't work on skylake at all, I
could just set the protect bits and prevent writing to status register
on resume path.

Post by Nico Huber
One way would be to let coreboot decide, e.g. prepare the configuration
and don't lock it, and let the payload lock. The payload could validate
this configuration before locking (and issue a warning if coreboot
didn't set the expected bits).

Thanks, that's a good idea, I forgot about the suspend/resume case.
This implies I need coreboot to know about what config the payload
will want to set. I'm not sure if that should go into a CONFIG or a
devicetree config. Since it might be user-configured, it makes more
sense for it to go into .config, right ?

Thanks again,
Youness.

Post by Nico Huber

Okay, then I believe we should leave the decision on CONFIG instead of force lockdown blindly. As of now, that's still optional I believe.

Post by Nico Huber

Post by Lance Zhao
I am reading the "flash security recommendation" from PCH BIOS writer
guide now, it did say strongly recommend to take those actions. The EISS
feature to ensure BIOS region can only get modfiyed from SMM.

The EISS bit is a highly questionable feature. It's part of the lost
cause of security by treating SMM more privileged than the OS. AFAIK,
coreboot vendors have secured flash access properly in the past without
SMM features and never failed [1]. OTOH, UEFI vendors often granted SMM
full flash access in the past and failed to secure SMM [2].
To my knowledge, EISS is incompatible to vboot btw. (not by design but
to the current implementation).
So I "strongly recommend" to ignore Intel's SMM recommendations wrt.
flash access and recommend instead to never grant SMM more privileges
than the OS.
Nico
[1] At least since the introduction of SPI flash chips. Earlier there
were possible race conditions regarding the BIOS Write Enable bit
where you needed SMM for protection, or had to use the flash chip's
own security features. But that was before/maybe why EISS became a
feature.
[2] e.g. https://github.com/Cr4sh/ThinkPwn (the list of vulnerable
systems is long and incomplete)

--
https://mail.coreboot.org/mailman/listinfo/coreboot

[Prasun Gera]

Post by Youness Alaoui
The problem is we want to allow users to update their flash and
coreboot doesn't have a "flash update utility" integrated, so it has
to happen in the payload, which is why coreboot needs to not lock
anything then let the payload do the locking for us instead. Heads is
the linux-based payload we're using, and the idea is that Heads would
lock the flash before it actually boots any OS (from HDD or from USB),
this way you can only update your flash from within Heads itself and
Heads will ensure that the image you're trying to flash is properly
signed, or that you authenticate first before it would allow you to do
that (prevents someone from booting into a live USB and flash a
malicious bios).

This is a pretty useful feature, and it would be nice if it weren't tied to
heads (or any payload for that matter). What about tianocore's capsule
update mechanism, as well as stuff like fwupd ? Any way to have something
like a common solution ?

[Nico Huber]

Post by Prasun Gera

Post by Youness Alaoui
The problem is we want to allow users to update their flash and
coreboot doesn't have a "flash update utility" integrated, so it has
to happen in the payload, which is why coreboot needs to not lock
anything then let the payload do the locking for us instead. Heads is
the linux-based payload we're using, and the idea is that Heads would
lock the flash before it actually boots any OS (from HDD or from USB),
this way you can only update your flash from within Heads itself and
Heads will ensure that the image you're trying to flash is properly
signed, or that you authenticate first before it would allow you to do
that (prevents someone from booting into a live USB and flash a
malicious bios).

This is a pretty useful feature, and it would be nice if it weren't tied to
heads (or any payload for that matter). What about tianocore's capsule
update mechanism, as well as stuff like fwupd ? Any way to have something
like a common solution ?

IIRC, HEADS already reuses a lot of common software, e.g. PGP for sig-
natures, flashrom for flashing. So the bulk of the implementation is
not tied to a specific payload. Actually, we use a similar scheme and
(lib)flashrom in our payload for years. I guess the only thing missing
for a common solution would be a scheme or configuration file format to
discover the update.

And there is also vboot. Which is already implemented in coreboot and
might even provide better security. It's not tied to any specific pay-
load.

Nico

[Nico Huber]

Post by Youness Alaoui
Thanks everyone for the responses.
- Add a CONFIG to decide if we set FLOCKDN or not (and one to decide
if we lock it on the resume path?)

Maybe no config at all, see discussion of PRR34_LOCKDN below. But if,
then only one config, IMO: On the resume path FLOCKDN should always be
set.

Post by Youness Alaoui
- Remove the chipset_lockdown devicetree config and change the code to
always assume it's LOCKDOWN_COREBOOT (this applies to all platforms,
right?)

Yes, unless somebody objects. Please make sure to add the right
reviewers to this patch. I expect some resistance.

Post by Youness Alaoui
- remove the call to fast_spi_pr_dlock() and fix the comment above
that function to be more accurate

Please also check the tree for code that sets PRRs. IIRC, it is used
somewhere to protect the MRC cache. I would set the discrete lock
directly after writing the region.

Post by Youness Alaoui
- Add .config CONFIG options or maybe optional devicetree configs for
how to setup the registers so coreboot can prepare them (due to the
resume path) ?

Hmm, I would add Kconfig options for this as well. I you want to match
the configuration of your payload, it definitely doesn't belong into the
devicetree. Note that "prepare" also implies to lock them on the resume
path.

Post by Youness Alaoui

Post by Nico Huber
AIUI, FLOCKDN always locks the PRRs.

Actually from what I can see, the FLOCKDN will lock a few registers,
among which it will lock the "discrete PR locks" register, and it will
lock the PR 0, 1 and 2, but there's also a PRR34_LOCKDN bit to
separately lock the PRR 3 and 4. So technically, I could leave FLOCKDN
set, and in the payload, just set protected range in PRR3 or PRR4,
then set the PRR34_LOCKDN. Unfortunately, I can't do that because the
PRR3 and 4 were already locked with the discrete lock register (if I
remove the call to fast_spi_pr_dlock(), it should be fine for my needs
though I think, since you said swseq would also fail for protected
ranges).

Ah, that PRR34_LOCKDN was only introduced with SKL. Didn't know it or
at least didn't remember it. In this case it seems best to always set
FLOCKDN in coreboot. The payload can then still protect additional
regions with PRR3/4. On the resume path, coreboot would set both FLOCKDN
and PRR34_LOCKDN, right?

Post by Youness Alaoui

Post by Nico Huber
Also note that swseq is not an option anymore since Skylake (IIRC, the
ME protects the flash-cycle go bit in its default configuration). With
only hwseq, you can only access the flash chip's first status register
which makes many security features unusable. So we have to rely on the
protected regions :-/ I hope Intel is going to fix that for future plat-
forms (or with an ME update if that could add more hwseq commands).

Well, I saw the opmenu/optypes/etc.. registers still being set in
skylake (their offsets were not in the datasheet though), so I figured
swseq is still there, just undocumented. It might work on systems
where the ME is disabled. I'd have to test. I was thinking of using
swseq and add the write-register-2 opcode and use it to set SPR1 and
lock the entire flash until it gets power cycled. I don't know if that
would work during suspend, but if it does, it might help with the
resume path at least (but would prevent updating flash after a reboot
and would force user to shut down and boot). I guess I have some
trial-error to do.

The tricky part is to get access to the flash chip's second status
register. I couldn't figure any way to do that with SKL (this cost
me some weeks of work once because FSP also locked empty flash pro-
tection).

Post by Youness Alaoui
Actually, if status register remains the same through a
reboot/suspend/resume, and swseq doesn't work on skylake at all, I
could just set the protect bits and prevent writing to status register
on resume path.

I don't understand, is there a lock to prevent status register writes
with hwseq? Also I though, you can't disable these status register bits
w/o a reset. Whether the flash chip is reset, depends on your board
design and power sequencing ofc.

Post by Youness Alaoui

Post by Nico Huber
One way would be to let coreboot decide, e.g. prepare the configuration
and don't lock it, and let the payload lock. The payload could validate
this configuration before locking (and issue a warning if coreboot
didn't set the expected bits).

Thanks, that's a good idea, I forgot about the suspend/resume case.
This implies I need coreboot to know about what config the payload
will want to set. I'm not sure if that should go into a CONFIG or a
devicetree config. Since it might be user-configured, it makes more
sense for it to go into .config, right ?

Yes, Kconfig seems to be the right place.

Nico

[Youness Alaoui]

Post by Nico Huber

Post by Youness Alaoui
Thanks everyone for the responses.
- Add a CONFIG to decide if we set FLOCKDN or not (and one to decide
if we lock it on the resume path?)

Maybe no config at all, see discussion of PRR34_LOCKDN below. But if,
then only one config, IMO: On the resume path FLOCKDN should always be
set.

Post by Youness Alaoui
- Remove the chipset_lockdown devicetree config and change the code to
always assume it's LOCKDOWN_COREBOOT (this applies to all platforms,
right?)

Yes, unless somebody objects. Please make sure to add the right
reviewers to this patch. I expect some resistance.

Ok, this is already done, but I want to finish/test my work before I
send for review and I might not have time until the end of the week.

Post by Nico Huber

Post by Youness Alaoui
- remove the call to fast_spi_pr_dlock() and fix the comment above
that function to be more accurate

Please also check the tree for code that sets PRRs. IIRC, it is used
somewhere to protect the MRC cache. I would set the discrete lock
directly after writing the region.

Ok, thanks, will do.
Note: I've also changed the fast_spi_pr_dlock() function to take 5 u8
arguments to allow the caller to lock each prr individually instead of
being an all or nothing.

Post by Nico Huber

Post by Youness Alaoui
- Add .config CONFIG options or maybe optional devicetree configs for
how to setup the registers so coreboot can prepare them (due to the
resume path) ?

Hmm, I would add Kconfig options for this as well. I you want to match
the configuration of your payload, it definitely doesn't belong into the
devicetree. Note that "prepare" also implies to lock them on the resume
path.

Yeah, so far, the KConfigs I added are :
FAST_SPI_LOCK_REGISTERS
FAST_SPI_LOCK_REGISTERS_ON_RESUME
FAST_SPI_LOCK_PRR34_REGISTERS
FAST_SPI_LOCK_PRR34_REGISTERS_ON_RESUME
FAST_SPI_PRR3_REGISTER (hex value)
FAST_SPI_PRR4_REGISTER (hex value)

This way, a user can lock/unlock the register (since it affects more
than just the PRRs) and they can override/set the PRR3 and PRR4 values
and decide whether to lock them or not or only on resume, etc.. I
think those should be enough for most use cases and it's enough for
what I need.

Post by Nico Huber

Post by Youness Alaoui

Post by Nico Huber
AIUI, FLOCKDN always locks the PRRs.

Actually from what I can see, the FLOCKDN will lock a few registers,
among which it will lock the "discrete PR locks" register, and it will
lock the PR 0, 1 and 2, but there's also a PRR34_LOCKDN bit to
separately lock the PRR 3 and 4. So technically, I could leave FLOCKDN
set, and in the payload, just set protected range in PRR3 or PRR4,
then set the PRR34_LOCKDN. Unfortunately, I can't do that because the
PRR3 and 4 were already locked with the discrete lock register (if I
remove the call to fast_spi_pr_dlock(), it should be fine for my needs
though I think, since you said swseq would also fail for protected
ranges).

Ah, that PRR34_LOCKDN was only introduced with SKL. Didn't know it or
at least didn't remember it. In this case it seems best to always set
FLOCKDN in coreboot. The payload can then still protect additional
regions with PRR3/4. On the resume path, coreboot would set both FLOCKDN
and PRR34_LOCKDN, right?

On resume, even if coreboot sets them, the PRRs need to be filled,
which is why I also added the hex value of the PRR in the KConfig.
I also want to keep FLOCKDN unlocked, so Heads can set the write
protect bits in the flash then prevent writing to the status register
via hwseq before locking it with FLOCKDN.

Post by Nico Huber

Post by Youness Alaoui

Post by Nico Huber
Also note that swseq is not an option anymore since Skylake (IIRC, the
ME protects the flash-cycle go bit in its default configuration). With
only hwseq, you can only access the flash chip's first status register
which makes many security features unusable. So we have to rely on the
protected regions :-/ I hope Intel is going to fix that for future plat-
forms (or with an ME update if that could add more hwseq commands).

Well, I saw the opmenu/optypes/etc.. registers still being set in
skylake (their offsets were not in the datasheet though), so I figured
swseq is still there, just undocumented. It might work on systems
where the ME is disabled. I'd have to test. I was thinking of using
swseq and add the write-register-2 opcode and use it to set SPR1 and
lock the entire flash until it gets power cycled. I don't know if that
would work during suspend, but if it does, it might help with the
resume path at least (but would prevent updating flash after a reboot
and would force user to shut down and boot). I guess I have some
trial-error to do.

The tricky part is to get access to the flash chip's second status
register. I couldn't figure any way to do that with SKL (this cost
me some weeks of work once because FSP also locked empty flash pro-
tection).

Only way I see is through swseq, but you say it doesn't work because
of the ME. I'd have to test if the disabled ME allows swseq to work.

Post by Nico Huber

Post by Youness Alaoui
Actually, if status register remains the same through a
reboot/suspend/resume, and swseq doesn't work on skylake at all, I
could just set the protect bits and prevent writing to status register
on resume path.

I don't understand, is there a lock to prevent status register writes
with hwseq? Also I though, you can't disable these status register bits
w/o a reset. Whether the flash chip is reset, depends on your board
design and power sequencing ofc.

Yes, see bit 11 of HSFSC register (WRSDIS). That one already has a
Kconfig to decide if we want it locked or not.

Post by Nico Huber

Post by Youness Alaoui

Post by Nico Huber
One way would be to let coreboot decide, e.g. prepare the configuration
and don't lock it, and let the payload lock. The payload could validate
this configuration before locking (and issue a warning if coreboot
didn't set the expected bits).

Thanks, that's a good idea, I forgot about the suspend/resume case.
This implies I need coreboot to know about what config the payload
will want to set. I'm not sure if that should go into a CONFIG or a
devicetree config. Since it might be user-configured, it makes more
sense for it to go into .config, right ?

Yes, Kconfig seems to be the right place.
Nico

Thanks!

[Martin Kepplinger]

Post by Youness Alaoui

Post by Nico Huber

Post by Youness Alaoui
Thanks everyone for the responses.
- Add a CONFIG to decide if we set FLOCKDN or not (and one to decide
if we lock it on the resume path?)

Maybe no config at all, see discussion of PRR34_LOCKDN below. But if,
then only one config, IMO: On the resume path FLOCKDN should always be
set.

Post by Youness Alaoui
- Remove the chipset_lockdown devicetree config and change the code to
always assume it's LOCKDOWN_COREBOOT (this applies to all platforms,
right?)

Yes, unless somebody objects. Please make sure to add the right
reviewers to this patch. I expect some resistance.

Ok, this is already done, but I want to finish/test my work before I
send for review and I might not have time until the end of the week.

Post by Nico Huber

Post by Youness Alaoui
- remove the call to fast_spi_pr_dlock() and fix the comment above
that function to be more accurate

Please also check the tree for code that sets PRRs. IIRC, it is used
somewhere to protect the MRC cache. I would set the discrete lock
directly after writing the region.

Ok, thanks, will do.
Note: I've also changed the fast_spi_pr_dlock() function to take 5 u8
arguments to allow the caller to lock each prr individually instead of
being an all or nothing.

Post by Nico Huber

Post by Youness Alaoui
- Add .config CONFIG options or maybe optional devicetree configs for
how to setup the registers so coreboot can prepare them (due to the
resume path) ?

Hmm, I would add Kconfig options for this as well. I you want to match
the configuration of your payload, it definitely doesn't belong into the
devicetree. Note that "prepare" also implies to lock them on the resume
path.

FAST_SPI_LOCK_REGISTERS
FAST_SPI_LOCK_REGISTERS_ON_RESUME
FAST_SPI_LOCK_PRR34_REGISTERS
FAST_SPI_LOCK_PRR34_REGISTERS_ON_RESUME
FAST_SPI_PRR3_REGISTER (hex value)
FAST_SPI_PRR4_REGISTER (hex value)
This way, a user can lock/unlock the register (since it affects more
than just the PRRs) and they can override/set the PRR3 and PRR4 values
and decide whether to lock them or not or only on resume, etc.. I
think those should be enough for most use cases and it's enough for
what I need.

Post by Nico Huber

Post by Youness Alaoui

Post by Nico Huber
AIUI, FLOCKDN always locks the PRRs.

Actually from what I can see, the FLOCKDN will lock a few registers,
among which it will lock the "discrete PR locks" register, and it will
lock the PR 0, 1 and 2, but there's also a PRR34_LOCKDN bit to
separately lock the PRR 3 and 4. So technically, I could leave FLOCKDN
set, and in the payload, just set protected range in PRR3 or PRR4,
then set the PRR34_LOCKDN. Unfortunately, I can't do that because the
PRR3 and 4 were already locked with the discrete lock register (if I
remove the call to fast_spi_pr_dlock(), it should be fine for my needs
though I think, since you said swseq would also fail for protected
ranges).

Ah, that PRR34_LOCKDN was only introduced with SKL. Didn't know it or
at least didn't remember it. In this case it seems best to always set
FLOCKDN in coreboot. The payload can then still protect additional
regions with PRR3/4. On the resume path, coreboot would set both FLOCKDN
and PRR34_LOCKDN, right?

On resume, even if coreboot sets them, the PRRs need to be filled,
which is why I also added the hex value of the PRR in the KConfig.
I also want to keep FLOCKDN unlocked, so Heads can set the write
protect bits in the flash then prevent writing to the status register
via hwseq before locking it with FLOCKDN.

Post by Nico Huber

Post by Youness Alaoui

Post by Nico Huber
Also note that swseq is not an option anymore since Skylake (IIRC, the
ME protects the flash-cycle go bit in its default configuration). With
only hwseq, you can only access the flash chip's first status register
which makes many security features unusable. So we have to rely on the
protected regions :-/ I hope Intel is going to fix that for future plat-
forms (or with an ME update if that could add more hwseq commands).

Well, I saw the opmenu/optypes/etc.. registers still being set in
skylake (their offsets were not in the datasheet though), so I figured
swseq is still there, just undocumented. It might work on systems
where the ME is disabled. I'd have to test. I was thinking of using
swseq and add the write-register-2 opcode and use it to set SPR1 and
lock the entire flash until it gets power cycled. I don't know if that
would work during suspend, but if it does, it might help with the
resume path at least (but would prevent updating flash after a reboot
and would force user to shut down and boot). I guess I have some
trial-error to do.

The tricky part is to get access to the flash chip's second status
register. I couldn't figure any way to do that with SKL (this cost
me some weeks of work once because FSP also locked empty flash pro-
tection).

Only way I see is through swseq, but you say it doesn't work because
of the ME. I'd have to test if the disabled ME allows swseq to work.

Post by Nico Huber

Post by Youness Alaoui
Actually, if status register remains the same through a
reboot/suspend/resume, and swseq doesn't work on skylake at all, I
could just set the protect bits and prevent writing to status register
on resume path.

I don't understand, is there a lock to prevent status register writes
with hwseq? Also I though, you can't disable these status register bits
w/o a reset. Whether the flash chip is reset, depends on your board
design and power sequencing ofc.

Yes, see bit 11 of HSFSC register (WRSDIS). That one already has a
Kconfig to decide if we want it locked or not.

Post by Nico Huber

Post by Youness Alaoui

Post by Nico Huber
One way would be to let coreboot decide, e.g. prepare the configuration
and don't lock it, and let the payload lock. The payload could validate
this configuration before locking (and issue a warning if coreboot
didn't set the expected bits).

Thanks, that's a good idea, I forgot about the suspend/resume case.
This implies I need coreboot to know about what config the payload
will want to set. I'm not sure if that should go into a CONFIG or a
devicetree config. Since it might be user-configured, it makes more
sense for it to go into .config, right ?

Yes, Kconfig seems to be the right place.
Nico

Thanks!

is there already a gerrit change you are working on this? Do plan to
support / test
a X230 flash chip's lock bits?
* MX25L6406E/MX25L6408E
* EN25QH64
* MX25L3206E

thanks,

martin

[Nico Huber]

Hi,

Post by Martin Kepplinger
is there already a gerrit change you are working on this? Do plan to
support / test
a X230 flash chip's lock bits?
* MX25L6406E/MX25L6408E
* EN25QH64
* MX25L3206E

not about this request in particular but such flash-chip features in
general: IMO, the best solution is to implement these in (lib)flashrom
and integrate that into coreboot. I wouldn't say that it's wasted time
to implement it in coreboot directly. But, in the long run, taking
shortcuts or maintaining redundant implementations will slow the pro-
ject down overall.

Nico

[Youness Alaoui]

Hi Everyone!

Sorry for the 2 weeks late reply, I've read your responses, but I've
been too busy and dealing with stuff and haven't had/taken the time to
reply but your input was very much appreciated and not ignored!
One thing to note is that this week will be my last week at Purism as
I'm going on sabbatical for a few months, and I may or may not (most
likely won't) come back to Purism in a few months. So this feature
will probably be my last coreboot contribution (for a while at least).

I'm going to try and reply quickly to some of the comments.
@Sam

Post by Sam Kuper
This seems to imply that each time a Librem user wants to internally

flash the ROM, she would have to:

Yes, updating the flash would be a relatively complicated process
which is ok, because for me and you, sure, we'd update the rom a few
times a day/week, but for 90% of the users, they would either :
- never do it
- only do it when a new update is released and interests them, i.e:
once or twice a year.
So it's a complicated process (as you've outlined) but it would be far
from annoying to users since most won't care or notice that all that
is needed, and if they do, they won't care to have to do it so rarely.
It will however, especially with cover-opening protections (either
using glitter/whatever methods on screws to notice if they'd been
opened, or with an EC handling a cover switch notification), that
could be very helpful to increase their security.

Post by Sam Kuper
Your assumption fails against a BadHeads attack.

Yes indeed, I wrote a proof of concept which was a Heads that would
extend PCRs with the same values that coreboot did (and have a
coreboot with measured boot disabled) and it passed the TOTP
authentication. That's something that other possible solutions would
try to mitigate (such as vboot I think).

Post by Sam Kuper
You two might have different kinds of updates in mind. You don't need

a switch for every update.
Well, I hadn't thought this through to be honest, but in theory you
could still flash early in the boot process (in heads) if the
protection bits aren't set on the flash. So using the jumper might
only allow flashing within the OS itself. Or maybe if the bootblock
locks its own region, maybe setting the jumpre would allow the user to
flash a new root of trust only.
I suppose that's where vboot comes through, and I've left Kyle to
investigate all that (though he says we don't need it, but I'm
starting to think he's wrong and I think he could be convinced easily
enough, I'll point him to this thread which should do the trick).
Anyways, I'm leaving Purism now and going on vacation so I'm not going
to bother trying to wrap my head around all that.

FYI: What I'm trying to do is to improve the security for current
machines, so the discussion on the jumper/etc.. is irrelevant for
machines already in the hands of customers.

Post by Sam Kuper
Youness and others at Purism: it would be great if Purism could be
sure not only to spec, but also to list on the Librem specification
pages on the website, a SPI flash ROM chip that *does* obey its
write-protect pin regardless of firmware. Thanks :)

I didn't realize that "some chips don't obey the write-protect pin",
but rather my understanding is that the write protect pin is there to
say "the protected blocks are protected/not-protected according to
hardware.
The SPI flash (according to the datasheets I've read) can protect
regions either with "don't protect" or "protected by WP#" or
"protected until power-cycle".
The status register bits can be written to either as volatile or
non-volatile (for non volatile, you need another command iirc, and you
can't do it with hardware sequencing, same for the 'protect until
power cycle', which also needs to write to status-register-2 which
can't be done with hardware sequencing either).
So, really, a flash rom chip does obey its WP pin, it just depends on
how it's set.

Post by Sam Kuper
Hi,

Post by Martin Kepplinger
is there already a gerrit change you are working on this? Do plan to
support / test
a X230 flash chip's lock bits?
* MX25L6406E/MX25L6408E
* EN25QH64
* MX25L3206E

not about this request in particular but such flash-chip features in
general: IMO, the best solution is to implement these in (lib)flashrom
and integrate that into coreboot. I wouldn't say that it's wasted time
to implement it in coreboot directly. But, in the long run, taking
shortcuts or maintaining redundant implementations will slow the pro-
ject down overall.
Nico
--
https://mail.coreboot.org/mailman/listinfo/coreboot

[Sam Kuper]

Hi Youness,

Post by Youness Alaoui
One thing to note is that this week will be my last week at Purism as
I'm going on sabbatical for a few months, and I may or may not (most
likely won't) come back to Purism in a few months.

Thank you for your efforts to make Coreboot work on the Librems, and
for the enthusiasm you displayed here in the mailing list and on the
Purism blog.

Although I might have sounded critical on occasion, this was never
personal; it was always out of a concern to avoid missing
opportunities to achieve the most secure and privacy-protecting
machines available within the constraints of the hardware and the
business model. I.e. my "criticisms" were always intended to be
constructive. I hope that they did not form any part of your decision
to take a break from Purism, and if they did, I apologise.

I wish you a good sabbatical, in any case.

Post by Youness Alaoui
@Sam
- never [flash the ROM]
once or twice a year.
So [...] it would be far
from annoying to users since most won't care or notice that all that
is needed, and if they do, they won't care to have to do it so rarely.

I fear that even performed rarely, it might be beyond some users'
abilities. But...

Post by Youness Alaoui
It will however, especially with cover-opening protections (either
using glitter/whatever methods on screws to notice if they'd been
opened, or with an EC handling a cover switch notification), that
could be very helpful to increase their security.

... I agree that making it tamper-evident is indeed potentially valuable.

Post by Youness Alaoui

Post by Sam Kuper
Your assumption fails against a BadHeads attack.

Yes indeed, I wrote a proof of concept which was a Heads that would
extend PCRs with the same values that coreboot did (and have a
coreboot with measured boot disabled) and it passed the TOTP
authentication.

Many thanks for confirming this to the mailing list. I was hoping to
write and somehow disseminate (e.g. to the Heads developers) a POC
myself, but I'm glad to be spared that need.

If you could send your POC to the Heads team for integration into the
test suite, that would be great. This flaw in Heads needs to be fixed
(if it hasn't already been). Having the POC in the test suite would
also help to detect future regressions, once the issue is fixed (if it
*can* be fixed).

If it hasn't yet been fixed... Thinking aloud: as a community, we need
to find a way (or else, determine that it really is impossible) to
achieve robust mutual authentication between PC and user, with just an
SPI ROM and a boot disk and a TPM and a TOTP/challenge-response token.
Some kind of formal verification might be in order.

Post by Youness Alaoui
That's something that other possible solutions would
try to mitigate (such as vboot I think).

In the open world, vboot does seem to be the state of the art.

Apple's T2 chip might also mitigate against this sort of thing,
although it does not authenticate to the user via TOTP: the check is
implicit rather than explicit. I may be wrong, though. Public
documentation seems to be scarce.

Post by Youness Alaoui

Post by Sam Kuper
it would be great if Purism could be
sure not only to spec, but also to list on the Librem specification
pages on the website, a SPI flash ROM chip that *does* obey its
write-protect pin regardless of firmware. Thanks :)

I didn't realize that "some chips don't obey the write-protect pin",
but rather my understanding is that the write protect pin is there to
say "the protected blocks are protected/not-protected according to
hardware.
The SPI flash (according to the datasheets I've read) can protect
regions either with "don't protect" or "protected by WP#" or
"protected until power-cycle".
The status register bits can be written to either as volatile or
non-volatile (for non volatile, you need another command iirc, and you
can't do it with hardware sequencing, same for the 'protect until
power cycle', which also needs to write to status-register-2 which
can't be done with hardware sequencing either).
So, really, a flash rom chip does obey its WP pin, it just depends on
how it's set.

Thanks for this. I clearly need to spend more time reading data sheets
and running tests on SPI flash ROM chips.

All best,

Sam

[R S]

Yes, thanks Youness for all the hard work and research. You provided an
exceptional service. I enjoyed your rants and explanations both on Purism's
blog and here. Hopefully Purism can fill that void you are leaving behind.

Post by Patrick Rudolph
Hi Youness,

Post by Youness Alaoui
One thing to note is that this week will be my last week at Purism as
I'm going on sabbatical for a few months, and I may or may not (most
likely won't) come back to Purism in a few months.

Thank you for your efforts to make Coreboot work on the Librems, and
for the enthusiasm you displayed here in the mailing list and on the
Purism blog.
Although I might have sounded critical on occasion, this was never
personal; it was always out of a concern to avoid missing
opportunities to achieve the most secure and privacy-protecting
machines available within the constraints of the hardware and the
business model. I.e. my "criticisms" were always intended to be
constructive. I hope that they did not form any part of your decision
to take a break from Purism, and if they did, I apologise.
I wish you a good sabbatical, in any case.

Post by Youness Alaoui
@Sam
- never [flash the ROM]
once or twice a year.
So [...] it would be far
from annoying to users since most won't care or notice that all that
is needed, and if they do, they won't care to have to do it so rarely.

I fear that even performed rarely, it might be beyond some users'
abilities. But...

Post by Youness Alaoui
It will however, especially with cover-opening protections (either
using glitter/whatever methods on screws to notice if they'd been
opened, or with an EC handling a cover switch notification), that
could be very helpful to increase their security.

... I agree that making it tamper-evident is indeed potentially valuable.

Post by Youness Alaoui

Post by Sam Kuper
Your assumption fails against a BadHeads attack.

Yes indeed, I wrote a proof of concept which was a Heads that would
extend PCRs with the same values that coreboot did (and have a
coreboot with measured boot disabled) and it passed the TOTP
authentication.

Many thanks for confirming this to the mailing list. I was hoping to
write and somehow disseminate (e.g. to the Heads developers) a POC
myself, but I'm glad to be spared that need.
If you could send your POC to the Heads team for integration into the
test suite, that would be great. This flaw in Heads needs to be fixed
(if it hasn't already been). Having the POC in the test suite would
also help to detect future regressions, once the issue is fixed (if it
*can* be fixed).
If it hasn't yet been fixed... Thinking aloud: as a community, we need
to find a way (or else, determine that it really is impossible) to
achieve robust mutual authentication between PC and user, with just an
SPI ROM and a boot disk and a TPM and a TOTP/challenge-response token.
Some kind of formal verification might be in order.

Post by Youness Alaoui
That's something that other possible solutions would
try to mitigate (such as vboot I think).

In the open world, vboot does seem to be the state of the art.
Apple's T2 chip might also mitigate against this sort of thing,
although it does not authenticate to the user via TOTP: the check is
implicit rather than explicit. I may be wrong, though. Public
documentation seems to be scarce.

Post by Youness Alaoui

Post by Sam Kuper
it would be great if Purism could be
sure not only to spec, but also to list on the Librem specification
pages on the website, a SPI flash ROM chip that *does* obey its
write-protect pin regardless of firmware. Thanks :)

I didn't realize that "some chips don't obey the write-protect pin",
but rather my understanding is that the write protect pin is there to
say "the protected blocks are protected/not-protected according to
hardware.
The SPI flash (according to the datasheets I've read) can protect
regions either with "don't protect" or "protected by WP#" or
"protected until power-cycle".
The status register bits can be written to either as volatile or
non-volatile (for non volatile, you need another command iirc, and you
can't do it with hardware sequencing, same for the 'protect until
power cycle', which also needs to write to status-register-2 which
can't be done with hardware sequencing either).
So, really, a flash rom chip does obey its WP pin, it just depends on
how it's set.

Thanks for this. I clearly need to spend more time reading data sheets
and running tests on SPI flash ROM chips.
All best,
Sam
--
https://mail.coreboot.org/mailman/listinfo/coreboot

[Youness Alaoui]

Yes, thanks Youness for all the hard work and research. You provided an exceptional service. I enjoyed your rants and explanations both on Purism's blog and here. Hopefully Purism can fill that void you are leaving behind.

Thanks! I had a lot of fun, and this community is really great! I hope
we still get to work together again in the future and cross paths!

Post by Patrick Rudolph
Hi Youness,

Post by Youness Alaoui
One thing to note is that this week will be my last week at Purism as
I'm going on sabbatical for a few months, and I may or may not (most
likely won't) come back to Purism in a few months.

Thank you for your efforts to make Coreboot work on the Librems, and
for the enthusiasm you displayed here in the mailing list and on the
Purism blog.
Although I might have sounded critical on occasion, this was never
personal; it was always out of a concern to avoid missing
opportunities to achieve the most secure and privacy-protecting
machines available within the constraints of the hardware and the
business model. I.e. my "criticisms" were always intended to be
constructive. I hope that they did not form any part of your decision
to take a break from Purism, and if they did, I apologise.
I wish you a good sabbatical, in any case.

Thanks!
I understand that the criticism was never personal, and I think you
all were justified in being critical as well, but then things started
to change for the better in purism and it took time for people here
(understandably) to see that the change was not just smoke and
mirrors. I hope that with me gone, they'll find a good replacement and
they'll continue working with the coreboot community and keep moving
forward, instead of backward.
No, you or anyone else's criticism here had zero part in my decision
to leave. On the contrary, I really enjoyed working with the coreboot
community, you're all very welcoming, so thanks for that! I'm leaving
because I'm feeling close to a burnout, and I don't want to get stuck
in one, so I dropped both Purism and a second client I had, in order
to concentrate on my health and well being. The reason I might not be
coming back to Purism in the future is because they have a new
contract for employees/contractors which I disagree with and I'm not
ready to sign. It's still a draft though so if the feedback is taken
into consideration and lawyers don't reject the feedback and the final
version of the contract is acceptable to me, then I might come back.
We'll see what happens! :)

Post by Patrick Rudolph

Post by Youness Alaoui
@Sam
- never [flash the ROM]
once or twice a year.
So [...] it would be far
from annoying to users since most won't care or notice that all that
is needed, and if they do, they won't care to have to do it so rarely.

I fear that even performed rarely, it might be beyond some users'
abilities. But...

Yeah, it might make someone not update if they realize they need to do
that, but I guess if they'd only need to do it in order to break the
root of trust and overwrite the bootblock or whatever, then that might
be good. Either way, it's better than having the WP# hard wired to VCC
as it is right now.

Post by Patrick Rudolph

Post by Youness Alaoui
It will however, especially with cover-opening protections (either
using glitter/whatever methods on screws to notice if they'd been
opened, or with an EC handling a cover switch notification), that
could be very helpful to increase their security.

... I agree that making it tamper-evident is indeed potentially valuable.

Post by Youness Alaoui

Post by Sam Kuper
Your assumption fails against a BadHeads attack.

Yes indeed, I wrote a proof of concept which was a Heads that would
extend PCRs with the same values that coreboot did (and have a
coreboot with measured boot disabled) and it passed the TOTP
authentication.

Many thanks for confirming this to the mailing list. I was hoping to
write and somehow disseminate (e.g. to the Heads developers) a POC
myself, but I'm glad to be spared that need.
If you could send your POC to the Heads team for integration into the
test suite, that would be great. This flaw in Heads needs to be fixed
(if it hasn't already been). Having the POC in the test suite would
also help to detect future regressions, once the issue is fixed (if it
*can* be fixed).

Yeah, I did that a few months ago, the PoC is rather simple but would
be hard to have in a test suite, I'm not sure.
Basically, I did 'cbmem -c | grep -i extend" to get the log which says
"extending PCR <id> with <hash>", then I rebuilt coreboot and disabled
MEASURED_BOOT, then in head's init script I just added the lines :
tpmcli pcr extend <id> -h <hash>
(more or less, can't remember the name of the command or what
arguments it needed.. I think i had to build a modified version of the
tool so i can give it directly the hash to extend with instead of a
message for it to hash)
That's all!

Post by Patrick Rudolph
If it hasn't yet been fixed... Thinking aloud: as a community, we need
to find a way (or else, determine that it really is impossible) to
achieve robust mutual authentication between PC and user, with just an
SPI ROM and a boot disk and a TPM and a TOTP/challenge-response token.
Some kind of formal verification might be in order.

I don't think there's a way to fix it without using some other method.
Currently, having Heads block any writes to the SPI flash and only
allow heads itself to update the bios after it verifies that the rom
is signed correctly, that's a good solution, but of course, it will
only prevent remote attacks or local software attacks. Anyone can
always just open the cover and use a hardware flasher to replace
everything. Hopefully with the next hardware, they'll have a way to
tell users if the cover was ever opened, and make it easier for users
(I'm hoping for a header) to have users verify their flash content
with a hardware flasher when needed/periodically.
Either way, 100% security doesn't exist in my opinion, all anyone can
do is make it so difficult, it stops being worth the trouble (or force
the attack to tailor his attack to a specific machine).

Post by Patrick Rudolph

Post by Youness Alaoui
That's something that other possible solutions would
try to mitigate (such as vboot I think).

In the open world, vboot does seem to be the state of the art.
Apple's T2 chip might also mitigate against this sort of thing,
although it does not authenticate to the user via TOTP: the check is
implicit rather than explicit. I may be wrong, though. Public
documentation seems to be scarce.

I don't know, either way, in 2 days, it will be out of my hands :)
I've sent Kyle a link so he can read this entire thread and figure out
what needs to be done.

Post by Patrick Rudolph

Post by Youness Alaoui

Post by Sam Kuper
it would be great if Purism could be
sure not only to spec, but also to list on the Librem specification
pages on the website, a SPI flash ROM chip that *does* obey its
write-protect pin regardless of firmware. Thanks :)

I didn't realize that "some chips don't obey the write-protect pin",
but rather my understanding is that the write protect pin is there to
say "the protected blocks are protected/not-protected according to
hardware.
The SPI flash (according to the datasheets I've read) can protect
regions either with "don't protect" or "protected by WP#" or
"protected until power-cycle".
The status register bits can be written to either as volatile or
non-volatile (for non volatile, you need another command iirc, and you
can't do it with hardware sequencing, same for the 'protect until
power cycle', which also needs to write to status-register-2 which
can't be done with hardware sequencing either).
So, really, a flash rom chip does obey its WP pin, it just depends on
how it's set.

Thanks for this. I clearly need to spend more time reading data sheets
and running tests on SPI flash ROM chips.

You're welcome!
You can see here :
https://www.winbond.com/resource-files/w25q64fw_revk%2007012016%20sfdp.pdf
Pages 14 to 20. Especially figure in 7.1.7

Post by Patrick Rudolph
All best,
Sam

Thanks,
Youness.

[Peter Stuge]

Post by Youness Alaoui
So, really, a flash rom chip does obey its WP pin, it just depends
on how it's set.

For all flash with non-volatile status register the WP pin is irrelevant
from reset until software (in same write-enabled flash) writes block
protection into the status register. (Only then does the WP pin matter.)

The later that status register write happens the more time there
is for anything with access to the SPI bus to write to the flash.


//Peter

[Nico Huber]

Post by Lance Zhao
Okay, then I believe we should leave the decision on CONFIG instead of
force lockdown blindly. As of now, that's still optional I believe.

AFAIK, EISS is not a configurable option in coreboot atm. And it
shouldn't be, IMHO, as it encourages to weaken security.

Nico

[Nico Huber]

Hi Youness,

Post by Youness Alaoui
First, the FLOCKDN bit is set which prevents us from enabling the
write protection. the BIOS Interface lock down is controlled by the
chipset_lockdown config variable, but the FLOCKDN is not behind a
config variable.
The second thing is that if I wanted to use the protected ranges
feature to lock specific regions, they are all getting locked using
the discrete lock register even while being unused. The locking of the
https://review.coreboot.org/c/coreboot/+/21064 and it passed without
notice among the move that the commit was supposed to do.
The commit states that the lockdown is meant to "support platform
security guidelines", but I think that this is not actually good
because coreboot leaves everything read-write and locks down the
registers so we can't make it read-only. I think that the security
guidelines would say to disable the write protection before locking
the registers down.

the code is flawed, I'm not sure if I noticed during review, probably
only when it was too late. It seems to me that these "security guide-
lines" have two issues:
1. They are written with UEFI style security in mind (e.g. updates in
SMM).
2. They are meant to be understandable for a humble reader and hence
can't comprise all the details (like threat models etc.) for real
security. They seem to be for getting-a-green-light-in-CHIPSEC
security.

Not sure how CHIPSEC would react if the individual PRR locks aren't set.
But feel free to remove the locking of unset PR registers on any path
where we don't set FLOCKDN.

Post by Youness Alaoui
Either way, I'm going to need to add a way to make this configurable,
- Should I create a new config variable to decide on whether or not to
lock the spi registers and another one to decide on whether or not to
lock the protected ranges ?

I would prefer to have a single Kconfig option like INTEL_CHIPSET_
LOCKDOWN (sb/intel/common) but for FLOCKDN only. This option for the
whole chipset lockdown on older platforms only made sense because the
lockdown was done in SMM to allow the payload to call into coreboot. As
SMM is not a good idea and reimplementing the whole lockdown in the pay-
load isn't either, just skipping flash locking bits seems to be the
right way.

Please take care that this only affects a clean boot, i.e. not a resume
when the payload is not going to be executed.

Post by Youness Alaoui
- Should I make the chipset_lockdown (currently used for locking the
BIOS CNTL register from LPC and SPI controllers) into an OR-ed flags
variable where we can say : chipset_lockdown = LOCKDOWN_COREBOOT |
LOCKDOWN_SPI | LOCKDOWN_PROTECTED_RANGES ?

The current `chipset_lockdown` option is nonsense. 1. during review when
I noticed a flaw in the LOCKDOWN_FSP path, the answer was something like
"but we set it to coreboot for all boards in the tree". So it seems the
author didn't even intend to add an option but just did it because eve-
rything else was an option? 2. Having to maintain two variants in core-
boot makes it harder to keep it secure. Please just kill this option and
all but the LOCKDOWN_COREBOOT path. Then add the Kconfig option
men-tioned above on this path.

Post by Youness Alaoui
- Should I make a single new config variable to decide what to
lockdown (LPC_BIOS, SPI_BIOS, SPI_BAR, SPI_PROTECTED_RANGES) and only
set them if the CHIPSET_LOCKDOWN_COREBOOT is set ? And if
chipset_lockdown is set to CHIPSET_LOCKDOWN_FSP not lockdown anything
at all ?
- Do we want to keep the protected ranges locked down at all, have
them configurable or completely remove that as I don't see the point
in using the discrete lock register ?

I would prefer to have the PR registers locked right after they are set,
in the same function. Also remove fast_spi_pr_dlock() or at least fix
the comment above it, it seems the author didn't understand the meaning
of "discrete" in this context. Optionally, if CHIPSEC complains other-
wise, set the discrete locks for empty PRRs before setting FLOCKDN.
AIUI, FLOCKDN always locks the PRRs.

Post by Youness Alaoui
Once I see a consensus on what's the best way to move forward, I'll
implement it and push it for review.

Thank you for looking into this it would be very nice to have this
cleaned up. I guess if we do it right, we'll have less code that is
more useful.

Post by Youness Alaoui
Note: I think these only affect hardware sequencing though so I assume
someone could always use software sequencing to do the writes. As long
as the FLOCKDN bit isn't set though, I could remove all write-related
opcodes from the software sequencing register, which would also
prevent someone using swseq to do writes.

In the past, we (at secunet) had FLOCKDN always set in the payload just
like you plan to do. We also made it the payload's responsibility to set
the OPMENU accordingly before setting FLOCKDN. You can have write op-
codes in the menu, they won't work on protected regions. But if you have
a partially protected flash (e.g. vboot), they are still useful.

Also note that swseq is not an option anymore since Skylake (IIRC, the
ME protects the flash-cycle go bit in its default configuration). With
only hwseq, you can only access the flash chip's first status register
which makes many security features unusable. So we have to rely on the
protected regions :-/ I hope Intel is going to fix that for future plat-
forms (or with an ME update if that could add more hwseq commands).

Nico

[Peter Stuge]

avoid any malware writing to the flash

Just disallow flash writes by the platform. Allow flash writes only
by dedicated hardware (maybe ChromeEC?) which implements a simple and
efficient security protocol.

Looking for a software solution is IMO like Intel trying to secure SMM.


//Peter

[Sam Kuper]

Post by Peter Stuge

avoid any malware writing to the flash

Just disallow flash writes by the platform. Allow flash writes only
by dedicated hardware (maybe ChromeEC?) which implements a simple and
efficient security protocol.

Relevant URL: https://www.chromium.org/chromium-os/ec-development#TOC-Write-Protect

Post by Peter Stuge
Looking for a software solution is IMO like Intel trying to secure SMM.

Hear, hear!

[Youness Alaoui]

This post might be inappropriate. Click to display it.

[Peter Stuge]

Post by Youness Alaoui
We don't have/use ChromeEC and I think that telling every user that
they'd need dedicated hardware to update their BIOS makes no sense.

I think you can decide what hardware your products include, right? I
meant dedicated hardware on the mainboard.

Post by Youness Alaoui

Post by Peter Stuge
Looking for a software solution is IMO like Intel trying to secure SMM.

I don't see why that would be true, the software solution is pretty
simple. You boot, you can write to the flash in a secure environment,

Intel also considered SMM a secure environment, until they realised
that it isn't. These days I think they consider ME a secure environment.


//Peter

[Sam Kuper]

I have been giving Youness's reply some thought.

Post by Peter Stuge

Post by Youness Alaoui

Post by Sam Kuper
https://www.chromium.org/chromium-os/ec-development#TOC-Write-Protect

We don't have/use ChromeEC and I think that telling every user that
they'd need dedicated hardware to update their BIOS makes no sense.

I think you can decide what hardware your products include, right? I
meant dedicated hardware on the mainboard.

I think Youness's point, essentially, was that with:

- Heads running from the ROM chip; and
- suitable secrets sealed in the TPM; and
- additional suitable secrets sealed in a Nitrokey;

any additional dedicated hardware on the motherboard would be
unnecessary in order to achieve:

- a "secure", pre-OS environment in which to upgrade Heads; and
- a way to prevent the OS from flashing the ROM.

(Youness, please correct me if I misunderstood you.)

That is all good stuff, and I want it to be achieved. However, I don't
think it goes far enough.

I know that several Chromebooks, as described at the URL above,
include a hardware switch (typically implemented as a screw or bolt
acting as a *latching* SPST switch) that allows ROM flashing to be
enabled/disabled. This seems to me a step in the right direction, but
I don't think it goes far enough, either.

Personally, I would prefer that, in addition to the Heads approach, a
hardware switch should be present, but unlike on the Chromebooks it
should be a *momentary* switch that stays in the write-protect
position by default, and that has to be held in the write-enable
position in order for the flashing process to be able to begin.
(Essentially, a "dead man's handle" or fail-safe.) This mitigates two
potential attack vectors:

1. a user, after she sets her Chromebook-style latching hardware
switch to write-enable and flashes the ROM, forgets to set the
hardware switch back to write-protect, leaving the ROM vulnerable;

2. a remote attacker finds a way to write a "badHeads" to the ROM from
the OS.[1][2][3]

Post by Peter Stuge

Post by Youness Alaoui

Post by Sam Kuper

Post by Peter Stuge
Looking for a software solution is IMO like Intel trying to secure SMM.

I don't see why that would be true, the software solution is pretty
simple. You boot, you can write to the flash in a secure environment,

Intel also considered SMM a secure environment, until they realised
that it isn't. These days I think they consider ME a secure environment.

Ouch! It's unkind to liken Heads developers to ME developers... :p

- Sam


[1] https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/3

[2] https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/4

[3] https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/6

[Nico Huber]

Post by Sam Kuper

Post by Peter Stuge

avoid any malware writing to the flash

Just disallow flash writes by the platform. Allow flash writes only
by dedicated hardware (maybe ChromeEC?) which implements a simple and
efficient security protocol.

Relevant URL: https://www.chromium.org/chromium-os/ec-development#TOC-Write-Protect

This seems to state the opposite of what Peter suggested, i.e. the host
firmware is responsible of validating the EC firmware('s update) and
not the other way around. IMHO, a good idea.

Nico

[ron minnich]

It's not a screw in Chromebooks any more, see vadim's excellent OSFC.io
talk on how it works now.

I think the momentary switch would not be acceptable to anyone for cost and
reliability reasons. The way chromebooks do the protection now is really
well done.

Post by Sam Kuper

Post by Peter Stuge

avoid any malware writing to the flash

Just disallow flash writes by the platform. Allow flash writes only
by dedicated hardware (maybe ChromeEC?) which implements a simple and
efficient security protocol.

https://www.chromium.org/chromium-os/ec-development#TOC-Write-Protect
This seems to state the opposite of what Peter suggested, i.e. the host
firmware is responsible of validating the EC firmware('s update) and
not the other way around. IMHO, a good idea.
Nico
--
https://mail.coreboot.org/mailman/listinfo/coreboot

[Sam Kuper]

Post by ron minnich
It's not a screw in Chromebooks any more, see vadim's excellent OSFC.io
talk on how it works now.

Vadim Bendebury? This talk below?

https://osfc.io/talks/google-secure-microcontroller-and-ccd-closed-case-debugging

If so, is there a video or audio recording available? Thanks.

Post by ron minnich
I think the momentary switch would not be acceptable to anyone for cost

Small momentary switches cost pennies and laptops usually have about a
hundred of them fitted, of various kinds. (Power on/off/suspend;
volume up/down; keyboard keys; maybe others.) So, fitting laptops with
momentary switches is definitely acceptable to manufacturers.

Post by ron minnich
and reliability reasons.

Such switches are often rated for ~100,000 cycles. It seems unlikely
that any laptop or its owner would live long enough to flash the ROM
chip even close to 100,000 times. So, I don't anticipate a reliability
problem.

Post by ron minnich
The way chromebooks do the protection now is really well done.

I look forward to reading Vadim's slides, and perhaps also to watching
or listening to his talk. Thanks for the pointer.

[ron minnich]

Post by Sam Kuper
Small momentary switches cost pennies and laptops usually have about a
hundred of them fitted, of various kinds. (Power on/off/suspend;
volume up/down; keyboard keys; maybe others.) So, fitting laptops with
momentary switches is definitely acceptable to manufacturers.

I'm guessing you don't work in a company that designs or builds laptops :-)
b/c they agonize over parts like this. I ran into one situation where the
ODM removed a single pulldown to save cost. One little
almost-too-small-to-see part which cost a fraction of a cent. But a laptop
BOM is a consequence of thousands of decisions of this type.

Nope, the switch is definitely a non-starter, esp. given that there are
solutions that don't require it.

It's not just the part. A single simple part like that has all kinds of
follow-on effects that are not obvious unless you've been at a company
which designs and builds consumer electronics.

[Sam Kuper]

This post might be inappropriate. Click to display it.

[Youness Alaoui]

Oh boy, lots of emails to answer! So first, thanks for everyone who
shared their input, I very much appreciate it.

Post by Peter Stuge
I think you can decide what hardware your products include, right? I

meant dedicated hardware on the mainboard.

Yes, but I'm currently looking for a solution to existing hardware,
not for the next laptop Purism produces. And by 'dedicated hardware' I
thought you meant only allow users to update their BIOS using an
external SPI flasher, which would be impractical of course.

Post by Peter Stuge

Post by ron minnich
It's not just the part. A single simple part like that has all kinds of
follow-on effects that are not obvious unless you've been at a company
which designs and builds consumer electronics.

Thank you for the perspective. I do understand that changing one
component can affect others.
Purism isn't a typical laptop company. The addition of hardware
switches, to control webcam, mic and Wi-Fi, is one of the USPs for
their Librem models. These undoubtedly had knock-on effects for the
BOM. Purism was undeterred by that. In that context...
I'm just asking for one more switch.
So, Youness and others at Purism: if you are reading this, please do
spec a momentary switch to control flashing on future Librems. Your
security-conscious users will thank you for it.

Yes, I already suggested it for the next iteration. It wouldn't be a
switch though, but rather a low profile 90-degrees jumper on the
motherboard.
As for your question earlier about someone forgetting it. I would
assume that it would be easy to have the Heads menu show a big warning
to the user if it's left unprotected (I assume there would be a way to
detect if WP# is 1/0 through a GPIO (or other method) without being
able to use that GPIO to override the WP# value).
Right now, if you boot into linux while ignoring tampering, you get
your ttys in red, as a huge and very visible warning.
Also, yes Sam, you did understand me perfectly, thanks!

Post by Peter Stuge
--
https://mail.coreboot.org/mailman/listinfo/coreboot

[Sam Kuper]

Post by Youness Alaoui

[...] Youness and others at Purism: if you are reading this, please do
spec a momentary switch to control flashing on future Librems. Your
security-conscious users will thank you for it.

Yes, I already suggested it for the next iteration.

Great!

Post by Youness Alaoui
It wouldn't be a switch though, but rather a low profile 90-degrees
jumper on the motherboard.

This seems to imply that each time a Librem user wants to internally
flash the ROM, she would have to:

- power down the laptop(?);
- implement ESD precautions;
- remove the half a dozen or so tiny bottom case screws, without
losing them, and without stripping their heads or threads or threaded
inserts;
- remove the bottom case;
- move a tiny motherboard jumper to "write-enable", without losing it;
- power up the laptop with the bottom case off(?);
- run FlashROM (or equivalent);
- power down the laptop again(?);
- move the tiny motherboard jumper to "write-protect", without losing it;
- push-fit the bottom case correctly;
- insert the half a dozen or so tiny bottom case screws, without
losing them, and without stripping their heads or threads or threaded
inserts;
- power the laptop back up(?).

Surely, having a momentary switch next to the existing kill switches
would be *much* more user-friendly! With such a switch, such a user
would just have to:

- hold the switch down while starting Flashrom (or equivalent);
- release the switch and let the flashing process finish.

Post by Youness Alaoui
As for your question earlier about someone forgetting it. I would
assume that it would be easy to have the Heads menu show a big warning
to the user if it's left unprotected

Your assumption fails against a BadHeads attack.

Post by Youness Alaoui
Right now, if you boot into linux while ignoring tampering, you get
your ttys in red, as a huge and very visible warning.

Only in the absence of BadHeads.

Post by Youness Alaoui
Also, yes Sam, you did understand me perfectly, thanks!

Great! :)

[Nico Huber]

Post by Sam Kuper

Post by Youness Alaoui

[...] Youness and others at Purism: if you are reading this, please do
spec a momentary switch to control flashing on future Librems. Your
security-conscious users will thank you for it.

Yes, I already suggested it for the next iteration.

Great!

Post by Youness Alaoui
It wouldn't be a switch though, but rather a low profile 90-degrees
jumper on the motherboard.

This seems to imply that each time a Librem user wants to internally
- power down the laptop(?);
- implement ESD precautions;
- remove the half a dozen or so tiny bottom case screws, without
losing them, and without stripping their heads or threads or threaded
inserts;
- remove the bottom case;
- move a tiny motherboard jumper to "write-enable", without losing it;
- power up the laptop with the bottom case off(?);
- run FlashROM (or equivalent);
- power down the laptop again(?);
- move the tiny motherboard jumper to "write-protect", without losing it;
- push-fit the bottom case correctly;
- insert the half a dozen or so tiny bottom case screws, without
losing them, and without stripping their heads or threads or threaded
inserts;
- power the laptop back up(?).
Surely, having a momentary switch next to the existing kill switches
would be *much* more user-friendly! With such a switch, such a user
- hold the switch down while starting Flashrom (or equivalent);
- release the switch and let the flashing process finish.

tldr; whether the effort to disable write protection is reasonable
or not depends on what you want to write protect.

You two might have different kinds of updates in mind. You don't need
a switch for every update. With a read-only root of trust, for instance,
that is secured by the switch or jumper or whatever, you could still
update everything else with software only. That root of trust could
either verify a signature of the following firmware parts (like vboot
does) or start a measuring chain or (ideally) do both.

Separating functional updates from those that change platform-ownership
is a key feature of vboot. Without such separation, you'll either make
owning too easy or updating too hard.

Post by Sam Kuper

Post by Youness Alaoui
As for your question earlier about someone forgetting it. I would
assume that it would be easy to have the Heads menu show a big warning
to the user if it's left unprotected

Your assumption fails against a BadHeads attack.

You need to tamper more than just HEADS, otherwise the attestation of
the firmware (e.g. via TOTP or a Librem Key) would fail. So BadHeads
seems to be the wrong name here, but I understand your concerns. But...
there are technical pitfalls that leave the same problem for a momentary
switch: Unless you use real custom chips, you'll have to use the access
protection current chips support and in the case of SPI NOR flashes
there usually is no simple on/off signal that tells the chip to deny
writes. Usually, you only signal it to protect its write-protection
configuration which you could forget to set correctly after flashing
too.

What I'm trying to show here is that there is no simple solution that
can be implemented in a single spot like putting a switch next to the
existing kill switches. One shouldn't rush to implement new schemes
that might seem better (compared to the state of the art, which is
vboot, imho). If one wants to enhance the security of their next batch
of laptops, implementing something compatible to what is already there
and has itself proven to work would be a good approach (and it seems
to me that is what Youness has in mind).

Also, Sam, you seem to be pushing for a hardware addition that suits
your own threat model (which I don't know). I can only assume that you
would only want to install updates that you just compiled yourself.
But that's not everybody's use case.

Nico

[Sam Kuper]

Post by Nico Huber
tldr; whether the effort to disable write protection is reasonable
or not depends on what you want to write protect.

Agreed.

Post by Nico Huber
You two might have different kinds of updates in mind. You don't need
a switch for every update. With a read-only root of trust, for instance,
that is secured by the switch or jumper or whatever, you could still
update everything else with software only. That root of trust could
either verify a signature of the following firmware parts (like vboot
does) or start a measuring chain or (ideally) do both.
Separating functional updates from those that change platform-ownership
is a key feature of vboot. Without such separation, you'll either make
owning too easy or updating too hard.

In principle, I agree. But in practice, Librems don't seem to possess
this kind of separation (yet?).

Post by Nico Huber

Post by Sam Kuper

Post by Youness Alaoui
As for your question earlier about someone forgetting it. I would
assume that it would be easy to have the Heads menu show a big warning
to the user if it's left unprotected

Your assumption fails against a BadHeads attack.

You need to tamper more than just HEADS, otherwise the attestation of
the firmware (e.g. via TOTP or a Librem Key) would fail.

That was not my understanding.

See this outline of a putative "BadHeads" attack:
https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/3

Also see Kyle Rankin's apparent confirmation that such attacks succeed
(on current Librems):
https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/4

If I was mistaken about this, then I apologise.

Post by Nico Huber
But...
there are technical pitfalls that leave the same problem for a momentary
switch: Unless you use real custom chips, you'll have to use the access
protection current chips support and in the case of SPI NOR flashes
there usually is no simple on/off signal that tells the chip to deny
writes. Usually, you only signal it to protect its write-protection
configuration which you could forget to set correctly after flashing
too.

Does this mean that Peter Stuge's suggestion to (de-)solder a typical
SPI flash chip's write-protect pin was erroneous?

https://media.ccc.de/v/30C3_-_5529_-_en_-_saal_2_-_201312271830_-_hardening_hardware_and_choosing_a_goodbios_-_peter_stuge#webm

Post by Nico Huber
What I'm trying to show here is that there is no simple solution that
can be implemented in a single spot like putting a switch next to the
existing kill switches. One shouldn't rush to implement new schemes
that might seem better (compared to the state of the art, which is
vboot, imho). If one wants to enhance the security of their next batch
of laptops, implementing something compatible to what is already there
and has itself proven to work would be a good approach (and it seems
to me that is what Youness has in mind).

I agree about not leaping to conclusions. Sorry if it seemed that this
is what I was doing. A couple of posts back, I did try to make clear
that I believe security improvements in the firmware will be valuable
(albeit probably not sufficient; i.e. a hardware switch of some kind
would also be helpful).

Post by Nico Huber
Also, Sam, you seem to be pushing for a hardware addition that suits
[wanting] to install updates that you just compiled yourself.
But that's not everybody's use case.

Whether the context is a solo user, a small organisation, or a large
one, it seems to me that upgrading at least *some* parts of the
firmware should require physical access.

As for how much effort it should be to gain that physical access, I
agree with your implicit point that if changing the root of trust is
separated from upgrading other parts of the firmware, then it may make
sense for the former, which should probably be done only rarely, to be
effortful (e.g. to require removal of the bottom case, and use of ESD
precautions). This would reduce the risk of a passer-by being able to
change the root of trust on a laptop that someone has accidentally
left running and unlocked for a moment while going to the bathroom or
whatever.

[Nico Huber]

Post by Sam Kuper

Post by Nico Huber
tldr; whether the effort to disable write protection is reasonable
or not depends on what you want to write protect.

Agreed.

Post by Nico Huber
You two might have different kinds of updates in mind. You don't need
a switch for every update. With a read-only root of trust, for instance,
that is secured by the switch or jumper or whatever, you could still
update everything else with software only. That root of trust could
either verify a signature of the following firmware parts (like vboot
does) or start a measuring chain or (ideally) do both.
Separating functional updates from those that change platform-ownership
is a key feature of vboot. Without such separation, you'll either make
owning too easy or updating too hard.

In principle, I agree. But in practice, Librems don't seem to possess
this kind of separation (yet?).

The software doesn't. But it's much easier to add it later once the
hardware supports it. IMHO, design decisions for future hardware should
prepare for state of the art security and not the security of yesterdays
soft/firmware.

Post by Sam Kuper

Post by Nico Huber

Post by Sam Kuper

Post by Youness Alaoui
As for your question earlier about someone forgetting it. I would
assume that it would be easy to have the Heads menu show a big warning
to the user if it's left unprotected

Your assumption fails against a BadHeads attack.

You need to tamper more than just HEADS, otherwise the attestation of
the firmware (e.g. via TOTP or a Librem Key) would fail.

That was not my understanding.
https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/3
Also see Kyle Rankin's apparent confirmation that such attacks succeed
https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/4
If I was mistaken about this, then I apologise.

Sorry, I won't have the time to read through all this. In theory, it
depends on when the measuring is started. If the measuring starts only
late in HEADS (and not in coreboot), you are right. Generally you'd have
to tamper the piece of software that starts the measuring.

Post by Sam Kuper

Post by Nico Huber
But...
there are technical pitfalls that leave the same problem for a momentary
switch: Unless you use real custom chips, you'll have to use the access
protection current chips support and in the case of SPI NOR flashes
there usually is no simple on/off signal that tells the chip to deny
writes. Usually, you only signal it to protect its write-protection
configuration which you could forget to set correctly after flashing
too.

Does this mean that Peter Stuge's suggestion to (de-)solder a typical
SPI flash chip's write-protect pin was erroneous?
https://media.ccc.de/v/30C3_-_5529_-_en_-_saal_2_-_201312271830_-_hardening_hardware_and_choosing_a_goodbios_-_peter_stuge#webm

No, I wouldn't think so (without watching that video). What I meant is
that lifting your finger from a momentary switch won't be enough. You,
or the software you use, could still "forget" other things with the same
effect. The problem is that what the flash chip does when the /WP pin is
asserted usually depends on the chip's configuration (that you might
have to change to be able to flash; depends on the chip I guess). Just
read your chip's datasheet if you want to know the whole story.

Nico

[Sam Kuper]

Post by Nico Huber

Post by Sam Kuper

Post by Nico Huber
Separating functional updates from those that change platform-ownership
is a key feature of vboot. Without such separation, you'll either make
owning too easy or updating too hard.

In principle, I agree. But in practice, Librems don't seem to possess
this kind of separation (yet?).

The software doesn't. But it's much easier to add it later once the
hardware supports it. IMHO, design decisions for future hardware should
prepare for state of the art security and not the security of yesterdays
soft/firmware.

In principle, I agree. I was just trying to clarify the reason for my
choice of earlier comments.

Post by Nico Huber

Post by Sam Kuper

Post by Nico Huber
You need to tamper more than just HEADS, otherwise the attestation of
the firmware (e.g. via TOTP or a Librem Key) would fail.

That was not my understanding.
https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/3
Also see Kyle Rankin's apparent confirmation that such attacks succeed
https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/4

Sorry, I won't have the time to read through all this. In theory, it
depends on when the measuring is started. If the measuring starts only
late in HEADS (and not in coreboot), you are right. Generally you'd have
to tamper the piece of software that starts the measuring.

The putative attack bypasses the measuring. As such, I can't see why
it makes any difference whether the measuring starts early (in
Coreboot), or late (in Heads). Sorry if I'm misunderstanding something
basic.

Post by Nico Huber

Post by Sam Kuper

Post by Nico Huber
there are technical pitfalls that leave the same problem for a momentary
switch: Unless you use real custom chips, you'll have to use the access
protection current chips support and in the case of SPI NOR flashes
there usually is no simple on/off signal that tells the chip to deny
writes. Usually, you only signal it to protect its write-protection
configuration which you could forget to set correctly after flashing
too.

Does this mean that Peter Stuge's suggestion to (de-)solder a typical
SPI flash chip's write-protect pin was erroneous?
https://media.ccc.de/v/30C3_-_5529_-_en_-_saal_2_-_201312271830_-_hardening_hardware_and_choosing_a_goodbios_-_peter_stuge#webm

No, I wouldn't think so (without watching that video). What I meant is
that lifting your finger from a momentary switch won't be enough. You,
or the software you use, could still "forget" other things with the same
effect. The problem is that what the flash chip does when the /WP pin is
asserted usually depends on the chip's configuration (that you might
have to change to be able to flash; depends on the chip I guess). Just
read your chip's datasheet if you want to know the whole story.
Indeed soldering the WP#-pin to ground is not sufficient to disable
writes on any and every flash chip, but for chips where writes *can*
be disabled electrically it is the key step that overrides software.
Many flash chips support a write enable policy for parts and/or all of
the chip. (See status register/block protect bits in flash chip data
sheets.) The WP#-pin usually controls whether software is allowed to
change that policy. If the WP#-pin is connected to ground then the
policy can only be changed from write-enable to write-disable, but
the other way around requires disconnecting WP# from ground first.
(That's what a switch would do.)
It is worth noting (I think I mentioned it in that talk) that not
all chips store the policy in non-volatile memory - only some do!
Some flash chips forget the write-protect policy on reset, meaning
that the WP#-pin has no effect from reset until a software-issued
command sets a write-protect policy.
That's potentially a problem if something can access the flash chip
before the x86 root-of-trust runs.

You are both correct that I was assuming a chip that obeys the
write-protect pin regardless of the firmware. I would be surprised if
Purism ordered their motherboards to be built with chips of which that
is not true, but perhaps that was unduly optimistic of me. I have not
attempted to check (yet).

Thank you both for your informative replies :)


Youness and others at Purism: it would be great if Purism could be
sure not only to spec, but also to list on the Librem specification
pages on the website, a SPI flash ROM chip that *does* obey its
write-protect pin regardless of firmware. Thanks :)

[Nico Huber]

Post by Sam Kuper

Post by Nico Huber

Post by Sam Kuper

Post by Nico Huber
You need to tamper more than just HEADS, otherwise the attestation of
the firmware (e.g. via TOTP or a Librem Key) would fail.

That was not my understanding.
https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/3
Also see Kyle Rankin's apparent confirmation that such attacks succeed
https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/4

Sorry, I won't have the time to read through all this. In theory, it
depends on when the measuring is started. If the measuring starts only
late in HEADS (and not in coreboot), you are right. Generally you'd have
to tamper the piece of software that starts the measuring.

The putative attack bypasses the measuring. As such, I can't see why
it makes any difference whether the measuring starts early (in
Coreboot), or late (in Heads). Sorry if I'm misunderstanding something
basic.

Sorry, we might talk past each other here. I was talking about type 2.
attacks (in your forum post). But if you consider type 1. and can just
skip the attestation, you are right, the measuring doesn't matter any
more. But there are other means to detect this (e.g. a TPM sealed disk-
encryption key; if you can't boot anymore, you'll notice).

About type 2.: To me HEADS is a coreboot payload that runs after core-
boot. If the measuring starts in coreboot, you have to tamper coreboot
which is "more than just HEADS" (in my terms).

Nico

[Peter Stuge]

Post by Sam Kuper

Post by Nico Huber
But...
there are technical pitfalls that leave the same problem for a momentary
switch: Unless you use real custom chips, you'll have to use the access
protection current chips support and in the case of SPI NOR flashes
there usually is no simple on/off signal that tells the chip to deny
writes. Usually, you only signal it to protect its write-protection
configuration which you could forget to set correctly after flashing
too.

Does this mean that Peter Stuge's suggestion to (de-)solder a typical
SPI flash chip's write-protect pin was erroneous?

Indeed soldering the WP#-pin to ground is not sufficient to disable
writes on any and every flash chip, but for chips where writes *can*
be disabled electrically it is the key step that overrides software.

Many flash chips support a write enable policy for parts and/or all of
the chip. (See status register/block protect bits in flash chip data
sheets.) The WP#-pin usually controls whether software is allowed to
change that policy. If the WP#-pin is connected to ground then the
policy can only be changed from write-enable to write-disable, but
the other way around requires disconnecting WP# from ground first.
(That's what a switch would do.)

It is worth noting (I think I mentioned it in that talk) that not
all chips store the policy in non-volatile memory - only some do!

Some flash chips forget the write-protect policy on reset, meaning
that the WP#-pin has no effect from reset until a software-issued
command sets a write-protect policy.

That's potentially a problem if something can access the flash chip
before the x86 root-of-trust runs.


//Peter

[Nico Huber]

Post by Peter Stuge

avoid any malware writing to the flash

Just disallow flash writes by the platform. Allow flash writes only
by dedicated hardware (maybe ChromeEC?) which implements a simple and
efficient security protocol.

It's not as easy as you might think. You are looking forward to an
additional flash chip at least because the ME needs direct access to
a SPI flash (you could try to route that through the EC as well, but
that would be everything but simple). Then your customers might ask
for suspend-to-RAM, for which you need to cache memory-training data
somewhere. You can't authenticate this data to the EC. That's solvable
too, ofc. But there might be more pitfalls. And I'm not convinced that
you'd end up with a simpler solution than your host firmware flipping
a bit at the right point in time.

Post by Peter Stuge
Looking for a software solution is IMO like Intel trying to secure SMM.

No matter if you run it on the EC or the host processor, it will be a
software solution. You can make things simpler with a dedicated control-
ler, right. But if you succeed still depends on the skills of software
developers. ECs can be attacked too (especially if they have a host
interface for software updates).

Nico

[Martin Kepplinger]

Post by Youness Alaoui
Hi,
I'm trying to add a way to lock the SPI flash to be read-only via
software *after* coreboot boots. The scenario is basically with using
Heads, you could authenticate to it (with a yubikey/nitrokey/librem
key) then be able to flash a new rom (update your BIOS), but once you
boot an OS, Heads would first lock the flash so it can't be written
to.
This should add some security to avoid any malware writing to the
flash, or someone booting into a USB stick and using that to flash a
malicious BIOS, but still gives the user the freedom of updating their
flash whenever they want to.

I might be wrong, but since Heads already authenticates to you via TOTP,
this wouldn't really add extra security, wouldn't it?

[Nico Huber]

Post by Martin Kepplinger

Post by Youness Alaoui
Hi,
I'm trying to add a way to lock the SPI flash to be read-only via
software *after* coreboot boots. The scenario is basically with using
Heads, you could authenticate to it (with a yubikey/nitrokey/librem
key) then be able to flash a new rom (update your BIOS), but once you
boot an OS, Heads would first lock the flash so it can't be written
to.
This should add some security to avoid any malware writing to the
flash, or someone booting into a USB stick and using that to flash a
malicious BIOS, but still gives the user the freedom of updating their
flash whenever they want to.

I might be wrong, but since Heads already authenticates to you via TOTP,
this wouldn't really add extra security, wouldn't it?

This is the most common misunderstanding about a measured boot. If you
don't have separate hardware that starts the measuring (usually you let
the firmware measure itself), you need a firmware part that starts the
measuring and is read-only for an attacker (referred to as read-only or
static `root of trust`). Otherwise you leave the decision what to mea-
sure to the attacker (and he can choose to measure the original software
before his tampering instead of the running program, and TOTP will still
work flawlessly).

So it's the other way around: without this, TOTP doesn't provide any
security at all.

Nico

[Martin Kepplinger]

Post by Nico Huber

Post by Martin Kepplinger

Post by Youness Alaoui
Hi,
I'm trying to add a way to lock the SPI flash to be read-only via
software *after* coreboot boots. The scenario is basically with using
Heads, you could authenticate to it (with a yubikey/nitrokey/librem
key) then be able to flash a new rom (update your BIOS), but once you
boot an OS, Heads would first lock the flash so it can't be written
to.
This should add some security to avoid any malware writing to the
flash, or someone booting into a USB stick and using that to flash a
malicious BIOS, but still gives the user the freedom of updating their
flash whenever they want to.

I might be wrong, but since Heads already authenticates to you via TOTP,
this wouldn't really add extra security, wouldn't it?

This is the most common misunderstanding about a measured boot. If you
don't have separate hardware that starts the measuring (usually you let
the firmware measure itself), you need a firmware part that starts the
measuring and is read-only for an attacker (referred to as read-only or
static `root of trust`). Otherwise you leave the decision what to mea-
sure to the attacker (and he can choose to measure the original software
before his tampering instead of the running program, and TOTP will still
work flawlessly).
So it's the other way around: without this, TOTP doesn't provide any
security at all.
Nico

thanks! My high-level understanding was that Heads uses the
TPM as said "root of trust" and the TOTP shared secret will be lost
in any changed firmware.

So a changed firmware would basically need to write PCRs to the TPM
in order for the "PCR matching" to succeed and release the valid TOTP
secret. Be it by measuring and remembering the original firmware or
somehow else.

I don't know why, but I've though that the TPM would prevent a modified
firmware to do this -.-

http://osresearch.net/Keys is quite good, but maybe we'd need a wiki
with real setups compared, or something. I fear that I'm not the only
one
who's confused with trusted boot stuff.

As a quick fix, couldn't Heads offer to create an image with the IFD
re-locked,
in order to force (yourself) to hardware-flashing. Has this been
discussed?

thanks

martin

[Nico Huber]

Post by Martin Kepplinger

Post by Nico Huber

Post by Martin Kepplinger

Post by Youness Alaoui
Hi,
I'm trying to add a way to lock the SPI flash to be read-only via
software *after* coreboot boots. The scenario is basically with using
Heads, you could authenticate to it (with a yubikey/nitrokey/librem
key) then be able to flash a new rom (update your BIOS), but once you
boot an OS, Heads would first lock the flash so it can't be written
to.
This should add some security to avoid any malware writing to the
flash, or someone booting into a USB stick and using that to flash a
malicious BIOS, but still gives the user the freedom of updating their
flash whenever they want to.

I might be wrong, but since Heads already authenticates to you via TOTP,
this wouldn't really add extra security, wouldn't it?

This is the most common misunderstanding about a measured boot. If you
don't have separate hardware that starts the measuring (usually you let
the firmware measure itself), you need a firmware part that starts the
measuring and is read-only for an attacker (referred to as read-only or
static `root of trust`). Otherwise you leave the decision what to mea-
sure to the attacker (and he can choose to measure the original software
before his tampering instead of the running program, and TOTP will still
work flawlessly).
So it's the other way around: without this, TOTP doesn't provide any
security at all.
Nico

thanks! My high-level understanding was that Heads uses the
TPM as said "root of trust" and the TOTP shared secret will be lost
in any changed firmware.
So a changed firmware would basically need to write PCRs to the TPM
in order for the "PCR matching" to succeed and release the valid TOTP
secret. Be it by measuring and remembering the original firmware or
somehow else.

Correct.

Post by Martin Kepplinger
I don't know why, but I've though that the TPM would prevent a modified
firmware to do this -.-

Alas, they can't (on their own). OTOH, TPMs are already too complex for
real security IMO. Adding more features would just weaken it further.

Post by Martin Kepplinger
http://osresearch.net/Keys is quite good, but maybe we'd need a wiki
with real setups compared, or something. I fear that I'm not the only one
who's confused with trusted boot stuff.
As a quick fix, couldn't Heads offer to create an image with the IFD
re-locked,

I don't understand why you would unlock the IFD in the first place. But
anyway, the usual lock settings only protect the IFD itself and the ME
firmware, not the BIOS region for the host firmware (e.g. coreboot).
Also, if you'd protect the BIOS region too, coreboot couldn't write to
the flash itself anymore which would prevent suspend-to-RAM to work; but
maybe you are too security concerned for that anyway ;)

Post by Martin Kepplinger
in order to force (yourself) to hardware-flashing. Has this been discussed?

Ofc, it has. And there is even an option in coreboot to lock the flash
(after coreboot is done with it). But this is only available for few
platforms (Sandy/Ivy Bridge IIRC; config LOCK_SPI_FLASH_RO).

Nico