* Marcel: > On 11/5/19 4:11 AM, Florian Weimer wrote: >> The FSF has given out an award in support of Secure Boot-related work, >> so its approach to the matter is rather ambiguous. > > Looking through fsf.org I couldn't find any award in support of "Secure > Boot" related work, would you mind pointing me to it?
<https://www.fsf.org/news/free-software-award-winners-announced> It's difficult to argue that the FSF wasn't supportive when it handed out an award for Secure Boot work. It also suggests that the issue has a solution and is therefore manageable. > The FSF seems to have a very clear position on "Secure Boot" vs. > "Restricted Boot", and has been running a campaign opposing "Restricted > Boot" for the best part of this decade: > > https://www.fsf.org/campaigns/campaigns-summaries#secureboot Matthew's work shifted the onus of supporting GNU-compatible Secure Boot from Microsoft and hardware vendors to GNU/Linux distributions and was a strategic mistake. >> I knew this would happen and wrote extensively against Secure Boot. >> That became a futile exercise when the FSF started supporting it, too. > > AFAIK, the only thing the FSF said is that when implemented correctly, > Secure Boot" is designed to protect the user against malware. They urged > manufacturers to respect user freedoms when implementing "Secure Boot" > by doing it correctly. > > How you interpret this as support for "Secure Boot"? Nobody knows what Secure Boot was originally designed to do—and what its current security objectives are. I suspect it was initially intended to save $1.50 for a read-only USB stick, by storing recovery media on the main storage device. But even that does not work anymore because Microsoft opened up the Secure Boot trust root to basically anyone (who can start their own little company and shell out a few hundred dollars). As a result, it no langer means that if it boots, it's authorized by Microsoft. The indirect cryptographic chain GNU/Linux distributions ensures that Microsoft never sees actual binaries running in ring 0, so they can't do any meaningful verification on submitted binaries, either. (The Secure Boot signing services works by submitting binaries to them, the code signing certificate you need to purchase does not give you the immediate ability to run code with Secure Boot active.) It's also unclear what how this alleged protection against malware would work when users can easily install their own operating systems. It's not possible to have it both ways: Either you can replace the guts of the operating system and you live with the malware risk (because malware can do the same), or you give up that capability. User prompts do not really work because they would have to say something along the line “proceed only if you want to install malware or GNU/Linux”, which is not politically feasible. (Also keep in mind that the Secure Boot work did not deliver anything close to a signed userspace, and due the lack of ELF signing support in glibc and the scripted nature of the boot process on mainstream GNU/Linux distributions, it is unclear how we could deliver that technically. There is dm-verity and IMA, but that is so draconian that you can't pretend that the result is still free software with user control, so it's not used by GNU distributions.) The main problem I have with the FSF approach to Secure Boot is that there was a time when we could have killed it, by not supporting it, and force Microsoft to come up with a different approach to avoid the obvious anti-trust issues. The non-copyleft (Tianocore, shim) to copyleft (GRUB, Linux) signing chain might have been the weakest point, but through its actions, the FSF has given its approval. But we failed to convey that this is a problem that Microsoft has to solve, and now we have to deal with the fallout.