6 ms·

There are two sides to this coin. Firstly there's the hardware vendors who make firmware, who decided to incorporate UEFI presumably because intel pushed it har

There are two sides to this coin. Firstly there's the hardware vendors who make firmware, who decided to incorporate UEFI presumably because intel pushed it hard (original efi booted itanium and is also found in older Macs). But it was certainly possible for a Linux vendor to have got a key into the kek and dB lists: https://mjg59.dreamwidth.org/12368.html https://mjg59.dreamwidth.org/12368.html That's from Matthew Garrett, who along with Peter Jones, were responsible for the first shim. A central authority like the Linux foundation could have stepped up here and could have since, actually. I understand why fedora/redhat preferred not to be in a privileged position but I can't help but feel someone ought to have stepped up. The other side of the coin is the windows logo program, that requires secure boot be turned on by default. For x86 I'm fairly sure it also requires that the user can take control of the platform key and therefore evict Microsoft keys from the firmware. It also requires that secure boot should be disabled. I'm fairly sure Microsoft did this because they realised there would be objections otherwise Microsoft's ARM hardware _is_ locked down with no such options and I object to that wholeheartedly. But then I also don't buy Apple kit for daily driver use for the same reason. Also luckily Microsoft are currently irrelevant in the arm space, although that might change with the serverready profiles. I am sure the process was onerous, but someone could have done it. Linux is big business in the server hardware space and intel for example contributed the thunderbolt code to the kernel. I am fairly sure they could between them organise a foundation and throw a few 100ks per year at maintaining a signing key for other distros independently to Microsoft. I don't believe any entirely locked down firmware ever made it into any x86 board.

my123 5y ago
> Microsoft's ARM hardware _is_ locked down with no such options That was for 32-bit Windows on Arm hardware. 64-bit Windows on Arm laptops/tablets have unlockable Secure Boot, with a regular SETUP interface and all.
- zahllos 5y ago
  That's really good news and I'm glad they decided to do that.
  - native_samples 5y ago
    All this does make Microsoft sound very reasonable, actually. People have been painting dystopian pictures of an ultra-locked down hardware future, complete with evil corporate overlordship etc for many years. Really as long as I've been using computers. Yet, here we are in 2021 and not only old hardware is still open but newly designed hardware too, and Microsoft has even been ensuring that platforms which didn't get the memo (mobile, ARM) open up. The problem with a completely unlocked bootloader is that the distinction between "a Linux distribution" and "malware" is not one that can be decided technologically. Otherwise malware could just install a heavily customized Linux kernel that directly boots into Windows, hot-patching it along the way, and who is to say it's not really Linux? Someone has to make that call for the ordinary userbase that doesn't care about operating systems and it sounds like out of an ideological fit of pique - what a surprise - Linux vendors just noped out and refused to do their part. Because, you know, malware is other people's problem. So now Microsoft finds themselves carrying water for their own competitor.
    - fragmede 5y ago
      Given Microsoft's losses with eg Windows mobile, their late entry into the cloud space, giving up on making their own web browser (engine), Microsoft's forced to play nice in order to compete. I don't understand your second part though. What is the "step up" available to Linux vendors that they didn't do?
      - native_samples 5y ago
        Take part in the UEFI secure boot process to get a key whitelisted that'd be shipped in hardware out of the box (e.g. one managed by the Linux Foundation).
      - native_samples 5y ago
        I feel maybe I should elaborate on this more because a lot of people in this thread don't seem to quite understand the UEFI thing. Yet I cannot see an error or oversight in the chain of logic, so Linux vendors really deliberately screwed themselves over here and it's quite impressive actually that Microsoft bailed them out. 1. Computer makers want to sell computers to the masses. This is reasonable. 2. The masses don't want un-removable malware that renders their virus scanners useless. Also reasonable. 3. Malware writers want to beat virus scanners by taking over the OS before it even boots, which is an unassailable position for them. This is "reasonable" from their POV. Likewise, computer makers - not just Microsoft - want to stop this from happening because it's a kinda game over move and there's nothing that really prevents it (pre UEFI) other than the fact that the programming is kind of tricky. 4. To fix this the computer maker must have some opinion about what the computer is willing to boot. Boot-loading code is henceforth separated into "good" code that makes users happy by letting them surf the web, print etc and "bad" code that makes users unhappy by screwing with their machine and data and possibly bank accounts. This appears to be unavoidable and can be implemented with cryptography. 5. But computer makers don't really want to have such an opinion because it's a live wire for geeks who run obscure operating systems. They just want to get rid of malware. So they need a default, reasonable whitelist that will make users happy, and then a way to edit that whitelist that is too difficult for users to get phished or scammed into doing by accident. Whitelisting public keys in the UEFI/BIOS screen seems like a reasonable approach to this. 6. To have a signing key that's shipped out of the box you must agree to some simple rules, like, you must actually not be malware, and you must not accidentally sign malware, and you must protect your key, and you must not sign a piece of software so open that it can be trivially wrapped around malware. The first three are easy but the sorts of guarantees best made by an institution, not an individual. Microsoft is an institution. "Linux hackers" are not. But, there is a Linux Foundation that could play the role and helpfully already own the Linux trademark (I think), so they already kinda get to decide what is and isn't really Linux. 7. The final condition is the harder one because it implies a chain of trust. Otherwise the malware writer can just create a bespoke Linux that boots into a minimalist Linux environment and then immediately unloads Linux and chains onwards to a patched Windows. So each whitelisted Linux distro needs to have a default opinion about what can run in kernel mode that is (again) overridable, but only by people who know what they're doing. Which Linux can do, via module signing. So no technical problem here. 8. At this point Linux vendors appear to have flounced out of the room and collectively decided they can tell the PC industry what to do by refusing to take part in the process. They were wrong, nobody gives a shit about desktop Linux because it has hardly any users. However they only realized this way too late, by which time PCs were already shipping without any Linux Foundation keys in the whitelist. What to do? 9. Answer: go crying to your primary competitor and pressure them/ask them nicely to fix your fuckup by using their own cert to sign your operating systems. This is kind of pathetic and it appears the Linux community has still never got its act together and set up a key whitelisting process.
KatrKat 5y ago
> I don't believe any entirely locked down firmware ever made it into any x86 board. There are some Android x86 devices that won't boot unsigned firmware and won't let you change the signing keys. But I've only seen that in non-BIOS, non-UEFI devices.
dogleash 5y ago
>But it was certainly possible for a Linux vendor to have got a key into the kek and dB lists: https://mjg59.dreamwidth.org/12368.html https://mjg59.dreamwidth.org/12368.html Your text is written in past tense. But if there is a maintained list why is nobody working to get linux vendor keys in now? Yeah, it'll take a while for the hardware cycle to refresh, but it's better than nothing.

my123 5y ago

> Microsoft's ARM hardware _is_ locked down with no such options That was for 32-bit Windows on Arm hardware. 64-bit Windows on Arm laptops/tablets have unlockable Secure Boot, with a regular SETUP interface and all.

zahllos 5y ago
That's really good news and I'm glad they decided to do that.
- native_samples 5y ago
  All this does make Microsoft sound very reasonable, actually. People have been painting dystopian pictures of an ultra-locked down hardware future, complete with evil corporate overlordship etc for many years. Really as long as I've been using computers. Yet, here we are in 2021 and not only old hardware is still open but newly designed hardware too, and Microsoft has even been ensuring that platforms which didn't get the memo (mobile, ARM) open up. The problem with a completely unlocked bootloader is that the distinction between "a Linux distribution" and "malware" is not one that can be decided technologically. Otherwise malware could just install a heavily customized Linux kernel that directly boots into Windows, hot-patching it along the way, and who is to say it's not really Linux? Someone has to make that call for the ordinary userbase that doesn't care about operating systems and it sounds like out of an ideological fit of pique - what a surprise - Linux vendors just noped out and refused to do their part. Because, you know, malware is other people's problem. So now Microsoft finds themselves carrying water for their own competitor.
  - fragmede 5y ago
    Given Microsoft's losses with eg Windows mobile, their late entry into the cloud space, giving up on making their own web browser (engine), Microsoft's forced to play nice in order to compete. I don't understand your second part though. What is the "step up" available to Linux vendors that they didn't do?
    - native_samples 5y ago
      Take part in the UEFI secure boot process to get a key whitelisted that'd be shipped in hardware out of the box (e.g. one managed by the Linux Foundation).
    - native_samples 5y ago
      I feel maybe I should elaborate on this more because a lot of people in this thread don't seem to quite understand the UEFI thing. Yet I cannot see an error or oversight in the chain of logic, so Linux vendors really deliberately screwed themselves over here and it's quite impressive actually that Microsoft bailed them out. 1. Computer makers want to sell computers to the masses. This is reasonable. 2. The masses don't want un-removable malware that renders their virus scanners useless. Also reasonable. 3. Malware writers want to beat virus scanners by taking over the OS before it even boots, which is an unassailable position for them. This is "reasonable" from their POV. Likewise, computer makers - not just Microsoft - want to stop this from happening because it's a kinda game over move and there's nothing that really prevents it (pre UEFI) other than the fact that the programming is kind of tricky. 4. To fix this the computer maker must have some opinion about what the computer is willing to boot. Boot-loading code is henceforth separated into "good" code that makes users happy by letting them surf the web, print etc and "bad" code that makes users unhappy by screwing with their machine and data and possibly bank accounts. This appears to be unavoidable and can be implemented with cryptography. 5. But computer makers don't really want to have such an opinion because it's a live wire for geeks who run obscure operating systems. They just want to get rid of malware. So they need a default, reasonable whitelist that will make users happy, and then a way to edit that whitelist that is too difficult for users to get phished or scammed into doing by accident. Whitelisting public keys in the UEFI/BIOS screen seems like a reasonable approach to this. 6. To have a signing key that's shipped out of the box you must agree to some simple rules, like, you must actually not be malware, and you must not accidentally sign malware, and you must protect your key, and you must not sign a piece of software so open that it can be trivially wrapped around malware. The first three are easy but the sorts of guarantees best made by an institution, not an individual. Microsoft is an institution. "Linux hackers" are not. But, there is a Linux Foundation that could play the role and helpfully already own the Linux trademark (I think), so they already kinda get to decide what is and isn't really Linux. 7. The final condition is the harder one because it implies a chain of trust. Otherwise the malware writer can just create a bespoke Linux that boots into a minimalist Linux environment and then immediately unloads Linux and chains onwards to a patched Windows. So each whitelisted Linux distro needs to have a default opinion about what can run in kernel mode that is (again) overridable, but only by people who know what they're doing. Which Linux can do, via module signing. So no technical problem here. 8. At this point Linux vendors appear to have flounced out of the room and collectively decided they can tell the PC industry what to do by refusing to take part in the process. They were wrong, nobody gives a shit about desktop Linux because it has hardly any users. However they only realized this way too late, by which time PCs were already shipping without any Linux Foundation keys in the whitelist. What to do? 9. Answer: go crying to your primary competitor and pressure them/ask them nicely to fix your fuckup by using their own cert to sign your operating systems. This is kind of pathetic and it appears the Linux community has still never got its act together and set up a key whitelisting process.

KatrKat 5y ago

> I don't believe any entirely locked down firmware ever made it into any x86 board. There are some Android x86 devices that won't boot unsigned firmware and won't let you change the signing keys. But I've only seen that in non-BIOS, non-UEFI devices.

dogleash 5y ago

>But it was certainly possible for a Linux vendor to have got a key into the kek and dB lists: https://mjg59.dreamwidth.org/12368.html https://mjg59.dreamwidth.org/12368.html Your text is written in past tense. But if there is a maintained list why is nobody working to get linux vendor keys in now? Yeah, it'll take a while for the hardware cycle to refresh, but it's better than nothing.