6 ms·

I remember when UEFI was about to be released, there were a lot of concerns about how this will completely block Linux installation, dual boot, etc on Windows c

by tsjq 6y ago

I remember when UEFI was about to be released, there were a lot of concerns about how this will completely block Linux installation, dual boot, etc on Windows computers. Did that problem happen? How was that solved?

salawat 6y ago
Technically solved by allowing you to manage your own keys. Just what any hobbyist wants to do to dual boot though. Sit down and read up on cryptographic signature verification! That'll make the hobby more approachable.
- freeone3000 6y ago
  DKMS allows for drivers to be installed without breaking the kernel signature. And Ubuntu and Red Hat and Fedora are all MS-signed (as will anyone else willing to go through the process, which is really only feasible for large orgs but is mostly just bureaucracy). So most hobbists will never need to mess with mokutil.
  - pantalaimon 6y ago
    > DKMS allows for drivers to be installed without breaking the kernel signature. how is this possible?
    - reanimus 6y ago
      You register an additional key, generated by you/the installer. Ubuntu automates it as part of setup, afaik Fedora doesn't but there are instructions for it. Ubuntu generates a key during installation, then requests UEFI register it as a secure boot signing key. You reboot, UEFI will verify in pre-boot that you asked for the key to be added (usually, some BIOSes let you disable this check). DKMS will use that key to sign the modules. Since the kernel gets the UEFI allowed keys from the firmware, it will see these signed modules as valid and load them.
    - MertsA 6y ago
      It's not, if a kernel was built and signed that allowed unsigned modules to be loaded that key should be revoked. The way kernel module loading works with secure boot is that modules are signed via kmodsign. https://ubuntu.com/blog/how-to-sign-things-for-secure-boot https://ubuntu.com/blog/how-to-sign-things-for-secure-boot
- reanimus 6y ago
  I actually really enjoyed learning about secure boot keys and TPMs and all when I was setting it up on my machine. Support for managing keys varies by board; some, especially older ones, don't let you do much, if at all, especially from within Linux. With modern firmware, you can add a self-generated key pretty easily, and it's not hard to do secure boot dual boot with Linux (or even macOS if you're using OpenCore, I think!). It does require a bit of reading up though. :)
noja 6y ago
Shims. MS signed some at the start, see https://docs.fedoraproject.org/en-US/Fedora/18/html/UEFI_Secure_Boot_Guide/sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Shim.html https://docs.fedoraproject.org/en-US/Fedora/18/html/UEFI_Sec... or https://wiki.debian.org/SecureBoot#Shim https://wiki.debian.org/SecureBoot#Shim
- navaati 6y ago
  What I don’t understand is, how did that not completely nullify the security promises of SecureBoot, rendering the whole exercise pointless in the end ?
  - wmf 6y ago
    Insecure shims can be revoked. https://blogs.gnome.org/hughsie/2020/08/17/updating-secure-boot-dbx-with-fwupd-and-the-lvfs/ https://blogs.gnome.org/hughsie/2020/08/17/updating-secure-b...
    - deleted 6y ago
      [deleted]
  - voxic11 6y ago
    Because the shim is still secure. > Shim then becomes the root of trust for all the other distro-provided UEFI programs. It embeds a further distro-specific CA key that is itself used for signing further programs (e.g. Linux, GRUB, fwupdate). This allows for a clean delegation of trust - the distros are then responsible for signing the rest of their packages. Shim itself should ideally not need to be updated very often, reducing the workload on the central auditing and CA teams.
  - monoideism 6y ago
    Because each stage of the boot sequence is still verified: - the root of trust is in the TPM - by default, the initial shim stage is verified using a Microsoft cert in the native trust database, and after the shim (which has an embedded Canonical cert) loads grub, then it verifies and loads the kennel Grub also has its own trust store it can use, if I recall.
rmrfstar 6y ago
You can manage your own secure boot keys [1]. [1] https://www.linuxjournal.com/content/take-control-your-pc-uefi-secure-boot https://www.linuxjournal.com/content/take-control-your-pc-ue...
Sunspark 6y ago
The bios in my computer has a toggle for secure boot to be on or off. I've had it off the whole time and there was no effect on any OS as a result. The issue was limited to bios setups that didn't allow this to be toggled, and for those, as pointed out by another, signed shims resolved that issue.
- MertsA 6y ago
  Even without the shims, right from the start Microsoft was requiring that OEMs allow secure boot to be disabled in settings if they wanted to pass Microsoft's "Windows Certification" requirement.
  - rbecker 6y ago
    A requirement they later dropped: https://tech.slashdot.org/story/15/03/20/2039251/oems-allowed-to-lock-secure-boot-in-windows-10-computers https://tech.slashdot.org/story/15/03/20/2039251/oems-allowe... First they require a lock, but also that the user gets the key. Next they require a lock, but the key may be withheld from the user. I wonder what they will require next. Their Surface RT line of laptops came without unlockable secure boot, so no alternative OS could be installed.
    - p_l 6y ago
      This is the problem with people not understanding how Secure Boot works, then reading specs that require such understanding. For max-level compatibility with Windows 10 Enterprise, there's a requirement that owner of the device can change all the keys. It doesn't require a "disable Secure Boot" setting. Worst case, the device won't permit you to keep it in what's called "Setup Mode" without some inconvenience, however you have to be able to enter Setup Mode. What's Setup Mode? Setup Mode is when the PK variable (PlatformKey) is empty, effectively disabling SecureBoot. This mode exists so that you can load new PK value. According to UEFI Secure Boot spec, it's supposed to be frozen by manufacturer. However, being able to set your own one is critical to some of the Windows Enterprise features, and as such a way to enter that mode is required by Windows certification.
MayeulC 6y ago
I think fear of an antitrust lawsuit is what kept Microsoft from locking it down completely (IIRC they did it on their RT line for a while, though).
- p_l 6y ago
  The UEFI spec insists on locked down - Microsoft sells features that depend on it being open, and sells them probably for much more than the value of dealing with rabid lawyers is.

by tsjq 6y ago

salawat 6y ago

Technically solved by allowing you to manage your own keys. Just what any hobbyist wants to do to dual boot though. Sit down and read up on cryptographic signature verification! That'll make the hobby more approachable.

freeone3000 6y ago
DKMS allows for drivers to be installed without breaking the kernel signature. And Ubuntu and Red Hat and Fedora are all MS-signed (as will anyone else willing to go through the process, which is really only feasible for large orgs but is mostly just bureaucracy). So most hobbists will never need to mess with mokutil.
- pantalaimon 6y ago
  > DKMS allows for drivers to be installed without breaking the kernel signature. how is this possible?
  - reanimus 6y ago
    You register an additional key, generated by you/the installer. Ubuntu automates it as part of setup, afaik Fedora doesn't but there are instructions for it. Ubuntu generates a key during installation, then requests UEFI register it as a secure boot signing key. You reboot, UEFI will verify in pre-boot that you asked for the key to be added (usually, some BIOSes let you disable this check). DKMS will use that key to sign the modules. Since the kernel gets the UEFI allowed keys from the firmware, it will see these signed modules as valid and load them.
  - MertsA 6y ago
    It's not, if a kernel was built and signed that allowed unsigned modules to be loaded that key should be revoked. The way kernel module loading works with secure boot is that modules are signed via kmodsign. https://ubuntu.com/blog/how-to-sign-things-for-secure-boot https://ubuntu.com/blog/how-to-sign-things-for-secure-boot
reanimus 6y ago
I actually really enjoyed learning about secure boot keys and TPMs and all when I was setting it up on my machine. Support for managing keys varies by board; some, especially older ones, don't let you do much, if at all, especially from within Linux. With modern firmware, you can add a self-generated key pretty easily, and it's not hard to do secure boot dual boot with Linux (or even macOS if you're using OpenCore, I think!). It does require a bit of reading up though. :)

noja 6y ago

Shims. MS signed some at the start, see https://docs.fedoraproject.org/en-US/Fedora/18/html/UEFI_Secure_Boot_Guide/sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Shim.html https://docs.fedoraproject.org/en-US/Fedora/18/html/UEFI_Sec... or https://wiki.debian.org/SecureBoot#Shim https://wiki.debian.org/SecureBoot#Shim

navaati 6y ago
What I don’t understand is, how did that not completely nullify the security promises of SecureBoot, rendering the whole exercise pointless in the end ?
- wmf 6y ago
  Insecure shims can be revoked. https://blogs.gnome.org/hughsie/2020/08/17/updating-secure-boot-dbx-with-fwupd-and-the-lvfs/ https://blogs.gnome.org/hughsie/2020/08/17/updating-secure-b...
  - deleted 6y ago
    [deleted]
- voxic11 6y ago
  Because the shim is still secure. > Shim then becomes the root of trust for all the other distro-provided UEFI programs. It embeds a further distro-specific CA key that is itself used for signing further programs (e.g. Linux, GRUB, fwupdate). This allows for a clean delegation of trust - the distros are then responsible for signing the rest of their packages. Shim itself should ideally not need to be updated very often, reducing the workload on the central auditing and CA teams.
- monoideism 6y ago
  Because each stage of the boot sequence is still verified: - the root of trust is in the TPM - by default, the initial shim stage is verified using a Microsoft cert in the native trust database, and after the shim (which has an embedded Canonical cert) loads grub, then it verifies and loads the kennel Grub also has its own trust store it can use, if I recall.

rmrfstar 6y ago

You can manage your own secure boot keys [1]. [1] https://www.linuxjournal.com/content/take-control-your-pc-uefi-secure-boot https://www.linuxjournal.com/content/take-control-your-pc-ue...

Sunspark 6y ago

The bios in my computer has a toggle for secure boot to be on or off. I've had it off the whole time and there was no effect on any OS as a result. The issue was limited to bios setups that didn't allow this to be toggled, and for those, as pointed out by another, signed shims resolved that issue.

MertsA 6y ago
Even without the shims, right from the start Microsoft was requiring that OEMs allow secure boot to be disabled in settings if they wanted to pass Microsoft's "Windows Certification" requirement.
- rbecker 6y ago
  A requirement they later dropped: https://tech.slashdot.org/story/15/03/20/2039251/oems-allowed-to-lock-secure-boot-in-windows-10-computers https://tech.slashdot.org/story/15/03/20/2039251/oems-allowe... First they require a lock, but also that the user gets the key. Next they require a lock, but the key may be withheld from the user. I wonder what they will require next. Their Surface RT line of laptops came without unlockable secure boot, so no alternative OS could be installed.
  - p_l 6y ago
    This is the problem with people not understanding how Secure Boot works, then reading specs that require such understanding. For max-level compatibility with Windows 10 Enterprise, there's a requirement that owner of the device can change all the keys. It doesn't require a "disable Secure Boot" setting. Worst case, the device won't permit you to keep it in what's called "Setup Mode" without some inconvenience, however you have to be able to enter Setup Mode. What's Setup Mode? Setup Mode is when the PK variable (PlatformKey) is empty, effectively disabling SecureBoot. This mode exists so that you can load new PK value. According to UEFI Secure Boot spec, it's supposed to be frozen by manufacturer. However, being able to set your own one is critical to some of the Windows Enterprise features, and as such a way to enter that mode is required by Windows certification.

MayeulC 6y ago

I think fear of an antitrust lawsuit is what kept Microsoft from locking it down completely (IIRC they did it on their RT line for a while, though).

p_l 6y ago
The UEFI spec insists on locked down - Microsoft sells features that depend on it being open, and sells them probably for much more than the value of dealing with rabid lawyers is.