3 ms·

If by "compromised already at step zero" you mean "just the way computers worked for decades prior to secure boot", then yeah, I suppose. The issue that I have

If by "compromised already at step zero" you mean "just the way computers worked for decades prior to secure boot", then yeah, I suppose. The issue that I have heard people bring up is that it could potentially make it harder to install free and open source operating systems and thus turn consumer-grade and relatively cheap computers into less of a tool that you can use the way you want and more into an appliance. For all the panic that ensued when stuff like secure boot and similar were first announced, and the fact that I still seem able to install my Linux distro of choice, I as somebody who has not gotten personally invested in this am not in a position to know how real such an issue is. But I would like to know what proponents of secure boot think the technology solves and why what we had before inadequately addressed security needs. Because it seems to me that e.g. Windows will still happily get infected with viruses such that whether the boot process itself has been compromised, or just what comes immediately thereafter, does not matter too much. Or does it?

tsimionescu 6y ago
Secure boot, when working correctly, prevents the survival of rootkits. This alone is not sufficient, but it is necessary in order to allow a user of a system where a rootkit was installed to know this. Without secure boot, it is basically impossible to detect the existence of a well written rootkit, since it can control the OS tmand hide itself from any OS API, whether internal or external.
- AnthonyMouse 6y ago
  > Without secure boot, it is basically impossible to detect the existence of a well written rootkit, since it can control the OS tmand hide itself from any OS API, whether internal or external. You can detect the existence of a rootkit by booting from known-clean read-only media and then scanning for it. It's even possible to implement "secure boot" this way without any hardware support -- have known-clean read-only boot media that contains your signing keys and then verifies and boots the operating system of your choice. Implementing this in rushed closed-source system firmware is then purely a misfeature, along with the legitimate concern that it could lead to systems where the device owner can't install their own signing keys. Give people a USB stick with a hardware write protect switch, not signing keys hard-coded in firmware.
  - tsimionescu 6y ago
    That does not solve the issue of a corrupted BIOS/UEFI, right? I assume at least that UEFI Secure Boot also protects itself from any attempt to be replaced without proper signed keys. Without this kind of protection, you either have to have a readonly BIOS/UEFI (so no possibility to issue updates), or you have a root-writeable, and so root-kit-able BIOS/UEFI.
    - AnthonyMouse 6y ago
      You don't need all the firmware to be read-only, only the firmware update code, which can then require a hardware jumper to be set in order to update the firmware. Then the firmware can't be corrupted without physical access to set the jumper, and even if it is, the owner can still re-flash clean firmware because the update code is strictly read-only and therefore still clean. And you already need to be able to at least detect that someone has had physical access, otherwise you can't even be sure that the device hasn't been replaced with a compromised one that forwards your credentials to the attacker.

tsimionescu 6y ago

Secure boot, when working correctly, prevents the survival of rootkits. This alone is not sufficient, but it is necessary in order to allow a user of a system where a rootkit was installed to know this. Without secure boot, it is basically impossible to detect the existence of a well written rootkit, since it can control the OS tmand hide itself from any OS API, whether internal or external.

AnthonyMouse 6y ago
> Without secure boot, it is basically impossible to detect the existence of a well written rootkit, since it can control the OS tmand hide itself from any OS API, whether internal or external. You can detect the existence of a rootkit by booting from known-clean read-only media and then scanning for it. It's even possible to implement "secure boot" this way without any hardware support -- have known-clean read-only boot media that contains your signing keys and then verifies and boots the operating system of your choice. Implementing this in rushed closed-source system firmware is then purely a misfeature, along with the legitimate concern that it could lead to systems where the device owner can't install their own signing keys. Give people a USB stick with a hardware write protect switch, not signing keys hard-coded in firmware.
- tsimionescu 6y ago
  That does not solve the issue of a corrupted BIOS/UEFI, right? I assume at least that UEFI Secure Boot also protects itself from any attempt to be replaced without proper signed keys. Without this kind of protection, you either have to have a readonly BIOS/UEFI (so no possibility to issue updates), or you have a root-writeable, and so root-kit-able BIOS/UEFI.
  - AnthonyMouse 6y ago
    You don't need all the firmware to be read-only, only the firmware update code, which can then require a hardware jumper to be set in order to update the firmware. Then the firmware can't be corrupted without physical access to set the jumper, and even if it is, the owner can still re-flash clean firmware because the update code is strictly read-only and therefore still clean. And you already need to be able to at least detect that someone has had physical access, otherwise you can't even be sure that the device hasn't been replaced with a compromised one that forwards your credentials to the attacker.