5 ms·

Obviously people might screw up, but the spec included a way to revoke any signed components that turned out not to be trustworthy "trustworthy" according to w

Obviously people might screw up, but the spec included a way to revoke any signed components that turned out not to be trustworthy "trustworthy" according to who? Remember that dystopia does not appear spontaneously, but steadily advances little-by-little. What's the summary? Microsoft (understandably) didn't want it to be possible to attack Windows by using a vulnerable version of grub that could be tricked into executing arbitrary code and then introduce a bootkit into the Windows kernel during boot. Microsoft did this by pushing a Windows Update that updated the SBAT variable to indicate that known-vulnerable versions of grub shouldn't be allowed to boot on those systems. Who is Microsoft to decide what others do on their machines? Should they have the right to police and censor software they have no control of? In the spirit of Linus Torvalds: Microsoft, fuck you! We are seeing the scenario Stallman alluded to over 2 decades ago slowly become a reality. He wasn't alone either. https://www.gnu.org/philosophy/right-to-read.en.html https://www.gnu.org/philosophy/right-to-read.en.html https://www.cl.cam.ac.uk/~rja14/tcpa-faq.html https://www.cl.cam.ac.uk/~rja14/tcpa-faq.html Things like TPM and "secure" boot were never envisioned for the interests of the user. The fact that it incidentally protects against 3rd party attacks just happened to be a good marketing point. "Those who give up freedom for security deserve neither."

palisade 2y ago
I guess in their defense the same attack can be used against any other OS so they're unintentionally protecting Linux as well, since they stated this was supposed to be a Windows-only system change. You can disable secure boot if you don't want to be secure. And, there is a way to disable the SBAT policy and keep secure boot if you want that, which is also insecure. Disable Secure Boot, login, sudo mokutil --set-sbat-policy delete, reboot again, re-enable secure boot. But, then you're susceptible to the attack. I think understandably, everyone is concerned because it felt like an affront by MS against Linux. But, I don't think that was their thought process at all.
- thwarted 2y ago
  > I think understandably, everyone is concerned because it felt like an affront by MS against Linux. But, I don't think that was their thought process at all. Given Microsoft's history, it's hard to really be sure. It's been a quarter century since The Halloween Documents and Microsoft definitely gives the air of contributing to the open source ecosystem today, but giants like having a big moat to defend, and old habits die hard. And Microsoft definitely has a reputation, even if, technically, undeserved.
  - palisade 2y ago
    There was nothing to be gained in this except ill will. Hanlon's Razor suggests they were in a hurry to fix a security issue and didn't dot their i's on checking for dual boot systems.
    - literalAardvark 2y ago
      It's a trolley problem, and it's not in Microsoft's locus of control to keep dual boot systems dual booting. So they don't try. They have never, ever supported anything other than the Microsoft bootloader[s], and if you work around that for instance it's pretty trivial to blow up your data by hibernating Windows and booting into a different partition. Resuming hibernation loads the old MFT onto the modified partition and you pretty much lose everything.
      - fuzzfactor 2y ago
        >hibernating Windows and booting into a different partition. Definitely to be avoided, along with a few other considerations. But experienced multibooters can usually reboot so quick that they have not had any need for hibernation since forever. It's almost like a valid excuse to not fully reboot a sluggish machine, more so than an energy-saving success. But I don't blame them.
    - account42 2y ago
      If you apply Hanlon's Razor to known malicious actors then the only one being stupid is you. In fact, it's a really bad heuristic for any corporation.
  - fuzzfactor 2y ago
    >it's hard to really be sure. Not that hard the more history there is. Keep in mind that the default since the beginning of Linux is for someone who wants their PC to be completely Linux, never had a need for anything originating from Microsoft whatsoever. Something in firmware would really be the worst and it was immediately obvious when UEFI & GPT were foisted, with Microsoft SecureBoot to boot, that something was rotten somewhere. A bigger threat than Linux was actually Windows 7, but with this exact hindsight now it can be seen how the knife was much further twisted for Linux well beyond the effective lifetime of W7. This was not just collateral damage, and it keeps on giving as if booby-trapped or time-bombed. Also remember that until Windows Vista, motherboards and business machines from all major manufacturers were always common where there was no way to alter the BIOS itself in any way without physical access. Like a jumper on the board internal to the PC. Sometimes special key combinations on laptops accepted only from its built-in keyboard. With BIOS settings only accessible to non-local users occasionally on specialized enterprise models according to options if present. When you wanted to upgrade your BIOS, or "re-flash" it due to something like power line corruption, you always booted to the floppy containing the desired firmware after enabling the delicate flashing operation manually. By the time Vista arrived it was often a bootable CDROM, or a USB stick formatted FAT32 with DOS to substitute for a floppy. Whichever way you did it you wrote the same binary file into the BIOS chip, then with further access completely disabled after that, never need to worry about malicious firmware whatsoever as long as you used a clean binary. The only possible way for a rootkit to infect your machine was to reside on your HDD. Usually in some of the spaces outside your filesystem that were so commonly unused it could lurk there and persist in spite of re-formatting. But no rootkit or preboot contamination could withstand a complete HDD zeroing, or replacement HDD if needed under emergency conditions. Well one day Microsoft must not have wanted people to ever boot DOS again, so they developed a need to access every BIOS from within Windows NT6, and manufacturers conformed. It only bricked machines significantly for a few years while the DOS way continued to be flawless for a while there. It's a slippery slope, this got much worse once they forced UEFI on consumers, and malware can now reside in the preboot environment itself, which can often also access the web if connected. Plus the motherboards have much more space for this kind of thing. With Windows Servers and general Macs well-established beforehand at using EFI to restrict booting to only the exact OS that it was shipped with. And everything on that Microsoft webpage introducing the advent of UEFI & GPT as a complete advantage in many ways, looking suspicious and turning out to be completely false without even waiting for the 20/20 hindsight there is now. The whole thing! The cloak has now been further removed from this "false sense of security" system but surely not everybody wants to say out loud how sparsely-clad the emperor has become as he struts as if to demand the full respect once deserved. So there hasn't been a physical way or available setting to prevent malicious access to sensitive PC firmware for quite some time, and who's most likely to blame for it? No Windows "update" has ever made sense to change anybody's BIOS or UEFI firmware without being absolutely stupid as shinola, not like there was any question before this either. This is also beyond most user recovery if you get malware in your UEFI. Zeroing a HDD or SSD won't help you now like it would with BIOS. You just can't fix shinola.
- ChoHag 2y ago
  [dead]
- salawat 2y ago
  >But, I don't think that was their thought process at all. Intent, being squishy and debatable matters far less than the outcome. I can say that I never intended X, but in the end, X still happened. That it happened unintentionally assuages exactly no injury from X having happened.
- salawat 2y ago
  >But, I don't think that was their thought process at all. Intent, being squishy and debatable matters far less than the outcome. I can say that I never intended X, but in the end, X still happened. That it happened unintentionally assuages exactly no injury from X having happened. Intent, therefore can only be considered as at best, an aggravating factor on top of the outcome.
kmeisthax 2y ago
The alternative dystopia is one where the NSA can grab your laptop, rip out the storage, write some code into the boot chain, put the storage back, leave, and you have no evidence to know who did that. Signed code fixes this by requiring someone actually put their name to the code. If it's not someone I recognize, I don't boot. And yes, the NSA could theoretically compromise a signing key with a $5 wrench. But then they blow their cover. Signatures create a paper trail that makes plausible deniability vaporize.
- userbinator 2y ago
  The game is already over for those who worry about the NSA spying on them. Using Windows in its default form means Microsoft already has a full backdoor into your machine, authorised by none other than MS itself.
- vuln 2y ago
  I don’t know what country you live in but it’s impossible to decrease your attack surface when targeted by a Nation State Actor. Even more impossible if you live in the country in which the Nation State Actor controls through a plethora of agencies and relationships with corporations.
  - computerfriend 2y ago
    It is usually possible to decrease your attack surface.
    - bigiain 2y ago
      Unplug all your computing devices, put them in a safe, embed the safe in concrete, drop it all in the sea.
      - bboygravity 2y ago
        Yeah that'll work for everybody who never ever touched any cloud service and who's friends and family never ever touched any cloud service (nobody in the real world).
sedatk 2y ago
> Who is Microsoft to decide what others do on their machines? That would be an amazing rant had it only ended with "Sent from my iPhone". Since the Blaster worm incident two decades ago, we're in a new era where security at scale becomes the forefront responsibility of the companies developing the product. That includes writing more secure code, having more verifications in place, adopting more secure technologies, but also, limiting user capabilities in order to avoid at scale security incidents. This isn't about Microsoft. Some of these "forced" limitations are: UAC (User Access Control)/SUDO, Bitlocker/Full disk encryption, App sandboxing/On-demand permissions, Signed firmware and boot mechanisms, signed release binaries, Jailbreak-protections, Limitations on raw packet operations, auto-installed updates, forced security updates, closed source code, built-in anti-malware. When you have a billion devices running around the world, you can't say "hey we'll let this arbitrary group of billion people do what they think is best for them", because you then end up with Blaster worm, and the whole Earth falls apart. Think about the more recent CrowdStrike incident. That kind of deployment has been performed by professionals, not even regular people, and yet, it's managed to bring down the entire world to its knees. People might have died because of CrowdStrike. CrowdStrike happened because one of the "user-empowering" features: ability to install kernel drivers on a machine. Now, people are begging Microsoft to adopt a more isolated, user-mode-only device driver system, so this kind of incident won't happen. Yes, some users who want to install their precious kernel driver could have problems, but at least the world would keep running. Microsoft is nowhere to be blamed about this. Secure defaults is the responsibility of every product that intends to be used at scale. If you'd like, you can disable Secure Boot, keep your data in plaintext on your hard drive, let all applications run as root, and you'd be the most powerful user in the universe. I'm all for personal freedom to disable the security features, but, at scale defaults must always prefer security over capability. That's not about Microsoft, or Google, or Apple. That's about at scale risk management.
- userbinator 2y ago
  Blaster was Microsoft's own incompetence. CrowdStrike was CrowdStrike's own incompetence. They are free to fix the problems of their own doing. But messing with software you do not own, on machines you do not own, crosses a line and should be considered an act of aggression. What if some Linux distro releases an update that deletes any installations of Windows it finds "because Windows is insecure" (according to them)? people are begging Microsoft to adopt a more isolated, user-mode-only device driver system, so this kind of incident won't happen Those people are, to put it bluntly, either authoritarian idiots or corporate shills. They want to give more control to Microsoft, but it's not like M$ is all that competent either, as what this article and past fiascos (like the Blaster you mentioned) have already shown, so they're going to just make things worse for everyone. CrowdStrike happened because one of the "user-empowering" features: ability to install kernel drivers on a machine. And crimes happen because people still have freedom. Doesn't mean we should start imprisoning (or enslaving to the machine) everyone from birth. "Freedom is not worth having if it does not include the freedom to make mistakes."
zahllos 2y ago
At the time of opening this page this was the top-ranked comment and that is a bit depressing. If you read Matthew Garrett's blog in full, you can learn quite a lot about what went into the process of building out secure boot for Linux. * The UEFI Consortium via their spec mandates nothing, but Microsoft (not mentioned here, but to stick Windows stickers on your boxes and get WHQL for your hardware) requires carrying their db keys: https://mjg59.dreamwidth.org/9844.html https://mjg59.dreamwidth.org/9844.html * You can take control of the process yourself and evict Microsoft's keys: https://mjg59.dreamwidth.org/16280.html https://mjg59.dreamwidth.org/16280.html the details are sort of in here, but let me summarize it for you: by default the platform key is provided by your manufacturer, which signs a key-signing-key, which itself signs updates to the DB (what you can boot) and DBX (what won't boot even with valid signatures). As the article says, x86 specifications explicitly require that this database be modifiable, so you can always install your own keys. I did this for a while, and on my laptop I evicted Microsoft's keys entirely. Ultimately you can bypass this if you can bypass the BIOS password simply by resetting the database or disabling secure boot and... well, https://bios-pw.org/ https://bios-pw.org/ . * The whole thing was built so that you can re-sign your own kernels and other bits if you want (you could just sign your distribution's db keys with your KEK, which will make OS upgrades smoother): https://mjg59.dreamwidth.org/12368.html https://mjg59.dreamwidth.org/12368.html * Here is an article on secure versus restricted boot: https://mjg59.dreamwidth.org/23817.html https://mjg59.dreamwidth.org/23817.html - I said above that the x86 specifications explicitly allow the key database to be modified (Microsoft's ARM devices were the inverse). Now some non-Garrett points: * To be affected by Windows Update, you need to run Windows. Tautological and true! * If you update your firmware via, say, LVFS (https://fwupd.org/ https://fwupd.org/) and your distribution via its standard tools you get updates to things like dbx all the time. All from your hardware vendor and friendly FOSS folk, no Microsoft involved. You might even be using SBAT right now. * Those Talos II boards people like? They also have secure boot. It is entirely optional and since Microsoft only implemented a "kinda" version of NT for PowerPC, they're definitely not involved. It is not UEFI, since there's no UEFI for POWER (there is for ARM and RISCV though). You also aren't getting anything from LVFS and barely anything from your distro, but, secure boot is there. You can turn it on. Personally, providing I can control the keys and decide what is and is not trusted and whether I use it, I am fine with it. Depending on what you want to achieve, secure boot is not always unreasonable, and neither are TPMs - small example, software exploits won't be able to successfully modify the boot chain if you have good key management (i.e. you sign elsewhere). They also have their limitations - as usual, physical access is hard to defend against and remote attestation is a hard problem all around.
fsflover 2y ago
I agree with everything except this: > Things like TPM and "secure" boot were never envisioned for the interests of the user. I am successfully using TPM with coreboot and Heads, with my own keys, to protect against boot attacks on my Librem 14 with Qubes OS.
mjg59 2y ago
The full quote is: "Those who would give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety" Is the ability to run an insecure bootloader on a system that has an installed OS with a security policy built around it not running insecure bootloaders an essential liberty? Let's say it is, for the sake of argument. Have you given up that freedom? Given that you can disable secure boot, or boot a live image and remove the SBAT entry, or boot an updated image and recover your existing install, I think it's hard to say that you've actually given it up. Is that security temporary? A well-maintained secure boot chain provides you long-term security against a variety of threats, so I don't think it's clearly temporary. It's fine to disagree, but please don't do so by pretending that a misquote is meaningful.

palisade 2y ago

I guess in their defense the same attack can be used against any other OS so they're unintentionally protecting Linux as well, since they stated this was supposed to be a Windows-only system change. You can disable secure boot if you don't want to be secure. And, there is a way to disable the SBAT policy and keep secure boot if you want that, which is also insecure. Disable Secure Boot, login, sudo mokutil --set-sbat-policy delete, reboot again, re-enable secure boot. But, then you're susceptible to the attack. I think understandably, everyone is concerned because it felt like an affront by MS against Linux. But, I don't think that was their thought process at all.

thwarted 2y ago
> I think understandably, everyone is concerned because it felt like an affront by MS against Linux. But, I don't think that was their thought process at all. Given Microsoft's history, it's hard to really be sure. It's been a quarter century since The Halloween Documents and Microsoft definitely gives the air of contributing to the open source ecosystem today, but giants like having a big moat to defend, and old habits die hard. And Microsoft definitely has a reputation, even if, technically, undeserved.
- palisade 2y ago
  There was nothing to be gained in this except ill will. Hanlon's Razor suggests they were in a hurry to fix a security issue and didn't dot their i's on checking for dual boot systems.
  - literalAardvark 2y ago
    It's a trolley problem, and it's not in Microsoft's locus of control to keep dual boot systems dual booting. So they don't try. They have never, ever supported anything other than the Microsoft bootloader[s], and if you work around that for instance it's pretty trivial to blow up your data by hibernating Windows and booting into a different partition. Resuming hibernation loads the old MFT onto the modified partition and you pretty much lose everything.
    - fuzzfactor 2y ago
      >hibernating Windows and booting into a different partition. Definitely to be avoided, along with a few other considerations. But experienced multibooters can usually reboot so quick that they have not had any need for hibernation since forever. It's almost like a valid excuse to not fully reboot a sluggish machine, more so than an energy-saving success. But I don't blame them.
  - account42 2y ago
    If you apply Hanlon's Razor to known malicious actors then the only one being stupid is you. In fact, it's a really bad heuristic for any corporation.
- fuzzfactor 2y ago
  >it's hard to really be sure. Not that hard the more history there is. Keep in mind that the default since the beginning of Linux is for someone who wants their PC to be completely Linux, never had a need for anything originating from Microsoft whatsoever. Something in firmware would really be the worst and it was immediately obvious when UEFI & GPT were foisted, with Microsoft SecureBoot to boot, that something was rotten somewhere. A bigger threat than Linux was actually Windows 7, but with this exact hindsight now it can be seen how the knife was much further twisted for Linux well beyond the effective lifetime of W7. This was not just collateral damage, and it keeps on giving as if booby-trapped or time-bombed. Also remember that until Windows Vista, motherboards and business machines from all major manufacturers were always common where there was no way to alter the BIOS itself in any way without physical access. Like a jumper on the board internal to the PC. Sometimes special key combinations on laptops accepted only from its built-in keyboard. With BIOS settings only accessible to non-local users occasionally on specialized enterprise models according to options if present. When you wanted to upgrade your BIOS, or "re-flash" it due to something like power line corruption, you always booted to the floppy containing the desired firmware after enabling the delicate flashing operation manually. By the time Vista arrived it was often a bootable CDROM, or a USB stick formatted FAT32 with DOS to substitute for a floppy. Whichever way you did it you wrote the same binary file into the BIOS chip, then with further access completely disabled after that, never need to worry about malicious firmware whatsoever as long as you used a clean binary. The only possible way for a rootkit to infect your machine was to reside on your HDD. Usually in some of the spaces outside your filesystem that were so commonly unused it could lurk there and persist in spite of re-formatting. But no rootkit or preboot contamination could withstand a complete HDD zeroing, or replacement HDD if needed under emergency conditions. Well one day Microsoft must not have wanted people to ever boot DOS again, so they developed a need to access every BIOS from within Windows NT6, and manufacturers conformed. It only bricked machines significantly for a few years while the DOS way continued to be flawless for a while there. It's a slippery slope, this got much worse once they forced UEFI on consumers, and malware can now reside in the preboot environment itself, which can often also access the web if connected. Plus the motherboards have much more space for this kind of thing. With Windows Servers and general Macs well-established beforehand at using EFI to restrict booting to only the exact OS that it was shipped with. And everything on that Microsoft webpage introducing the advent of UEFI & GPT as a complete advantage in many ways, looking suspicious and turning out to be completely false without even waiting for the 20/20 hindsight there is now. The whole thing! The cloak has now been further removed from this "false sense of security" system but surely not everybody wants to say out loud how sparsely-clad the emperor has become as he struts as if to demand the full respect once deserved. So there hasn't been a physical way or available setting to prevent malicious access to sensitive PC firmware for quite some time, and who's most likely to blame for it? No Windows "update" has ever made sense to change anybody's BIOS or UEFI firmware without being absolutely stupid as shinola, not like there was any question before this either. This is also beyond most user recovery if you get malware in your UEFI. Zeroing a HDD or SSD won't help you now like it would with BIOS. You just can't fix shinola.
ChoHag 2y ago
[dead]
salawat 2y ago
>But, I don't think that was their thought process at all. Intent, being squishy and debatable matters far less than the outcome. I can say that I never intended X, but in the end, X still happened. That it happened unintentionally assuages exactly no injury from X having happened.
salawat 2y ago
>But, I don't think that was their thought process at all. Intent, being squishy and debatable matters far less than the outcome. I can say that I never intended X, but in the end, X still happened. That it happened unintentionally assuages exactly no injury from X having happened. Intent, therefore can only be considered as at best, an aggravating factor on top of the outcome.

kmeisthax 2y ago

The alternative dystopia is one where the NSA can grab your laptop, rip out the storage, write some code into the boot chain, put the storage back, leave, and you have no evidence to know who did that. Signed code fixes this by requiring someone actually put their name to the code. If it's not someone I recognize, I don't boot. And yes, the NSA could theoretically compromise a signing key with a $5 wrench. But then they blow their cover. Signatures create a paper trail that makes plausible deniability vaporize.

userbinator 2y ago
The game is already over for those who worry about the NSA spying on them. Using Windows in its default form means Microsoft already has a full backdoor into your machine, authorised by none other than MS itself.
vuln 2y ago
I don’t know what country you live in but it’s impossible to decrease your attack surface when targeted by a Nation State Actor. Even more impossible if you live in the country in which the Nation State Actor controls through a plethora of agencies and relationships with corporations.
- computerfriend 2y ago
  It is usually possible to decrease your attack surface.
  - bigiain 2y ago
    Unplug all your computing devices, put them in a safe, embed the safe in concrete, drop it all in the sea.
    - bboygravity 2y ago
      Yeah that'll work for everybody who never ever touched any cloud service and who's friends and family never ever touched any cloud service (nobody in the real world).

sedatk 2y ago

> Who is Microsoft to decide what others do on their machines? That would be an amazing rant had it only ended with "Sent from my iPhone". Since the Blaster worm incident two decades ago, we're in a new era where security at scale becomes the forefront responsibility of the companies developing the product. That includes writing more secure code, having more verifications in place, adopting more secure technologies, but also, limiting user capabilities in order to avoid at scale security incidents. This isn't about Microsoft. Some of these "forced" limitations are: UAC (User Access Control)/SUDO, Bitlocker/Full disk encryption, App sandboxing/On-demand permissions, Signed firmware and boot mechanisms, signed release binaries, Jailbreak-protections, Limitations on raw packet operations, auto-installed updates, forced security updates, closed source code, built-in anti-malware. When you have a billion devices running around the world, you can't say "hey we'll let this arbitrary group of billion people do what they think is best for them", because you then end up with Blaster worm, and the whole Earth falls apart. Think about the more recent CrowdStrike incident. That kind of deployment has been performed by professionals, not even regular people, and yet, it's managed to bring down the entire world to its knees. People might have died because of CrowdStrike. CrowdStrike happened because one of the "user-empowering" features: ability to install kernel drivers on a machine. Now, people are begging Microsoft to adopt a more isolated, user-mode-only device driver system, so this kind of incident won't happen. Yes, some users who want to install their precious kernel driver could have problems, but at least the world would keep running. Microsoft is nowhere to be blamed about this. Secure defaults is the responsibility of every product that intends to be used at scale. If you'd like, you can disable Secure Boot, keep your data in plaintext on your hard drive, let all applications run as root, and you'd be the most powerful user in the universe. I'm all for personal freedom to disable the security features, but, at scale defaults must always prefer security over capability. That's not about Microsoft, or Google, or Apple. That's about at scale risk management.

userbinator 2y ago
Blaster was Microsoft's own incompetence. CrowdStrike was CrowdStrike's own incompetence. They are free to fix the problems of their own doing. But messing with software you do not own, on machines you do not own, crosses a line and should be considered an act of aggression. What if some Linux distro releases an update that deletes any installations of Windows it finds "because Windows is insecure" (according to them)? people are begging Microsoft to adopt a more isolated, user-mode-only device driver system, so this kind of incident won't happen Those people are, to put it bluntly, either authoritarian idiots or corporate shills. They want to give more control to Microsoft, but it's not like M$ is all that competent either, as what this article and past fiascos (like the Blaster you mentioned) have already shown, so they're going to just make things worse for everyone. CrowdStrike happened because one of the "user-empowering" features: ability to install kernel drivers on a machine. And crimes happen because people still have freedom. Doesn't mean we should start imprisoning (or enslaving to the machine) everyone from birth. "Freedom is not worth having if it does not include the freedom to make mistakes."

zahllos 2y ago

At the time of opening this page this was the top-ranked comment and that is a bit depressing. If you read Matthew Garrett's blog in full, you can learn quite a lot about what went into the process of building out secure boot for Linux. * The UEFI Consortium via their spec mandates nothing, but Microsoft (not mentioned here, but to stick Windows stickers on your boxes and get WHQL for your hardware) requires carrying their db keys: https://mjg59.dreamwidth.org/9844.html https://mjg59.dreamwidth.org/9844.html * You can take control of the process yourself and evict Microsoft's keys: https://mjg59.dreamwidth.org/16280.html https://mjg59.dreamwidth.org/16280.html the details are sort of in here, but let me summarize it for you: by default the platform key is provided by your manufacturer, which signs a key-signing-key, which itself signs updates to the DB (what you can boot) and DBX (what won't boot even with valid signatures). As the article says, x86 specifications explicitly require that this database be modifiable, so you can always install your own keys. I did this for a while, and on my laptop I evicted Microsoft's keys entirely. Ultimately you can bypass this if you can bypass the BIOS password simply by resetting the database or disabling secure boot and... well, https://bios-pw.org/ https://bios-pw.org/ . * The whole thing was built so that you can re-sign your own kernels and other bits if you want (you could just sign your distribution's db keys with your KEK, which will make OS upgrades smoother): https://mjg59.dreamwidth.org/12368.html https://mjg59.dreamwidth.org/12368.html * Here is an article on secure versus restricted boot: https://mjg59.dreamwidth.org/23817.html https://mjg59.dreamwidth.org/23817.html - I said above that the x86 specifications explicitly allow the key database to be modified (Microsoft's ARM devices were the inverse). Now some non-Garrett points: * To be affected by Windows Update, you need to run Windows. Tautological and true! * If you update your firmware via, say, LVFS (https://fwupd.org/ https://fwupd.org/) and your distribution via its standard tools you get updates to things like dbx all the time. All from your hardware vendor and friendly FOSS folk, no Microsoft involved. You might even be using SBAT right now. * Those Talos II boards people like? They also have secure boot. It is entirely optional and since Microsoft only implemented a "kinda" version of NT for PowerPC, they're definitely not involved. It is not UEFI, since there's no UEFI for POWER (there is for ARM and RISCV though). You also aren't getting anything from LVFS and barely anything from your distro, but, secure boot is there. You can turn it on. Personally, providing I can control the keys and decide what is and is not trusted and whether I use it, I am fine with it. Depending on what you want to achieve, secure boot is not always unreasonable, and neither are TPMs - small example, software exploits won't be able to successfully modify the boot chain if you have good key management (i.e. you sign elsewhere). They also have their limitations - as usual, physical access is hard to defend against and remote attestation is a hard problem all around.

fsflover 2y ago

I agree with everything except this: > Things like TPM and "secure" boot were never envisioned for the interests of the user. I am successfully using TPM with coreboot and Heads, with my own keys, to protect against boot attacks on my Librem 14 with Qubes OS.

mjg59 2y ago

The full quote is: "Those who would give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety" Is the ability to run an insecure bootloader on a system that has an installed OS with a security policy built around it not running insecure bootloaders an essential liberty? Let's say it is, for the sake of argument. Have you given up that freedom? Given that you can disable secure boot, or boot a live image and remove the SBAT entry, or boot an updated image and recover your existing install, I think it's hard to say that you've actually given it up. Is that security temporary? A well-maintained secure boot chain provides you long-term security against a variety of threats, so I don't think it's clearly temporary. It's fine to disagree, but please don't do so by pretending that a misquote is meaningful.