5 ms·

It was hard to read past the attitude that Secure Boot is the enemy. That’s just not the case, and if the author believes it is, it kind of undermines their exp

It was hard to read past the attitude that Secure Boot is the enemy. That’s just not the case, and if the author believes it is, it kind of undermines their expertise/the rest of the writing.

reanimus 6y ago
Yeah, hemming and hawing over whether or not an x86/64 PC can disable Secure Boot in 2020 is a bit silly when it's been a certification requirement by Microsoft for ages
- vxNsr 6y ago
  As someone who knows little to nothing about UEFI except what I read on these types of blogs and comments, what do you mean that secure boot is no longer an issue? and that it's been a certificate requirement by microsoft?
  - Arnavion 6y ago
    https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot https://docs.microsoft.com/en-us/windows/security/informatio... >All x86-based Certified For Windows 10 PCs must meet several requirements related to Secure Boot: > - They must have Secure Boot enabled by default. > - They must trust Microsoft’s certificate (and thus any bootloader Microsoft has signed). > - They must allow the user to configure Secure Boot to trust other bootloaders. > - They must allow the user to completely disable Secure Boot. The last two points in particular. It's been this way since SB was introduced. Note that this requirement does not apply to non-x86 devices. In particular, ARM devices (Windows RT) are explicitly required to disallow SB from being disabled, to meet the certification requirement.
    - morganvachon 6y ago
      "They must trust Microsoft’s certificate (and thus any bootloader Microsoft has signed)." This one in particular always pissed me off, and I'm glad it only applies to pre-built machines that come with Windows 10 preinstalled. If the individual motherboard makers ever decide they need to be "certified for Windows 10" and start auto-trusting a certificate for closed-source commercial software, I'm left with no choice but to either stick with my "old" (not really that old) hardware or switch to another platform like POWER9.
      - easton 6y ago
        You can revoke the keys as a user, it’s just that the system has to trust the Microsoft CA out of the box. If you have purchased a device with Secure Boot capability (including a motherboard), it trusts Microsoft’s CA (since it would be extremely confusing for 99% of users if Windows wouldn’t boot without trusting a key). My Ryzen board trusted Microsoft out of the box, it has to if they want to pass Windows logo certification. You can check yours here: https://partner.microsoft.com/en-us/dashboard/hardware/search/cpl https://partner.microsoft.com/en-us/dashboard/hardware/searc...
        morganvachon 6y ago
        "...it’s just that the system has to trust the Microsoft CA out of the box" That's the entirety of my complaint. Thanks for the link! My board is not on it as I assumed.
        reanimus 6y ago
        You can remove Microsoft's certs from the trust store used by the board, though. You can choose to keep them to facilitate dual boot with Secure Boot on, but you can also choose to eject them from the trust store. Sure, they're loaded by default, and you can argue that we can't prove the board isn't gonna trust them behind your back -- but that applies to older non-open hardware too. My bigger annoyance is Intel Boot Guard. I want Intel to let us control the firmware more directly -- even if it requires some physical authorization/kills some DRM component in ME or something. But that's not happening anytime soon...
      - p_l 6y ago
        Full compliance with Windows 10 Enterprise certification requires ability to enter Setup Mode, where all certificates are deleted and owner has to reload the whole certificate database from scratch. The requirements mentioned by grandparent are for setup where without any extra configuration you can approach a computer with Windows 10 install media and it will install properly.
        6y ago
  - easton 6y ago
    Microsoft has always required (on x86, ARM is different) that for Windows logo certification Secure Boot must be able to be disabled, you must trust Microsoft’s CA and the third-party CA that they run (and that Red Hat/Ubuntu/Debian use to sign their builds) and that the user must be able to load their own keys. This means that any x86 device sold with UEFI Secure Boot can still boot Linux (or if it can’t, it’s not Secure Boot’s fault). https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot https://docs.microsoft.com/en-us/windows/security/informatio...
    - hda2 6y ago
      That used to be the case for x86, but not anymore: https://www.zdnet.com/article/microsoft-to-stop-linux-older-windows-from-running-on-windows-8-pcs/ https://www.zdnet.com/article/microsoft-to-stop-linux-older-...
      - easton 6y ago
        No, it's the other way around. It originally was as the article described, and once Microsoft probably got scared about antitrust (or thought about how the heck they'd buy hardware for Azure and not be able to load their own secure boot keys), they changed the procedure. As of 2015-ish, the information I linked applies (for x86).
raxxorrax 6y ago
I don't think it is hard to read past it and I don't think there are only positive sides. If it stays an optional component it might be true, but it would be naive to just let this be the only perspective in hindsight of development of closed systems like smartphones.
- hackmiester 6y ago
  But the author states that they still use computers from before 2012 because they are avoiding EFI. Why? From 2012 until present, computers have been produced that run any EFI binary you want. Why not buy one of those? It's no different than sticking with pre-2012 machines, except you aren't attached to cruft from the 1980s anymore.

It was hard to read past the attitude that Secure Boot is the enemy. That’s just not the case, and if the author believes it is, it kind of undermines their expertise/the rest of the writing.

reanimus 6y ago

Yeah, hemming and hawing over whether or not an x86/64 PC can disable Secure Boot in 2020 is a bit silly when it's been a certification requirement by Microsoft for ages

vxNsr 6y ago
As someone who knows little to nothing about UEFI except what I read on these types of blogs and comments, what do you mean that secure boot is no longer an issue? and that it's been a certificate requirement by microsoft?
- Arnavion 6y ago
  https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot https://docs.microsoft.com/en-us/windows/security/informatio... >All x86-based Certified For Windows 10 PCs must meet several requirements related to Secure Boot: > - They must have Secure Boot enabled by default. > - They must trust Microsoft’s certificate (and thus any bootloader Microsoft has signed). > - They must allow the user to configure Secure Boot to trust other bootloaders. > - They must allow the user to completely disable Secure Boot. The last two points in particular. It's been this way since SB was introduced. Note that this requirement does not apply to non-x86 devices. In particular, ARM devices (Windows RT) are explicitly required to disallow SB from being disabled, to meet the certification requirement.
  - morganvachon 6y ago
    "They must trust Microsoft’s certificate (and thus any bootloader Microsoft has signed)." This one in particular always pissed me off, and I'm glad it only applies to pre-built machines that come with Windows 10 preinstalled. If the individual motherboard makers ever decide they need to be "certified for Windows 10" and start auto-trusting a certificate for closed-source commercial software, I'm left with no choice but to either stick with my "old" (not really that old) hardware or switch to another platform like POWER9.
    - easton 6y ago
      You can revoke the keys as a user, it’s just that the system has to trust the Microsoft CA out of the box. If you have purchased a device with Secure Boot capability (including a motherboard), it trusts Microsoft’s CA (since it would be extremely confusing for 99% of users if Windows wouldn’t boot without trusting a key). My Ryzen board trusted Microsoft out of the box, it has to if they want to pass Windows logo certification. You can check yours here: https://partner.microsoft.com/en-us/dashboard/hardware/search/cpl https://partner.microsoft.com/en-us/dashboard/hardware/searc...
      - morganvachon 6y ago
        "...it’s just that the system has to trust the Microsoft CA out of the box" That's the entirety of my complaint. Thanks for the link! My board is not on it as I assumed.
        reanimus 6y ago
        You can remove Microsoft's certs from the trust store used by the board, though. You can choose to keep them to facilitate dual boot with Secure Boot on, but you can also choose to eject them from the trust store. Sure, they're loaded by default, and you can argue that we can't prove the board isn't gonna trust them behind your back -- but that applies to older non-open hardware too. My bigger annoyance is Intel Boot Guard. I want Intel to let us control the firmware more directly -- even if it requires some physical authorization/kills some DRM component in ME or something. But that's not happening anytime soon...
    - p_l 6y ago
      Full compliance with Windows 10 Enterprise certification requires ability to enter Setup Mode, where all certificates are deleted and owner has to reload the whole certificate database from scratch. The requirements mentioned by grandparent are for setup where without any extra configuration you can approach a computer with Windows 10 install media and it will install properly.
      - 6y ago
- easton 6y ago
  Microsoft has always required (on x86, ARM is different) that for Windows logo certification Secure Boot must be able to be disabled, you must trust Microsoft’s CA and the third-party CA that they run (and that Red Hat/Ubuntu/Debian use to sign their builds) and that the user must be able to load their own keys. This means that any x86 device sold with UEFI Secure Boot can still boot Linux (or if it can’t, it’s not Secure Boot’s fault). https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot https://docs.microsoft.com/en-us/windows/security/informatio...
  - hda2 6y ago
    That used to be the case for x86, but not anymore: https://www.zdnet.com/article/microsoft-to-stop-linux-older-windows-from-running-on-windows-8-pcs/ https://www.zdnet.com/article/microsoft-to-stop-linux-older-...
    - easton 6y ago
      No, it's the other way around. It originally was as the article described, and once Microsoft probably got scared about antitrust (or thought about how the heck they'd buy hardware for Azure and not be able to load their own secure boot keys), they changed the procedure. As of 2015-ish, the information I linked applies (for x86).

raxxorrax 6y ago

I don't think it is hard to read past it and I don't think there are only positive sides. If it stays an optional component it might be true, but it would be naive to just let this be the only perspective in hindsight of development of closed systems like smartphones.

hackmiester 6y ago
But the author states that they still use computers from before 2012 because they are avoiding EFI. Why? From 2012 until present, computers have been produced that run any EFI binary you want. Why not buy one of those? It's no different than sticking with pre-2012 machines, except you aren't attached to cruft from the 1980s anymore.