5 ms·

I keep hearing that Microsoft is making things "harder", but I've yet to see any evidence that this is true. All I can see is that Microsoft mandate that lapto

by growse 4y ago

I keep hearing that Microsoft is making things "harder", but I've yet to see any evidence that this is true. All I can see is that Microsoft mandate that laptop hardware sold with Windows installed have secure boot capability and that the MS-signing keys are shipped in the TPM. This has been true for, what, over 10 years? How are they making things harder?

candiddevmike 4y ago
There are quite a few instances[1] where adding your own signing keys bricks the device. [1] https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Using_your_own_keys https://wiki.archlinux.org/title/Unified_Extensible_Firmware...
- growse 4y ago
  Huh, wasn't aware of that. Reading through, it looks like this is just talking about Microsoft "Secured-core" hardware, which seems to be hardware specifically marketed to provide a Microsoft-certified boot chain. I'm not sure that's the same thing as Microsoft making it harder in general for people to bring and use their own keys (or just turn it off altogether).
  - Foxboron 4y ago
    It's a bit more complicated. The UEFI drivers and Linux distributions are signed by the same certificate, the "Microsoft 3rd party UEFI Certificate". UEFI Drivers can be Option ROM on the PCIe cards, commonly found of graphics cards. If you where to leave this certificate out of your boot chain, how would you validate this drivers? Well, you can't. This results in your not having any GPUs and your device is "bricked" until you can hopefully piggyback on something else. It's not really a proper brick. This is just a design flaw in my opinion. Microsoft taking the easy route for being the org responsible for signing UEFI code when there was no other options (LetsEncrypt wasnt a thing in 2010/2012). And I don't think Microsoft envisioned themselves in the position they are currently inn. There are workarounds though, you can read the drivers loaded during boot from the TPM Eventlog and enroll each driver into the approve list for Secure Boot (The `db` variable). But this isn't necessarily future proof if anything changes.
- vladvasiliu 4y ago
  As others have said, it's not a full-on brick (though I can see how it can be a pain to fix). However, the third-party MS certificate can be signed with your own keys, as described on that same page [1]. I don't have a need for that (my PCs don't need any option ROMs), but I did sign MS's main Windows key so that I can dual boot Win11 / Arch (which MS doesn't sign) with my own key registered in the UEFI. [1] https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Dual_booting_with_other_operating_systems https://wiki.archlinux.org/title/Unified_Extensible_Firmware...
AshamedCaptain 4y ago
A recent example https://mjg59.dreamwidth.org/59931.html https://mjg59.dreamwidth.org/59931.html , discussed here at HN https://news.ycombinator.com/item?id=32023868 https://news.ycombinator.com/item?id=32023868 , in which ironically MS is making it harder to run stuff which _is_ MS-signed (the current version of Windows being exempt, of course).
hulitu 4y ago
> I keep hearing that Microsoft is making things "harder", but I've yet to see any evidence that this is true. You shall try to run Windows 10. See calc.exe or Teams (though the web versions of 365 are also representative)
fweimer 4y ago
The Microsoft policies are unclear. I was around when Fedora came up with its current Secure Boot policies and may even have contributed to a somewhat maximalist interpretation. Fedora and others operate under the assumption that Secure Boot needs to prevent the execution of unsigned code in ring 0 (or the Arm equivalent), but is this actually required for a signature from Microsoft? Unclear. Plenty of distributions had their shims signed without kernel module signing implemented in the distribution. I think the current policy is here: https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916 https://techcommunity.microsoft.com/t5/hardware-dev-center/u... It doesn't mention kernel mode. The focus on kernel mode may not even be appropriate because many bad things can happen without kernel mode (wiping local disks, operating the hardware beyond safe parameters).
- deleted 4y ago
  [deleted]

by growse 4y ago

candiddevmike 4y ago

There are quite a few instances[1] where adding your own signing keys bricks the device. [1] https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Using_your_own_keys https://wiki.archlinux.org/title/Unified_Extensible_Firmware...

growse 4y ago
Huh, wasn't aware of that. Reading through, it looks like this is just talking about Microsoft "Secured-core" hardware, which seems to be hardware specifically marketed to provide a Microsoft-certified boot chain. I'm not sure that's the same thing as Microsoft making it harder in general for people to bring and use their own keys (or just turn it off altogether).
- Foxboron 4y ago
  It's a bit more complicated. The UEFI drivers and Linux distributions are signed by the same certificate, the "Microsoft 3rd party UEFI Certificate". UEFI Drivers can be Option ROM on the PCIe cards, commonly found of graphics cards. If you where to leave this certificate out of your boot chain, how would you validate this drivers? Well, you can't. This results in your not having any GPUs and your device is "bricked" until you can hopefully piggyback on something else. It's not really a proper brick. This is just a design flaw in my opinion. Microsoft taking the easy route for being the org responsible for signing UEFI code when there was no other options (LetsEncrypt wasnt a thing in 2010/2012). And I don't think Microsoft envisioned themselves in the position they are currently inn. There are workarounds though, you can read the drivers loaded during boot from the TPM Eventlog and enroll each driver into the approve list for Secure Boot (The `db` variable). But this isn't necessarily future proof if anything changes.
vladvasiliu 4y ago
As others have said, it's not a full-on brick (though I can see how it can be a pain to fix). However, the third-party MS certificate can be signed with your own keys, as described on that same page [1]. I don't have a need for that (my PCs don't need any option ROMs), but I did sign MS's main Windows key so that I can dual boot Win11 / Arch (which MS doesn't sign) with my own key registered in the UEFI. [1] https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Dual_booting_with_other_operating_systems https://wiki.archlinux.org/title/Unified_Extensible_Firmware...

AshamedCaptain 4y ago

A recent example https://mjg59.dreamwidth.org/59931.html https://mjg59.dreamwidth.org/59931.html , discussed here at HN https://news.ycombinator.com/item?id=32023868 https://news.ycombinator.com/item?id=32023868 , in which ironically MS is making it harder to run stuff which _is_ MS-signed (the current version of Windows being exempt, of course).

hulitu 4y ago

> I keep hearing that Microsoft is making things "harder", but I've yet to see any evidence that this is true. You shall try to run Windows 10. See calc.exe or Teams (though the web versions of 365 are also representative)

fweimer 4y ago

The Microsoft policies are unclear. I was around when Fedora came up with its current Secure Boot policies and may even have contributed to a somewhat maximalist interpretation. Fedora and others operate under the assumption that Secure Boot needs to prevent the execution of unsigned code in ring 0 (or the Arm equivalent), but is this actually required for a signature from Microsoft? Unclear. Plenty of distributions had their shims signed without kernel module signing implemented in the distribution. I think the current policy is here: https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916 https://techcommunity.microsoft.com/t5/hardware-dev-center/u... It doesn't mention kernel mode. The focus on kernel mode may not even be appropriate because many bad things can happen without kernel mode (wiping local disks, operating the hardware beyond safe parameters).

deleted 4y ago
[deleted]