Malicious bios or boot firmware protection?

Framework Desktop
1

Whats to stop malware from infecting boot firmware? Does it only accept images signed by frame.work? Is there something confirming that a user is in front of the machine and wants new firmware when it reboots?

2

I am an end-user like you.
I don’t know for sure about the BIOS. I assume that needs a FW signature.

For the EC, anyone can change that firmware. That is pretty safe, because the EC cannot do much, it has no internet connection, or direct access to all RAM. It talks to the CPU over GPIOs, and can switch the CPU on and off. If you write the wrong firmware to the EC, it bricks the laptop/desktop. FW have given us open source access to the EC firmware, so we can fix bits of it ourselves, as end-users.

There is also USB/PD firmware. I don’t know if that needs a signature or not.

So, simplistically, it might be quite easy for a Virus to brick your laptop. But, to be fair, that has been the case with all laptops and desktop since about 20 years ago, since they removed the need for a mainboard hardware jumper to be able to flash the BIOS.

3

Not true with recent macbooks, chromebooks, intel laptops with trusted boot and some, maybe all, of the open source edk2 based coreboot payloads. For example, Dasharo uefi has an option specifically to disable write protections for one boot when its time to update firmware. Those options can be locked behind a password and you could enable trusted boot so it refuses to boot firmware not signed with the key its fused with. Then you just reflash the firmware with a signed image to fix it. For some motherboards, the way to update firmware is too boot into the firmware to install a new image from usb. You may still be able infect it in person, but its harder to do remotely.

AMD has platform secure boot, but I couldn’t find anything about it on frame.work.
Everything I could find on AMDs site referred to enterprise, server, and arm socs.

1 Like
4

Secure boot needs Signing which it’s a very scary process and I am not sure Framework can do it in this scale.

5

Secure boot is for verifying what the bios is booting, like the os kernel. Framework supports secure boot and uses intel boot guard, which does verify the firmware. Or as intel calls it, the pre os environment. I’d like to know if they do anything like that for AMD systems like the framework desktop. They outsource uefi to Insyde, who should be able to protect a signing key.

6

Could someone show the output of “fwupdmgr security”? You can run it as user. You can read about it here, https://fwupd.org/

7

Heres the results. This is reasonable firmware protection.

$ fwupdmgr security
Host Security ID: HSI:3! (v2.0.12)

HSI-1
✔ SMM locked down:               Locked
✔ BIOS firmware updates:         Enabled
✔ Fused platform:                Locked
✔ Supported CPU:                 Valid
✔ TPM empty PCRs:                Valid
✔ TPM v2.0:                      Found
✔ UEFI bootservice variables:    Locked
✔ UEFI platform key:             Valid
✔ UEFI secure boot:              Enabled

HSI-2
✔ SPI write protection:          Enabled
✔ IOMMU:                         Enabled
✔ Platform debugging:            Locked
✔ TPM PCR0 reconstruction:       Valid

HSI-3
✔ SPI replay protection:         Enabled
✔ CET Platform:                  Supported
✔ Pre-boot DMA protection:       Enabled
✔ Suspend-to-idle:               Enabled
✔ Suspend-to-ram:                Disabled

HSI-4
✔ Processor rollback protection: Enabled
✔ SMAP:                          Enabled
✘ Encrypted RAM:                 Not supported

Runtime Suffix -!
✔ CET OS Support:                Supported
✔ fwupd plugins:                 Untainted
✔ Linux swap:                    Encrypted
✔ UEFI db:                       Valid
✘ Linux kernel lockdown:         Disabled
✘ Linux kernel:                  Tainted

This system has HSI runtime issues.
» https://fwupd.github.io/hsi.html#hsi-runtime-suffix
8

99% of the “virus” come from the manufacturers. After write-protect was removed from BIOS, forced BIOS updates pushed by windows, reduced CPU performance, removed S3 sleep retroactively, laptop bricked (needs chip-level repair), removed undervolting, reduced RAM speed. The list go on and on…

I don’t trust the so called firmware security, it’s pro- modern standby and anti-S3. Some people prefer faster resume speed (assume the computer never overheated in bags) others prefer a longer standby endurance. It should be both available and up to the user’s choice, not some random criteria and use security as an excuse for coercion. Linux shouldn’t go in this way to be honest