Part of the concern that you want the kernel to handle the secure boot at a low level is because Microsoft keys could be used to hack the system, and if that happens, they fear that Microsoft will disable the key and therefore Linux PCs. let them run with that key (and nobody wants that).
It all started with a pull request from David Howells that allowed Microsoft-signed binary keys to be dynamically loaded into the kernel running in secure boot mode. The one with the blanket thought it was bullshit and that it would be better to improve the X.509 parser. Matthew Garrett replies that there is only one signing authority and that they only sign PE binaries (portable executables). And here Linus lets go of his sharp tongue and says:
Guys, this is not a cock sucking contest. If you want to parse PE binaries, go ahead. If Red Hat wants to ask you deep throat to Microsoft, it's * your * problem. It has nothing to do with the kernel that I maintain. It is trivial for you to have a signing machine that parses the PE binary, verifies the signatures, and signs the resulting keys with its own key. They already wrote the code, by God, it's in that damn order. Why should I care? Why should the kernel give a shit like "we only sign PE binaries"? We support X.509, which is the standard for signing. Do it on the user's side on a reliable machine. There is no excuse to do it in the kernel.
Matthew replies:
Sellers want to bring keys signed by a trusted third party. Now the only one that measures up is Microsoft, because apparently the only thing vendors love more than crappy firmware is following Microsoft's specifications. The equivalent is not just Red Hat (or whatever) re-signing those keys programmatically, it is re-signing those keys with a trusted key by the upstream kernel. Would you be willing to carry a trusted key by default if a member of the trusted society hosts a re-signing service? Or do we assume that anyone who wants to launch external modules is an idiot and deserves to be a miserable?
Linus replies that he doubts anyone cares. That it is already stupid to sign kernel modules with a Microsoft key. Also, Red Hat WILL sign the NVIDIA and AMD binary modules. Peter Jones says no, that Red Hat will not sign any module built by another. Garret adds that RHEL will end up relying on keys from NVIDIA and AMD and that it is very likely that they will be based on Microsoft's signing service.
And this is where I pause and summarize partial and brutal for those who do not want to go into technical details:
All the development around the secure boot has gone crazy, but because the hardware vendors (the biggest ones at least) still want to deepthroat Microsoft.
So Linus decided to make the following suggestions, so they stop fucking ……:
Cut it off with scaremongering.
This is what I would suggest, and it's based on TRUE SAFETY and in PUT THE USER FIRST instead of his "let's indulge Microsoft by doing crap" approach.
So instead of pleasing Microsoft, let's try to see how we can really add security:
- a distro must sign its own modules AND NOTHING MORE default. And it shouldn't allow any other module at all to load by default either, because why the fuck should it? And what the hell does a microsoft firm have to do with anything else?
- before loading any other third party modules, make sure ask the user for permission. On the console. Without using keys. Nothing of that. The keys will be compromised. Try to limit the damage, but more importantly, let the user have control.
- Animate things like random keys per host - with stupid UEFI checks disabled if necessary. They are almost definitely going to be more secure so depending on some crazy root of trust based on a large company, with signing authorities who trust anyone who has a credit card. Try to teach those things to people. Encourage people to make their own (random) keys, and add them to their UEFI settings (or not: everything about UEFI is more about control than security), and strive to do things like one-time signing with the key private discarded. In other words, try animating that kind of security like "we make sure to ask the user explicitly with big warnings and create their own key for that particular module." Real security, not security "we control the user."
Sure, users are going to screw it up too. They will want to load NVIDIA binary modules and all that crap. But let it be SU decision, and under SU control, instead of telling the world how this should be blessed by Microsoft.
Because this should not be about MS blessings, but about the user blessing the kernel modules.
Honestly, you are what the crazy anti-key people fear. You sell the "control, not security" shitware. All "MS owns your machine" is just the wrong way to use passwords.
From then on the thread calmed down ... and it is not worth following.
Friends of DesdeLinux. Today I celebrate my first anniversary as an editor on a Linux blog, despite not having debuted as such here but on Frannoe's blog, which at that time was called Ubuntu Cosillas and which today is LMDE Cosillas. And it was there on March 2 when I wrote the first chapter of this firmware saga that I later continued here. I would like to thank everyone who reads me and has read me, especially Frannoe and the entire staff of Desdelinux for making a place for me. If it weren't for having taken that Advanced Functional Programming course, and a colleague who suggested I use Linux to work with ghc, I'm sure I would still give a damn about everything about Linux.
I will end with this sentence: "If you don't shout your ignorance, no one will come out to correct you and therefore you will be right being wrong"
Relevant posts from the kernel mails list:
https://lkml.org/lkml/2013/2/21/196
https://lkml.org/lkml/2013/2/21/228
https://lkml.org/lkml/2013/2/21/275
https://lkml.org/lkml/2013/2/25/487
The point is that if the manufacturers of Notebooks and others are definitely behind Wintel's UEFI (we must not forget that UEFI is Intel's idea), and, in the worst case, they all decide not to include the option to deactivate it, Linux distros are going to look black if they don't have the signature, and I think that's something the people at RedHat noticed. I want to see what they are going to do in a couple of years when Linux cannot be installed on any new computer because it does not have the signature.
In the worst case scenario, the distributions will sign the kernel with the keys signed by Microsoft. In fact, it is what several are already doing.
What Torvalds says is that this needs to be resolved on each distro, because the kernel is not going to do it. And this is the most sensible thing, it has no return.
Linus is my favorite real world personality. It's like he's been taken out of a Quentin Tarantino movie and put to lead a community. You are quite right in what you say.
What about LinuxMint machines, do they come with UEFI / Secure boot? I insist that when I need one, I will buy one of those.
My lap is one year old, by the time I need another I think that the UEFI / Secure boot thing will already be well resolved, or properly implemented, or duly eliminated, ha.
I really doubt it, it is impossible because although the mintbox is designed to be used with linuxmint, fedora, ubuntu and debian, as it says in its specifications so it would be silly to put secure boot to something that will surely have dualboot, or it is designed for free or moderately free software in the case of Ubuntu XD.
Well, it is an issue that has always generated controversy since it came out. It is interesting to see how he progresses and as Alf, I think that in the medium term things will improve. There are manufacturers that will always allow the deactivation of secure boot and others that already have Linux pre-installed such as ThinkPenguin or System76, I hope that over time more and more will be born as to have a choice ... I will always prefer to buy something that is 100% compatible with linux guaranteed to play them with any other machine.
I still do not understand very well these shenanigans from UEFI and others .. Shit .. by the way diazepan: Congratulations! For us it is a pleasure to have you here.
In the end we will end up buying pure server equipment, that is if they do not transport this shit there.
It should be a large person that most of the large and critical servers run on Linux and many of them (depends on their handling) are extremely secure, as if to presume that this security pull is going to kill all that malicious software.
As always, I VERY agree with what Linus puts forward, as he rightly says, this UEFI topic is more about "control" than "security." For my part, I do not trust at all in this supposed security mechanism and if a computer with UEFI falls into my hands, the first thing I will do is deactivate it and continue as before. On the other hand, I do not believe that equipment manufacturers will prevent the deactivation of the UEFI as they would risk losing market share; that there will be someone who takes risks or at least does it in some specific models, I do not doubt it, but I think that there will always be solutions, remember that this is nothing more than a BIOS on steroids and the possibility of upgrading it with "open" versions always will be latent.
As far as I know the eufi only works for win8 if you want a dual boot system since you can deactivate it with bios, in itself so it does not matter if you have only linux and deactivate that option from the bios and there is no need to be so much fuss about the issue .
This issue is a bit big for me, but by personal deduction what I see is that the microsoft puppets began to see them black when they saw how mature Linux is…. And how they monopolize the big manufacturers since the beginning of time, for me it is clear why so much trouble with that damn secure boot ...... even some large or medium-sized company I suppose that I would take other options without counting on more and there I will be buying my next machine ... that's for sure 😉