BIOS Lock does not work as expected

Dasharo / dasharo-issues

The Dasharo issue tracker

https://dasharo.com/

24 stars 0 forks source link

BIOS Lock does not work as expected #754

Open mkopec opened 5 months ago

mkopec commented 5 months ago

Device

PC Engines apu4

Dasharo version

Dasharo (coreboot+UEFI) v0.9.0

Affected component(s) or functionality

BIOS Lock

Brief summary

The BIOS Boot Medium Lock feature does not respect the UEFI menu setting

How reproducible

100%

How to reproduce

tie WP# to ground
reboot in Firmware Update Mode
attempt to update WP_RO region

Expected behavior

bootblock is updated

Actual behavior

bootblock is not updated

Screenshots

No response

Additional context

If I unset the WP# jumper then I can write to the BIOS again.

Solutions you've tried

No response

miczyg1 commented 5 months ago

How do you expect the bootblock to be updated? tie WP# to ground essentially means to activate the protection. Nothing will be able to disable the protection, unless you pull the WP pin up again. The actual behavior described in the issue is correct.

macpijan commented 5 months ago

So what is the purpose of this option?

mkopec commented 5 months ago

@miczyg1 in that case having the option at all seems unnecessary, if the jumper is needed to enable and disable the protection anyway

miczyg1 commented 5 months ago

@mkopec @macpijan it seems you still don't understand how it works...

If you remove the option, you will have no protection. Asserted WP pin alone does not give any protection if SRP and BPs are not set. The UEFI option ensures the SRP and BPs are set.

Of course SRP and BPs remain set as long as WP pin is asserted, even after a reboot (maybe power off as well). But something has to program SRP and BPs at least once (right before or while WP pin is grounded).

macpijan commented 5 months ago

@mkopec @macpijan it seems you still don't understand how it works...

If we don't, users certainly will not understand this. Maybe you should document this behavior?

miczyg1 commented 5 months ago

@macpijan PC Engines had this feature for a very long time. It is not something new...

Flash locking was also described here: https://github.com/pcengines/sortbootorder

mkopec commented 5 months ago

We should at least update the helptext in the setup menu so that it describes this behavior.

mkopec commented 5 months ago

Another point of info: Disabling the option does not unset SRP and BP, it only skips setting them. This means the ranges stay protected until one tries to reflash the firmware by flashrom or other tool.

mkopec commented 5 months ago

Ideally I would want this feature to work like this:

If enabled, coreboot will attempt to set write protection
If disabled, coreboot will attempt to disable write protection - currently it does not
If the WP jumper is set, the option should be grayed out - to reflect that the setting cannot be changed without unsetting the jumper.

miczyg1 commented 5 months ago

If the WP jumper is set, the option should be grayed out - to reflect that the setting cannot be changed without unsetting the jumper.

There is no status bit to check for WP state. What you can do is: https://github.com/pcengines/sortbootorder/blob/master/utils/spi_lock_menu.c#L221

But then you may lock yourself if WP is really asserted.