Secure boot theoretically possible with custom keys
brozkeff opened this issue · comments
I propose to modify the argument that Secure Boot cannot be used due to Microsoft lack of will to sign GPL3 code. While many (crappy) PCs do not have proper UEFI and have only the default (=Microsoft's) bunch of certified keys for Secure Boot, some better UEFIs (such as on my HP EliteDesk SFF PC) offer the user to actually push to the UEFI one's own signing keys, sign the bootloader etc with them, and have Secure Boot with ANY self-signed code. So while this option makes sense for only a very small minority of users, it is a legit option on the platforms that have a reasonable UEFI capable of replacing Microsoft's keys with alternative keys.
The issue here is that we (or at least the vast majority of people who use UEFI:NTFS) are attempting to boot Windows bootloaders, and it appears that Microsoft designed its bootloaders to also validate that they have been signed only with the Microsoft signature (which is very easy to validate during boot), and not a user-generated one.
See https://superuser.com/questions/1449698/secure-boot-custom-signed-bootloader for instance and especially this reply:
You might be able to get a Linux OS to accept your own certificate but you will be unable to get Windows 10 to accept it. There is no way to enable Secure Boot and boot to Windows 10 using your own certificate.
Again, while I am well aware that, theoretically, one could add their own keys to the bootloaders and use custom Secure Boot, in practice, this would be both very inconvenient for most users, who would have to go through what they see as a very obtuse and fairly technical process that they don't quite understand (hence fraught with user mistakes) and that wouldn't work when trying to install Windows anyway.
Ergo, I stand by my argument that Secure Boot cannot be used due to Microsoft lack of will to sign GPL3 code. because, unless you can demonstrate otherwise and come up with a simple (and universal) process that even a non technical person can follow when they are trying to install Windows on a Secure Boot protected computer, what I say about Microsoft hampering the ability of people to use Secure Boot, even when most UEFI machines are supposed to make it theoretically possible to do so, is the de-facto reality.
Hello there,
I'd like to point out that Microsoft is moving closer to Open Source (e.g. they recently published exFAT specs).
You might have more luck trying to tackle this
As a developer, I'd like nothing better than be able to sign UEFI:NTFS for Secure Boot.
However, this is not possible because Microsoft have arbitrarily decided that they would not sign anything that is GPLv3 under the false pretence that it would force them to relinquish their private signing keys.
e.g. they recently published exFAT specs
Yeah, about this: they did that... but only for the Linux kernel consumption.
Wanna add an exFAT driver to the EDK2 so that we can stop with the bullshit limitations UEFI firmwares have with FAT32? No dice.
Wanna add exFAT support to your Open Source app? No dice.
Once again, what we are seeing is that Microsoft are only "moving closer to Open Source" insofar as it directly benefits them.
If they were actually moving closer to Open Source, they'd have made exFAT available for all Open Source applications. But if you read the terms & conditions under which they are making usage of their newly published specs available, you'll see that this is far from being the case...
Call me cynical, but I'll be convinced that Microsoft are actually "moving closer to Open Source" the day they drop point 4 from their Secure Boot signing policy requirements, because this IS a blatant move against Open Source that, furthermore, can only be qualified as sheer abuse of power. Until that day people can try to point to Microsoft having become more Open Source friendly all they want, there'll still remain enough inconvenient facts to demonstrate that there remains a huge discrepancy between the image they are trying to present and what's actually happening at the ground level.
One also has to wonder, since NTFS has really become the de-facto file system to use for data exchange between heterogeneous systems where FAT won't do, why Microsoft are suddenly choosing to push for exFAT, instead of doing the one thing that would have been better suited to help Linux and other Open Source implementations, which is to make NTFS file system specs available for said implementations.
TL;DR: Even with their recent well publicized actions, colour me unconvinced that Microsoft are effectively "moving closer to Open Source".
Call me cynical, [...]
No, please. That's the kind of answer I was expecting; I just didn't know "why" your answer was going to be this (i.e. what is the facade they are selling vs the reality).
I am not convinced with Microsoft's actions "for a very long time". However, it is hard to know the details of these issues, since I explicitly refuse even trying to do something productive on Windows (for exactly these reasons i.e. not hit stupid brick walls like that)
TIL the rufus guy is a crazy stallman-lite....
Call me cynical, but I'll be convinced that Microsoft are actually "moving closer to Open Source" the day they drop point 4 from their Secure Boot signing policy requirements, because this IS a blatant move against Open Source that, furthermore, can only be qualified as sheer abuse of power.
have you actually read the gplv3? M$'s argument makes perfect sense. here's an excerpt from section 6
“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.
so in some other schizophrenic rant against secure boot you posted "BUT THEY SIGN LINUX SHIMS!!!"
again, are you on your meds? are you doing okay? have you even read what license the SHIM is released under (spoilers: it's not GPLv3). guess why the SHIM exists in the first place? BECAUSE GRUB IS GPL. It had to get written to sidestep the secure boot signing requirement. so grub is not signed, now the shim is, the shim trusts a compiled-in certificate for any loaded binaries, problem solved. here's a link for you to actually read the shim, since you probably never have: https://github.com/rhboot/shim/
and there's nothing stopping you from taking a SHIM approach where you write a loader that validates the signatures of subsequent binaries against a hardcoded cert, getting that signed, and having the problem solved.
your M$ bashing is out of fashion and is just an excuse for laziness / incompetence. anyone can see that the GPL's requirement for disclosure of keys is retarded. cheers.
have you actually read the gplv3?
I did.
M$'s argument makes perfect sense.
Not even close. And I will be elaborating that at length below.
But I'm glad they managed to fool you, because it gives me a chance to explain explain how pernicious their "justification" that they are entitled to shut down the GPLv3 really is when trying to look at it logically...
here's an excerpt from section 6
Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work
And yet, without having to relinquish their keys, Microsoft does provide means for users to install and execute modified version of covered (i.e. GPLv3) work, since they have a procedure in place allegedly allowing anybody who wants to to sign their code for Secure Boot.
You'll notice that there's no mention of not having to pay or having to go through a potentially cumbersome procedure to get your GPLv3 code running, and of course, I don't think anybody (and by anybody, I really mean: the FSF) will argue (but feel free to do so if you want) that Microsoft should let GPLv3 code through that is deliberately designed to weaken the Secure Boot process. After all, Microsoft already have control of the signing keys, so if they believe that someone is going to attempt to use GPLv3 as a trojan horse to relinquish their keys or something else, they don't actually have to take pre-emptive measures, because, after all, they could just state, and this is the part that a lot of people, including yourself appear to have a lot of difficulty to grasp: "We will place no condition on the license being used, but we do reserve the right to refuse service on a case by case basis".
There really was no reason to pre-emtively single out GPLv3 when they just had to add a line: "Microsoft reserves the right to refuse to sign binaries for Secure Boot at their own discretion", which I'm pretty sure is already implied.
But instead, they floated the idea that GPLv3 would "magically" demand that Microsoft release their private signing keys, and that, the minute they sign a SINGLE GPLv3 binary for Secure Boot, there is no way, no appeal, no lengthy layers tractations that would save them from having to make their private Secure Boot signing key available to the world.
Ever seen a large corporation shake that much from trying to engage in a service where they could easily put legal terms of "when using this service, our corporate rights trump your user rights"? Yeah, me neither.
So, UNTIL PROVEN OTHERWISE, I can't see how one would buy the argument that has been put forward that the provision of a relatively open service for signing UEFI binaries for Secure Boot, which Microsoft does have in place, would run afoul of section 6 of the GPLv3. And that is not even taking into consideration the precedent of the SHIM in order to disprove the allegations that GPLv3 may force the relinquishing of private keys.
Especially, I have never heard a single FSF spokesperson even hint that "Oh yeah, Microsoft are right to be cautious there, because, theoretically, this section of the GPLv3 could completely defeat Secure Boot, and also, there's certainly no way someone arguing in court that relinquishing the private keys or be forced to remove steps designed to keep a system secure, could ever win their argument that they should not be legally forced to take these steps, even if one could somehow interpret not-so-specific wording to imply as such".
As far as I am concerned (outside of the specific GPLv3 restrictions they added to their Secure Boot signing T&Cs), by providing an open service to sign binaries for Secure Boot, Microsoft does fit the requirements of providing "methods, procedures, authorization keys, or other information required to install (to) execute modified versions of a covered work". There's a procedure that anyone can follow to get UEFI bootloaders signed for Secure Boot, and get their modified versions of software work on a Secure Boot enabled machine, even without having to remove the Microsoft public key and installing their own (which, as long as no manufacturer of a computer prevents it -- and I can talk about the original Windows on ARM Secure Boot fiasco/backlash if you want, which, I would assert, might have been the reason why Microsoft tried to weed out the GPLv3 for Secure Boot, as this is what they might have seen as a bigger challenge to their plan) I would also consider as more than good enough to satisfy the allegedly Secure Boot incompatible terms of GPLv3 section 6.
But again, I am not a layer, and unless we do see actual lawyers pronounce themselves on whether section 6 (or any other GPLv3 section for that matter) runs afoul of the current process that allows developers to sign their UEFI binaries for Secure Boot, I don't see how anyone can be 100% positive that it does, and that Microsoft are justified in their stance, which is my point.
Now, if you can point me to a quote from a legal person or the FSF, stating that, yes, as it stands, the Microsoft Secure Boot signing process is not enough to meet the requirements of the GPLv3, I will be more than happy to accept that Microsoft might be more atuned to interpreting legal licensing implications than I am, and that they had little choice but to place a wholesale ban on GPLv3 for Secure Boot... But I have now been waiting years for someone to do that, and so far, nobody has managed to point to anything substantial.
Therefore, in the absence of that, and again, I have not even seen an inkling of indication that anyone outside of Microsoft, including the FSF, agrees with Microsoft's scaremongering "interpretation" of what the GPLv3 might mean for them, I have to rely on the next best thing, which is my own logical interpretation of what the GPLv3 licensing terms actually mean, whether the Microsoft Secure Boot process runs afoul of them, and whether Microsoft are justified in their pre-emptive stance. And so far, everything I have seen and read point to at best, a massive unjustified overreaction from Microsoft, and at worst, something a lot more devious.
IMO, as long as Microsoft does allow the public at large to sign binaries for Secure Boot (and they do, regardless of how many hoops one has to jump through or how expensive the whole process is), they are meeting the terms of section 6, and therefore have no reason to issue a blanket ban of the GPLv3.
so in some other schizophrenic rant against secure boot you posted "BUT THEY SIGN LINUX SHIMS!!!"
again, are you on your meds? are you doing okay? have you even read what license the SHIM is released under (spoilers: it's not GPLv3).
Wow. If you really think I somehow assumed that shims were GPLv3, I'm not sure if I want to continue this argument, because you've completely missed the point, and you have just constructed a straw man.
As I've explained quite a few times before, the point about the shims is that, if Microsoft were truly believing that the GPLv3
is incompatible with Secure Boot, there's no way they would be happy to sign a shim, which in turn allows GPLv3 binaries to run.
It's called transitive property. And that's because, since the shim must implement a mechanism similar to Secure Boot, to validate that no random user-modified binary can run (because otherwise the whole Secure Boot process would be completely defeated by running whatever GPLv3 licensed malware you want through the shim), IF the Secure Boot signing process is allegedly legally incompatible with GPLv3, THEN the downstream shim signing process MUST be equally incompatible with GPLv3, as one has to jump through pretty similar hoops as Secure Boot to get their own modified UEFI code running. Yet, the only major difference is that one happily accepts GPLv3 (and I have yet to see anyone complain that going through a shim for GPLv3 runs afoul of section 6), whereas the other does not, even though they are designed to provide the same services in terms of security, and use the same mechanisms (PKI and/or hash validation) to enforce that security.
It just makes no sense: What in the world makes the shim special, that doesn't apply to Secure Boot itself, and that lets it accept
GPLv3 work? Can you, or anyone for that matter, explain the legal technicalities here? Because if it's a matter of enforcing the
relinquishing of private keys, then, if they might allegedly do so with Microsoft if they allowed GPLv3, then anyone should legally be entitled to ask the main shim maintainers (Red Hat and co) to relinquish their private key so that they can run their own GRUB derivatives.
Yet, none of that "the shim signature requirements are clashing with the GPLv3 requirements" business has happened...
Considering this, I don't see how one can sustain the opinion that "the Secure Boot signature requirements can only run afoul of with the GPLv3 requirements", because it doesn't make one shred of logical sense.
And this has NOTHING to do with the license the shim is released under, only the transitive properties of a secure system that has to end up at a root trust level.
guess why the SHIM exists in the first place? BECAUSE GRUB IS GPL.
No, the shim exists because Microsoft stated that they would refuse to sign anything GPLv3.
Oh, btw, Microsoft will happily sign GPLv2, so you can't even simply state "BECAUSE GRUB IS GPL", it's only GPLv3 that is prevented, which means that it's only one of the new conditions introduced with the GPLv3 that appears to matter to Microsoft.
The shim is not a consequence of GRUB being GPL, which it was long before Secure Boot was introduced. The shim is a consequence of Microsoft introducing an explicit anti-GPLv3 condition in their own service requirements for Secure Boot.
It had to get written to sidestep the secure boot signing requirement.
Requirements, that were arbitrarily added by Microsoft.
so grub is not signed
GRUB is signed to work with the shim, if you want that to boot on Secure Boot systems.
If shim allowed any unsigned GRUB binary to run, Secure Boot would be completely defeated.
Considering that you are talking about certificates below, I'm going to give you the benefit of the doubt here, but the statement above on its own is wholly inaccurate in this context.
now the shim is, the shim trusts a compiled-in certificate for any loaded binaries
And therefore, these binaries need to be signed (or hashed in), so that only the ones that have been approved by the SHIM trust committee run... just like Microsoft does.
For instance, you can open a Fedora ISO and look at the grub EFI binary provided there. You'll see the nice presence of certificates and even a link that points you to https://fedoraproject.org/wiki/Features/SecureBoot which explains that GRUB, like any other binary meant to be chained booted by the shim, must be signed, through a process that is awfully similar to the Microsoft signing process, yet, even as if it was a purely legal matter they should have no reason not to adopt the same stance as Microsoft, is GPLv3 friendly.
But even the link you pointed to explains that:
it will then validate the binary against a built-in certificate.
In other words, GRUB still needs to be signed by an authority (the one that gets its shim signed by Microsoft), who places their own signing certificate in the shim to prevent binaries that they haven't signed themselves to run (if Secure Boot is enforced).
So, it's signatures all the way, and Microsoft's Secure Boot signing signatures are no more special than the Red Hat/Fedora/Any other shim user ones, especially when another little talked about aspect of Secure Boot allows one to install their own signing keys in the firmware, at pretty much the same level as Microsoft (this is described in part at https://fedoraproject.org/wiki/Features/SecureBoot), in which case, it makes even less sense how a set of rule that doesn't seem to apply to shim providers (allow GPLv3 binaries to be signed with their own private keys) would apply to Microsoft.
problem solved.
ARTIFICIAL problem solved. And THAT is my point. This is not a legal issue. This is not a logical issue. This is a purely artificial/arbitrary issue, that should not exist in the first place.
here's a link for you to actually read the shim, since you probably never have: https://github.com/rhboot/shim/
I have long read it. But it seems you might need this more than me, since your statement about GRUB being not signed is wrong.
and there's nothing stopping you from taking a SHIM approach where you write a loader that validates the signatures
of subsequent binaries against a hardcoded cert, getting that signed, and having the problem solved.
But then that puts me at risk of becoming a very valuable target for compromise, and last time I checked (which you may want to do) the requirements for being a purveyor of a shim were a lot more stringent than for just getting a non GPLv3 binary signed for Secure Boot. As an ISV, I don't think I can meet this level of resources, and I also expect Microsoft to flat out refuse to let a single individual ultimately exert about the same level of control as they do when it comes to deciding what should be greenlit for Secure Boot and what shouldn't (even if, yes, they could revoke my shim, but the propagation of revocation, and desire to avoid it altogether, especially after the recent GRUB BootHole issue would make it very unlikely for them to let a single individual qualify as a shim purveyor).
Which means that between writing a shim, and writing my own GPLv2 NTFS UEFI driver (and relicensing UEFI-NTFS for GPLv2 or later, which, again, Microsoft will happily sign, since I wrote pretty much all of that code, and the rest was derived from GPLv2+
work) and getting that signed by Microsoft, the vastly better (and more affordable) solution is the latter.
However, considering that noone has managed to provide any logical reason as to why Microsoft would forbid GPLv3 for Secure Boot signing, where, if they did, they shouldn't transitively let shims allow GPLv3, I don't see why I should waste my time working around a limitation that appears to be purely arbitrary and abusive.
your M$ bashing is out of fashion and is just an excuse for laziness / incompetence.
If that is your assertion, then I can only hope that you're going to start looking at the issue from a logical standpoint, as I did, rather than from the idea that someone is blinded by ideology.
From a logical standpoint, and especially given that shim providers have made the decision to sign GPLv3 code and don't seem to have suffered any negative consequences from it, it just makes less and less sense for Microsoft to prevent GPLv3 binaries from being signed, no matter how you look at the GPLv3 licensing terms.
anyone can see that the GPL's requirement for disclosure of keys is retarded. cheers.
Yet, the shim people at Red Hat don't seem to see it that way, since they happily sign GRUB UEFI bootloaders.
But it's nice to see how Microsoft managed to somehow convince people, like yourself, that the root of the problem has nothing to do with what, when looked at it closely and logically, is hard to construe as anything else but a purely arbitrary decision, and that "the GPLv3 terms are simply unworkable in terms of being compatible with modern security", which is great propaganda.