5 ms·

> From that mindset what makes sense are hardware vendors including a cache of trusted third party root certificates from known other vendors. Today this would

> From that mindset what makes sense are hardware vendors including a cache of trusted third party root certificates from known other vendors. Today this would include Microslop, the same said hardware vendor, probably various respected Linux organizations/groups (Offhand, Linux Foundation, ArchLinux, Debian, IBM/RedHat, Oracle, SUSE, etc), similar for BSD... IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys. This way it is entirely agnostic of any cherrypicked list of "trust me" vendors. You'd still have most of the benefits of easy secure boot enrolling for those that don't know what it even is/how to do it while also allowing easy choosing of other OSes (at least on initial first boot). The main problem currently is option-ROM which has a tendency to cause the system to not even POST if secure boot is enabled without MS keys. Recently bricked a MoBo this way and even though it has 2 BIOS I can't actively choose which one to boot, it just has some "trust me, I know when" logic that chooses... well guess how well that is working for me...). The Asrock board I replaced it with though has an option for what it should do with such option-ROM when secure boot is active (don't run, always run, run if signed, ...) > The user should also be able to enroll their own CA certs as well; multiple of them. Useful for Organization, Division Unit, and system local signatures. Isn't this already the status quo?? > It would also, really, be nice if UEFI mandated a uniform access API (maybe it does) for local blobs stored in non mass-storage space. [...] I think UEFI is already complex enough and most of this can in a way already somewhat be handled by the EFI System Partition, e.g. systemd-boot can tell the UEFI to load (file system) drivers off of it (https://wiki.archlinux.org/title/Systemd-boot#Supported_file_systems https://wiki.archlinux.org/title/Systemd-boot#Supported_file...), I don't know if UEFI technically supports other types of drivers to be loaded.

bitwize 8mo ago
> IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys. Nobody wants to "install" an operating system. Computers should come with an OS preinstalled and ready to run. Everything else is a dead letter in terms of the marketplace.
- NekkoDroid 8mo ago
  I was talking about the same "install" that is already done (pre-installed on the drive that is first booted). Enrolling certs into the UEFI isn't something that needs to be done manually when "Setup Mode" is enabled, the bootloader can automatically enroll them. This already is a thing with the exception of the ship in "Setup Mode" part. Though some motherboard UEFI implementations are shit (as to be expected) and shit their pants when this happens. See last paragraph in this section as example: https://www.freedesktop.org/software/systemd/man/latest/systemd-boot.html#Files https://www.freedesktop.org/software/systemd/man/latest/syst...
  - bri3d 8mo ago
    What would be the point of this change? It erodes security in some moderately meaningful way (even easier to supply chain new computers by swapping the boot disk) to add what amounts to either a nag screen or nothing, in exchange for some ideological purity about Microsoft certificates?
    - NekkoDroid 8mo ago
      It really doesn't. UEFI are still not by default locked behind a password (can't be locked since you couldn't change settings in the UEFI if that were the case), so anyone that has access to change a drive can also disable secure boot or enroll their own keys if they want to do an actual supply chain attack. If your threat model is "has access to the system before first boot" you are fucked on anything that isn't locked down to only the manufacturer.
      - bri3d 8mo ago
        What if my threat model is "compromised the disk imaging / disk supply chain?" This is a plausible and real threat model, and represents a moderate erosion, like I said. UEFI Secure Boot is also just not a meaningful countermeasure to anyone with even a moderate paranoia level anyway, so it's all just goofing around at this point from a security standpoint. All of these "add more nag screens for freedom" measures like the grandparent post and yours don't really seem useful to me, though.
josephg 8mo ago
> IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys. I don’t think this works with the security model of secure boot. The secure boot rom is supposed to sit above the OS - as in, it’s more privileged than the OS. A compromise in the OS can’t lead to a compromise in secure boot. (And if it could, why even bother with secure boot in the first place?) If the OS could enrol whatever keys it wants, then malware could enrol its own malware keys and completely take over the system like that. And if that’s possible then secure boot provides no value.
- NekkoDroid 8mo ago
  The enrolling of the certs happen before the bootloader calls `ExitBootServices()` (I think that is what the function was called). Up until then the bootloader still has elevated priviledges and can modify certain UEFI stuff it can't after, including enrolling certs. systemd-boot can do that if you force it to (only does it by default on VMs cuz expectedly UEFI implementations in the wild are kinda shit)[1, 2] [1]: https://www.freedesktop.org/software/systemd/man/latest/systemd-boot.html#Files https://www.freedesktop.org/software/systemd/man/latest/syst... [2]: https://www.freedesktop.org/software/systemd/man/latest/loader.conf.html#force https://www.freedesktop.org/software/systemd/man/latest/load...
  - mjg59 8mo ago
    No, there's nothing special about the spec secure boot variables as far as boot services goes - you can modify those in runtime as well. We use boot service variables to protect the MOK key in Shim, but that's outside what the spec defines as secure boot.
gruez 8mo ago
>IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys. Sounds like browserchoice.eu but even more pointless. For the normies who don't care about what keys they want installed, it doesn't make a difference. For people who want to switch to linux, it also doesn't make a difference because unless they're setting up their computer for the first time, because the windows key would already be installed. The only thing it does is make setting up a new computer marginally easier for one specific case (ie. you want to install a non-windows operating system AND you don't want to dualboot), and ticks off a box for being "vendor agnostic" or whatever.
- fc417fc802 8mo ago
  On the contrary. It means only the currently installed OS will ever boot. If you wanted to switch you would enter the bios, clear the keys, then boot into the new system. That's roughly analogous to re-locking the bootloader on a pixel. Right now to achieve that level of security you have to manually enroll only the keys you want. Have fun with that process.
  - gruez 8mo ago
    >Right now to achieve that level of security you have to manually enroll only the keys you want. Have fun with that process. There will still be the situation with microsoft signing third party bootloaders, because various legitimate system utilities (eg. the kaspersky rescue disk mentioned in the OP) will still need it, and telling users to clear their keys willy-nilly is just going to train users to blindly clear their keys whenever something goes wrong.
- whateverboat 8mo ago
  You are missing the big picture. > The only thing it does is make setting up a new computer marginally easier for one specific case (ie. you want to install a non-windows operating system AND you don't want to dualboot), and ticks off a box for being "vendor agnostic" or whatever. this is much more important than you realize.
Sophira 8mo ago
> IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys. Let's be clear here. Most computers ship with Windows pre-installed, thanks to Microsoft's exclusivity deals with OEMs and the general assumption of Windows as the default OS. Most users, even those who want to use Linux exclusively, will never be able to utilize the first-OS-install functionality you propose, because the OEM will already have installed Windows on their behalf.

bitwize 8mo ago

> IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys. Nobody wants to "install" an operating system. Computers should come with an OS preinstalled and ready to run. Everything else is a dead letter in terms of the marketplace.

NekkoDroid 8mo ago
I was talking about the same "install" that is already done (pre-installed on the drive that is first booted). Enrolling certs into the UEFI isn't something that needs to be done manually when "Setup Mode" is enabled, the bootloader can automatically enroll them. This already is a thing with the exception of the ship in "Setup Mode" part. Though some motherboard UEFI implementations are shit (as to be expected) and shit their pants when this happens. See last paragraph in this section as example: https://www.freedesktop.org/software/systemd/man/latest/systemd-boot.html#Files https://www.freedesktop.org/software/systemd/man/latest/syst...
- bri3d 8mo ago
  What would be the point of this change? It erodes security in some moderately meaningful way (even easier to supply chain new computers by swapping the boot disk) to add what amounts to either a nag screen or nothing, in exchange for some ideological purity about Microsoft certificates?
  - NekkoDroid 8mo ago
    It really doesn't. UEFI are still not by default locked behind a password (can't be locked since you couldn't change settings in the UEFI if that were the case), so anyone that has access to change a drive can also disable secure boot or enroll their own keys if they want to do an actual supply chain attack. If your threat model is "has access to the system before first boot" you are fucked on anything that isn't locked down to only the manufacturer.
    - bri3d 8mo ago
      What if my threat model is "compromised the disk imaging / disk supply chain?" This is a plausible and real threat model, and represents a moderate erosion, like I said. UEFI Secure Boot is also just not a meaningful countermeasure to anyone with even a moderate paranoia level anyway, so it's all just goofing around at this point from a security standpoint. All of these "add more nag screens for freedom" measures like the grandparent post and yours don't really seem useful to me, though.

josephg 8mo ago

> IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys. I don’t think this works with the security model of secure boot. The secure boot rom is supposed to sit above the OS - as in, it’s more privileged than the OS. A compromise in the OS can’t lead to a compromise in secure boot. (And if it could, why even bother with secure boot in the first place?) If the OS could enrol whatever keys it wants, then malware could enrol its own malware keys and completely take over the system like that. And if that’s possible then secure boot provides no value.

NekkoDroid 8mo ago
The enrolling of the certs happen before the bootloader calls `ExitBootServices()` (I think that is what the function was called). Up until then the bootloader still has elevated priviledges and can modify certain UEFI stuff it can't after, including enrolling certs. systemd-boot can do that if you force it to (only does it by default on VMs cuz expectedly UEFI implementations in the wild are kinda shit)[1, 2] [1]: https://www.freedesktop.org/software/systemd/man/latest/systemd-boot.html#Files https://www.freedesktop.org/software/systemd/man/latest/syst... [2]: https://www.freedesktop.org/software/systemd/man/latest/loader.conf.html#force https://www.freedesktop.org/software/systemd/man/latest/load...
- mjg59 8mo ago
  No, there's nothing special about the spec secure boot variables as far as boot services goes - you can modify those in runtime as well. We use boot service variables to protect the MOK key in Shim, but that's outside what the spec defines as secure boot.

gruez 8mo ago

>IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys. Sounds like browserchoice.eu but even more pointless. For the normies who don't care about what keys they want installed, it doesn't make a difference. For people who want to switch to linux, it also doesn't make a difference because unless they're setting up their computer for the first time, because the windows key would already be installed. The only thing it does is make setting up a new computer marginally easier for one specific case (ie. you want to install a non-windows operating system AND you don't want to dualboot), and ticks off a box for being "vendor agnostic" or whatever.

fc417fc802 8mo ago
On the contrary. It means only the currently installed OS will ever boot. If you wanted to switch you would enter the bios, clear the keys, then boot into the new system. That's roughly analogous to re-locking the bootloader on a pixel. Right now to achieve that level of security you have to manually enroll only the keys you want. Have fun with that process.
- gruez 8mo ago
  >Right now to achieve that level of security you have to manually enroll only the keys you want. Have fun with that process. There will still be the situation with microsoft signing third party bootloaders, because various legitimate system utilities (eg. the kaspersky rescue disk mentioned in the OP) will still need it, and telling users to clear their keys willy-nilly is just going to train users to blindly clear their keys whenever something goes wrong.
whateverboat 8mo ago
You are missing the big picture. > The only thing it does is make setting up a new computer marginally easier for one specific case (ie. you want to install a non-windows operating system AND you don't want to dualboot), and ticks off a box for being "vendor agnostic" or whatever. this is much more important than you realize.

Sophira 8mo ago

> IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys. Let's be clear here. Most computers ship with Windows pre-installed, thanks to Microsoft's exclusivity deals with OEMs and the general assumption of Windows as the default OS. Most users, even those who want to use Linux exclusively, will never be able to utilize the first-OS-install functionality you propose, because the OEM will already have installed Windows on their behalf.