Implementing UEFI Secure Boot in Fedora
May. 30th, 2012 11:11 pm![[personal profile]](http://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59Edit 16:17EDT 31/5/12: Clarification of who gets the $99
Edit 02:10EDT 01/6/12: Clarification that it's a one-off payment
(Brief disclaimer - while I work for Red Hat, I'm only going to be talking about Fedora here. Anything written below represents only my opinions and my work on Fedora, not Red Hat's opinions or future plans)
Fedora 17 was released this week. It's both useful and free, and serves as a welcome addition to any family gathering. Do give it a go. But it's also noteworthy for another reason - it's the last Fedora release in the pre-UEFI secure boot era. Fedora 18 will be released at around the same time as Windows 8, and as previously discussed all Windows 8 hardware will be shipping with secure boot enabled by default. While Microsoft have modified their original position and all x86 Windows machines will be required to have a firmware option to disable this or to permit users to enrol their own keys, it's not really an option to force all our users to play with hard to find firmware settings before they can run Fedora. We've been working on a plan for dealing with this. It's not ideal, but of all the approaches we've examined we feel that this one offers the best balance between letting users install Fedora while still permitting user freedom.
Most hardware you'll be able to buy towards the end of the year will be Windows 8 certified. That means that it'll be carrying a set of secure boot keys, and if it comes with Windows 8 pre-installed then secure boot will be enabled by default. This set of keys isn't absolutely fixed and will probably vary between manufacturers, but anything with a Windows logo will carry the Microsoft key[1].
We explored the possibility of producing a Fedora key and encouraging hardware vendors to incorporate it, but turned it down for a couple of reasons. First, while we had a surprisingly positive response from the vendors, there was no realistic chance that we could get all of them to carry it. That would mean going back to the bad old days of scouring compatibility lists before buying hardware, and that's fundamentally user-hostile. Secondly, it would put Fedora in a privileged position. As one of the larger distributions, we have more opportunity to talk to hardware manufacturers than most distributions do. Systems with a Fedora key would boot Fedora fine, but would they boot Mandriva? Arch? Mint? Mepis? Adopting a distribution-specific key and encouraging hardware companies to adopt it would have been hostile to other distributions. We want to compete on merit, not because we have better links to OEMs.
An alternative was producing some sort of overall Linux key. It turns out that this is also difficult, since it would mean finding an entity who was willing to take responsibility for managing signing or key distribution. That means having the ability to keep the root key absolutely secure and perform adequate validation of people asking for signing. That's expensive. Like millions of dollars expensive. It would also take a lot of time to set up, and that's not really time we had. And, finally, nobody was jumping at the opportunity to volunteer. So no generic Linux key.
The last option wasn't hugely attractive, but is probably the least worst. Microsoft will be offering signing services through their sysdev portal. It's not entirely free (there's a one-off $99 fee to gain access edit: The $99 goes to Verisign, not Microsoft - further edit: once paid you can sign as many binaries as you want), but it's cheaper than any realistic alternative would have been. It ensures compatibility with as wide a range of hardware as possible and it avoids Fedora having any special privileges over other Linux distributions. If there are better options then we haven't found them. So, in all probability, this is the approach we'll take. Our first stage bootloader will be signed with a Microsoft key.
We've decided to take a multi-layer approach to our signing for a fairly simple reason. Signing through the Microsoft signing service is a manual process, and that's a pain. We don't want to have bootloader updates delayed because someone needs to find a copy of Internet Explorer and a smartcard and build packages by hand. Instead we're writing a very simple bootloader[2]. This will do nothing other than load a real bootloader (grub 2), validate that it's signed with a Fedora signing key and then execute it. Using the Fedora signing key there means that we can build grub updates in our existing build infrastructure and sign them ourselves. The first stage bootloader should change very rarely, and we don't envisage updating it more than once per release cycle. It shouldn't be much of a burden on release management.
What about grub? We've already switched Fedora 18 over to using grub 2 by default on EFI systems, but it still needs some work before it's ready for secure boot. The first thing is that we'll be disabling the module loading. Right now you can load arbitrary code into grub 2 at runtime, and that defeats the point of secure boot. So that'll be disabled. Next we'll be adding support for verifying that the kernel it's about to boot is signed with a trusted key. And finally we'll be sanitising the kernel command line to avoid certain bits of functionality that would permit an attacker to cause even a signed kernel to launch arbitrary code. These restrictions will all vanish if secure boot is disabled.
Secure boot is built on the idea that all code that can touch the hardware directly is trusted, and any untrusted code must go through the trusted code. This can be circumvented if users can execute arbitrary code in the kernel. So, we'll be moving to requiring signed kernel modules and locking down certain aspects of kernel functionality. The most obvious example is that it won't be possible to access PCI regions directly from userspace, which means all graphics cards will need kernel drivers. Userspace modesetting will be a thing of the past. Again, disabling secure boot will disable these restrictions.
Signed modules are obviously troubling from a user perspective. We'll be signing all the drivers that we ship, but what about out of tree drivers? We don't have a good answer for that yet. As before, we don't want any kind of solution that works for us but doesn't work for other distributions. Fedora-only or Ubuntu-only drivers are the last thing anyone wants, and this really needs to be handled in a cross-distribution way.
Secure boot is designed to protect against malware code running before the operating system. This isn't a hypothetical threat. Pre-boot malware exists in the wild, and some of it is nastier than you expect. So obviously bootloaders need to be signed, since otherwise you'd just replace the signed bootloader with an unsigned one that installed malware and booted your OS.
But what about the kernel? The kernel is just code. If I take a signed Linux bootloader and then use it to boot something that looks like an unsigned Linux kernel, I've instead potentially just booted a piece of malware. And if that malware can attack Windows then the signed Linux bootloader is no longer just a signed Linux bootloader, it's a signed Windows malware launcher and that's the kind of thing that results in that bootloader being added to the list of blacklisted binaries and suddenly your signed Linux bootloader isn't even a signed Linux bootloader. So kernels need to be signed.
And modules? Again, modules are just code. It's a little trickier, but if your signed kernel loads an unsigned module then that unsigned module can set up a fake UEFI environment and chain into a compromised OS bootloader. Now the attacker just has to include a signed kernel and a minimal initramfs that loads their malware module. It'd slow down boot by a couple of seconds, but other than that it'd be undetectable. X? If you can access the registers on a GPU then you can get the GPU to DMA over the kernel and execute arbitrary code. Trickier again, but still achievable - and if you've locked down every other avenue of attack, it's even attractive.
If we produce signed code that can be used to attack other operating systems then those other operating systems are justified in blacklisting us. That doesn't seem like a good outcome.
A lot of our users want to build their own kernels. Some even want to build their own distributions. Signing our bootloader and kernel is an impediment to that. We'll be providing all the tools we use for signing our binaries, but for obvious reasons we can't hand out our keys. There's three approaches here. The first is for a user to generate their own key and enrol it in their system firmware. We'll trust anything that's signed with a key that's present in the firmware. The second is to rebuild the shim loader with their own key installed and then pay $99 and sign that with Microsoft. That means that they'll be able to give copies to anyone else and let them install it without any fiddling. The third is to just disable secure boot entirely, at which point the machine should return to granting the same set of freedoms as it currently does.
A system in custom mode should allow you to delete all existing keys and replace them with your own. After that it's just a matter of re-signing the Fedora bootloader (like I said, we'll be providing tools and documentation for that) and you'll have a computer that will boot Fedora but which will refuse to boot any Microsoft code. It may be a little more awkward for desktops because you may have to handle the Microsoft-signed UEFI drivers on your graphics and network cards, but this is also solvable. I'm looking at ways to implement a tool to allow you to automatically whitelist the installed drivers. Barring firmware backdoors, it's possible to configure secure boot such that your computer will only run software you trust. Freedom means being allowed to run the software you want to run, but it also means being able to choose the software you don't want to run.
We've been working on this for months. This isn't an attractive solution, but it is a workable one. We came to the conclusion that every other approach was unworkable. The cause of free software isn't furthered by making it difficult or impossible for unskilled users to run Linux, and while this approach does have its downsides it does also avoid us ending up where we were in the 90s. Users will retain the freedom to run modified software and we wouldn't have accepted any solution that made that impossible.
But is this a compromise? Of course. There's already inequalities between Fedora and users - trademarks prevent the distribution of the Fedora artwork with modified distributions, and much of the Fedora infrastructure is licensed such that some people have more power than others. This adds to that inequality. It's not the ideal outcome for anyone, and I'm genuinely sorry that we weren't able to come up with a solution that was better. This isn't as bad as I feared it would be, but nor is it as good as I hoped it would be.
Microsoft's certification requirements for ARM machines forbid vendors from offering the ability to disable secure boot or enrol user keys. While we could support secure boot in the same way as we plan to on x86, it would prevent users from running modified software unless they paid money for a signing key. We don't find that acceptable and so have no plans to support it.
Thankfully this shouldn't be anywhere near as much of a problem as it would be in the x86 world. Microsoft have far less influence over the ARM market, and the only machines affected by this will be the ones explicitly designed to support Windows. If you want to run Linux on ARM then there'll be no shortage of hardware available to you.
No. We've spent some time thinking about all of this and are happy that we can implement it in the Fedora 18 timescale, but there's always the possibility that we've missed something or that a new idea will come up. If we can increase user freedom without making awful compromises somewhere else then we'll do it.
[1] In fact, chances are that everything will carry the Microsoft key. Secure boot requires that UEFI drivers also be signed. The signing format only permits a single signature per binary. For compatibility, approximately all add-on hardware shipped will be signed with Microsoft's key, and that means that all system vendors have to recognise Microsoft's key in order to permit that hardware to run on their systems.
[2] Current source is here. It relies on a port of the UEFI crypto library and OpenSSL that I have building with some handholding, and which I'll upload as soon as possible.
Edit 02:10EDT 01/6/12: Clarification that it's a one-off payment
(Brief disclaimer - while I work for Red Hat, I'm only going to be talking about Fedora here. Anything written below represents only my opinions and my work on Fedora, not Red Hat's opinions or future plans)
Fedora 17 was released this week. It's both useful and free, and serves as a welcome addition to any family gathering. Do give it a go. But it's also noteworthy for another reason - it's the last Fedora release in the pre-UEFI secure boot era. Fedora 18 will be released at around the same time as Windows 8, and as previously discussed all Windows 8 hardware will be shipping with secure boot enabled by default. While Microsoft have modified their original position and all x86 Windows machines will be required to have a firmware option to disable this or to permit users to enrol their own keys, it's not really an option to force all our users to play with hard to find firmware settings before they can run Fedora. We've been working on a plan for dealing with this. It's not ideal, but of all the approaches we've examined we feel that this one offers the best balance between letting users install Fedora while still permitting user freedom.
Getting the machine booted
Most hardware you'll be able to buy towards the end of the year will be Windows 8 certified. That means that it'll be carrying a set of secure boot keys, and if it comes with Windows 8 pre-installed then secure boot will be enabled by default. This set of keys isn't absolutely fixed and will probably vary between manufacturers, but anything with a Windows logo will carry the Microsoft key[1].
We explored the possibility of producing a Fedora key and encouraging hardware vendors to incorporate it, but turned it down for a couple of reasons. First, while we had a surprisingly positive response from the vendors, there was no realistic chance that we could get all of them to carry it. That would mean going back to the bad old days of scouring compatibility lists before buying hardware, and that's fundamentally user-hostile. Secondly, it would put Fedora in a privileged position. As one of the larger distributions, we have more opportunity to talk to hardware manufacturers than most distributions do. Systems with a Fedora key would boot Fedora fine, but would they boot Mandriva? Arch? Mint? Mepis? Adopting a distribution-specific key and encouraging hardware companies to adopt it would have been hostile to other distributions. We want to compete on merit, not because we have better links to OEMs.
An alternative was producing some sort of overall Linux key. It turns out that this is also difficult, since it would mean finding an entity who was willing to take responsibility for managing signing or key distribution. That means having the ability to keep the root key absolutely secure and perform adequate validation of people asking for signing. That's expensive. Like millions of dollars expensive. It would also take a lot of time to set up, and that's not really time we had. And, finally, nobody was jumping at the opportunity to volunteer. So no generic Linux key.
The last option wasn't hugely attractive, but is probably the least worst. Microsoft will be offering signing services through their sysdev portal. It's not entirely free (there's a one-off $99 fee to gain access edit: The $99 goes to Verisign, not Microsoft - further edit: once paid you can sign as many binaries as you want), but it's cheaper than any realistic alternative would have been. It ensures compatibility with as wide a range of hardware as possible and it avoids Fedora having any special privileges over other Linux distributions. If there are better options then we haven't found them. So, in all probability, this is the approach we'll take. Our first stage bootloader will be signed with a Microsoft key.
Bootloaders
We've decided to take a multi-layer approach to our signing for a fairly simple reason. Signing through the Microsoft signing service is a manual process, and that's a pain. We don't want to have bootloader updates delayed because someone needs to find a copy of Internet Explorer and a smartcard and build packages by hand. Instead we're writing a very simple bootloader[2]. This will do nothing other than load a real bootloader (grub 2), validate that it's signed with a Fedora signing key and then execute it. Using the Fedora signing key there means that we can build grub updates in our existing build infrastructure and sign them ourselves. The first stage bootloader should change very rarely, and we don't envisage updating it more than once per release cycle. It shouldn't be much of a burden on release management.
What about grub? We've already switched Fedora 18 over to using grub 2 by default on EFI systems, but it still needs some work before it's ready for secure boot. The first thing is that we'll be disabling the module loading. Right now you can load arbitrary code into grub 2 at runtime, and that defeats the point of secure boot. So that'll be disabled. Next we'll be adding support for verifying that the kernel it's about to boot is signed with a trusted key. And finally we'll be sanitising the kernel command line to avoid certain bits of functionality that would permit an attacker to cause even a signed kernel to launch arbitrary code. These restrictions will all vanish if secure boot is disabled.
Kernel
Secure boot is built on the idea that all code that can touch the hardware directly is trusted, and any untrusted code must go through the trusted code. This can be circumvented if users can execute arbitrary code in the kernel. So, we'll be moving to requiring signed kernel modules and locking down certain aspects of kernel functionality. The most obvious example is that it won't be possible to access PCI regions directly from userspace, which means all graphics cards will need kernel drivers. Userspace modesetting will be a thing of the past. Again, disabling secure boot will disable these restrictions.
Signed modules are obviously troubling from a user perspective. We'll be signing all the drivers that we ship, but what about out of tree drivers? We don't have a good answer for that yet. As before, we don't want any kind of solution that works for us but doesn't work for other distributions. Fedora-only or Ubuntu-only drivers are the last thing anyone wants, and this really needs to be handled in a cross-distribution way.
Wait signed what
Secure boot is designed to protect against malware code running before the operating system. This isn't a hypothetical threat. Pre-boot malware exists in the wild, and some of it is nastier than you expect. So obviously bootloaders need to be signed, since otherwise you'd just replace the signed bootloader with an unsigned one that installed malware and booted your OS.
But what about the kernel? The kernel is just code. If I take a signed Linux bootloader and then use it to boot something that looks like an unsigned Linux kernel, I've instead potentially just booted a piece of malware. And if that malware can attack Windows then the signed Linux bootloader is no longer just a signed Linux bootloader, it's a signed Windows malware launcher and that's the kind of thing that results in that bootloader being added to the list of blacklisted binaries and suddenly your signed Linux bootloader isn't even a signed Linux bootloader. So kernels need to be signed.
And modules? Again, modules are just code. It's a little trickier, but if your signed kernel loads an unsigned module then that unsigned module can set up a fake UEFI environment and chain into a compromised OS bootloader. Now the attacker just has to include a signed kernel and a minimal initramfs that loads their malware module. It'd slow down boot by a couple of seconds, but other than that it'd be undetectable. X? If you can access the registers on a GPU then you can get the GPU to DMA over the kernel and execute arbitrary code. Trickier again, but still achievable - and if you've locked down every other avenue of attack, it's even attractive.
If we produce signed code that can be used to attack other operating systems then those other operating systems are justified in blacklisting us. That doesn't seem like a good outcome.
Customisation
A lot of our users want to build their own kernels. Some even want to build their own distributions. Signing our bootloader and kernel is an impediment to that. We'll be providing all the tools we use for signing our binaries, but for obvious reasons we can't hand out our keys. There's three approaches here. The first is for a user to generate their own key and enrol it in their system firmware. We'll trust anything that's signed with a key that's present in the firmware. The second is to rebuild the shim loader with their own key installed and then pay $99 and sign that with Microsoft. That means that they'll be able to give copies to anyone else and let them install it without any fiddling. The third is to just disable secure boot entirely, at which point the machine should return to granting the same set of freedoms as it currently does.
But I don't trust Microsoft
A system in custom mode should allow you to delete all existing keys and replace them with your own. After that it's just a matter of re-signing the Fedora bootloader (like I said, we'll be providing tools and documentation for that) and you'll have a computer that will boot Fedora but which will refuse to boot any Microsoft code. It may be a little more awkward for desktops because you may have to handle the Microsoft-signed UEFI drivers on your graphics and network cards, but this is also solvable. I'm looking at ways to implement a tool to allow you to automatically whitelist the installed drivers. Barring firmware backdoors, it's possible to configure secure boot such that your computer will only run software you trust. Freedom means being allowed to run the software you want to run, but it also means being able to choose the software you don't want to run.
You've sold out
We've been working on this for months. This isn't an attractive solution, but it is a workable one. We came to the conclusion that every other approach was unworkable. The cause of free software isn't furthered by making it difficult or impossible for unskilled users to run Linux, and while this approach does have its downsides it does also avoid us ending up where we were in the 90s. Users will retain the freedom to run modified software and we wouldn't have accepted any solution that made that impossible.
But is this a compromise? Of course. There's already inequalities between Fedora and users - trademarks prevent the distribution of the Fedora artwork with modified distributions, and much of the Fedora infrastructure is licensed such that some people have more power than others. This adds to that inequality. It's not the ideal outcome for anyone, and I'm genuinely sorry that we weren't able to come up with a solution that was better. This isn't as bad as I feared it would be, but nor is it as good as I hoped it would be.
What about ARM
Microsoft's certification requirements for ARM machines forbid vendors from offering the ability to disable secure boot or enrol user keys. While we could support secure boot in the same way as we plan to on x86, it would prevent users from running modified software unless they paid money for a signing key. We don't find that acceptable and so have no plans to support it.
Thankfully this shouldn't be anywhere near as much of a problem as it would be in the x86 world. Microsoft have far less influence over the ARM market, and the only machines affected by this will be the ones explicitly designed to support Windows. If you want to run Linux on ARM then there'll be no shortage of hardware available to you.
Is this all set in stone?
No. We've spent some time thinking about all of this and are happy that we can implement it in the Fedora 18 timescale, but there's always the possibility that we've missed something or that a new idea will come up. If we can increase user freedom without making awful compromises somewhere else then we'll do it.
[1] In fact, chances are that everything will carry the Microsoft key. Secure boot requires that UEFI drivers also be signed. The signing format only permits a single signature per binary. For compatibility, approximately all add-on hardware shipped will be signed with Microsoft's key, and that means that all system vendors have to recognise Microsoft's key in order to permit that hardware to run on their systems.
[2] Current source is here. It relies on a port of the UEFI crypto library and OpenSSL that I have building with some handholding, and which I'll upload as soon as possible.
![[identity profile]](http://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
bootpath security in general
Date: 2012-06-01 01:17 pm (UTC)First of all, thanks very much, I've been following your posts here and on LWN, and I really appreciate what you have been doing and documenting with respect to UEFI
As to the general idea of bootpath security, I am a little taken aback by some of things I didn't think about previously. Things like usermode PCI drivers, systemtap, and out-of-tree modules are things I never considered. Is this the inevitable consequence of any form of secured boot path implementation? How is Microsoft managing this situation? I imagine there will be some developers and server users that will want things to work with Secure Boot.
And with respect to the Linux UEFI solution, can you envision certain changes in the kernel in response? For example, perhaps a restriction on modules (or unsigned modules) on access to UEFI/BIOS would provide the same security?
Thanks
Legally dubious?
Date: 2012-06-01 02:04 pm (UTC)However, I'd be curious to know why MS aren't being dragged over the coals for antitrust over this: they are using their monopoly position to create an impediment to competing operating systems. That is, they are using their monopoly position to push manufacturers to produce systems that can't boot other OSes (without lots of user-unfriendly fiddling in the BIOS) unless those OS vendors have used a MS service that costs them money. I know that the money doesn't go to MS, but that's hardly the point - it is an impedement to the competing systems all the same.
When I say they are using their monopoly position to push the manufacturers to do this, look at it this way: if Fedora told someone like Dell that they could receive a "Fedora Certification" if they prevented OSes that weren't Fedora from booting without the user fiddling the BIOS, what do you think Dell would say? I'm pretty sure they would tell you to go to hell because Fedora (as big as it is) doesn't have the might to convince a manufacturer that Fedora Certification is worth making it hard for users of Windows, etc., whilst MS seemingly does.
Re: Legally dubious?
Date: 2012-06-03 10:34 pm (UTC)They're not stopping manufacturers from including competitor's signing keys.
So I don't see where the anti-trust FUD comes in.
And as for the idea that "fiddling in the BIOS" is an impediment to Fedora users, well that's just hilarious. You must have a pretty low opinion of the technical abilities of people who use Fedora. If disabling secure boot is too hard, God help anyone who has to change the boot order so they can boot from CD to install the damn thing.
Re: Legally dubious?
From: (Anonymous) - Date: 2012-06-04 11:04 pm (UTC) - ExpandRe: Legally dubious?
From: (Anonymous) - Date: 2012-06-05 08:19 am (UTC) - ExpandAntitrust violation for Microsoft's practice?
Date: 2012-06-01 03:09 pm (UTC)http://en.wikipedia.org/wiki/Tying_(comm
Windows 8 as it stands is a piece of crap. Paying Microsoft $99 even if we don't want to use that piece of crap is completely unacceptable.
Implementing UEFI Secure Boot in Fedora
Date: 2012-06-01 03:49 pm (UTC)Microsoft must be highly complimented for finding the way to defeat the anti-monopoly laws.
I have used Fedora since Fedora Core 3. If Fedora pays Microsoft any fees, I will end using Fedora.
I will not purchase nor recommend any hardware that limits the freedom of choice.
The time to stand for freedom has come!
Re: Implementing UEFI Secure Boot in Fedora
Date: 2012-06-02 06:01 pm (UTC)Learn to read. Fedora is not paying Microsoft. Geez, I can't believe how dim some Linux users are.
Re: Implementing UEFI Secure Boot in Fedora
From: (Anonymous) - Date: 2012-06-02 08:33 pm (UTC) - ExpandRe: Implementing UEFI Secure Boot in Fedora
From: (Anonymous) - Date: 2012-06-06 09:15 pm (UTC) - Expanddkms
Date: 2012-06-01 07:29 pm (UTC)Re: dkms
Date: 2012-06-01 07:34 pm (UTC)Re: dkms
From: (Anonymous) - Date: 2012-06-01 10:11 pm (UTC) - ExpandRe: dkms
From:Re: dkms
From: (Anonymous) - Date: 2012-06-02 08:55 pm (UTC) - ExpandRe: dkms
From:Re: dkms
From: (Anonymous) - Date: 2012-06-02 09:13 pm (UTC) - ExpandRe: dkms
From:Re: dkms
From: (Anonymous) - Date: 2012-06-02 09:31 pm (UTC) - ExpandRe: dkms
From:Re: dkms
From: (Anonymous) - Date: 2012-06-02 10:34 pm (UTC) - ExpandRe: dkms
From:Blacklists
From: (Anonymous) - Date: 2012-06-03 10:50 am (UTC) - ExpandRe: Blacklists
From:Re: Blacklists
From: (Anonymous) - Date: 2012-06-03 05:42 pm (UTC) - ExpandRe: Blacklists
From:Signed X86 hardware
Date: 2012-06-01 09:34 pm (UTC)Dear Mr. Chamberlain
Date: 2012-06-02 12:10 am (UTC)UEFI Secure Boot in Fedora
Date: 2012-06-02 01:53 am (UTC)I must say I'm very disillusioned. I thought I had heard the worst of Microsoft, but anything can apparently always become worse.
One thing is sure - I am not getting rid of my old computers very soon.
no subject
Date: 2012-06-02 02:09 am (UTC)no subject
Date: 2012-06-02 06:03 pm (UTC)Do not cower for the bully
Date: 2012-06-02 05:20 am (UTC)You never give in to bullies.
Please fight with all you have. I will never pay Microsoft for the privilege of using my hardware with Linux.
Amazing
Date: 2012-06-02 08:38 am (UTC)It seems to me that Fedora have taken a really logical step and have leveraged the fact that Windows will tie up most OEMs and get you the ability to use all that hardware.
Imagine where you'd be if Fedora didn't do this?
Everyone of those bits of hardware could be out of your reach but this little bit of innovation means that you will be able to use as many machines as MS do.
No one said that Microsoft have been actively selling this idea or pushing it onto unsuspecting Linux imbeciles? This seems to have been a good deal done on your behalf.
And please, Microsoft is not getting paid to do this? Read the blog again and calm down. Without this bit of diplomatic maneuvering by Matthew and Fedora, you would be locked out of millions of machines worldwide. No-one says you can't use other means of getting into UEFI machines but this action has got you the ability to use all of the machines that will be Windows OEMs, but only if you want to.
Now, go and have a good lie down and think about it for a minute. Lord!
Re: Amazing
Date: 2012-06-03 04:09 am (UTC)Imagine where Microsoft would be had this been done to them in the early days.....absolutely no where if they even existed at all. But that is beside the point. Your post assumes that Microsoft deserves to be able to control the market like this simply because they are the biggest OS provider in the market. THEY DON'T!
"Everyone of those bits of hardware could be out of your reach but this little bit of innovation means that you will be able to use as many machines as MS do."
Horsecrap! Microsoft will use this to hamper Linux at every opportunity. Doing this will NOT allow easy access to hardware. Quite the contrary, it validates Microsoft as being the sole gatekeeper on access to PC hardware, something they only dreamed about in their wettest wet dreams previously.
"No one said that Microsoft have been actively selling this idea or pushing it onto unsuspecting Linux imbeciles? This seems to have been a good deal done on your behalf."
Total bullsh*t! (talk about an "imbecile")
"And please, Microsoft is not getting paid to do this? Read the blog again and calm down. Without this bit of diplomatic maneuvering by Matthew and Fedora, you would be locked out of millions of machines worldwide. No-one says you can't use other means of getting into UEFI machines but this action has got you the ability to use all of the machines that will be Windows OEMs, but only if you want to."
Yes, they are getting paid to this. They get "paid" every time a user has access blocked to competitive operating systems. They get paid every time a user can't use their machine to try out a run from CD Linux disc. They get paid every time a user loses the ability to dual boot into Linux. UEFI segregates Linux from Windows users who might be curious enough to consider switching away from Microsoft. Microsoft KNOWS this will be the long term effect of UEFI. They are using the same old tactic of "weapons of mass destruction" excuse for an unjustified war but in this case UEFI is supposedly going to "save" the world from malware. Of course we all know it won't. Malware will just figure a way around it as it always has in the past. This won't be a silver bullet for Windows users but.....it will certainly block competitors access to a formerly open PC architecture and also greatly hamper the ability of Windows users to make a successful test run of Linux let alone actually make the switch or explore Linux at all. THIS is what UEFI is all about and MIcrosoft KNOWS that will be the end result.
This IS an antitrust issue and it DESERVES legal action.
Re: Amazing
From: (Anonymous) - Date: 2012-06-03 06:57 am (UTC) - ExpandRe: Amazing
From: (Anonymous) - Date: 2012-06-03 05:44 pm (UTC) - ExpandRe: Amazing
From: (Anonymous) - Date: 2012-06-04 12:07 am (UTC) - ExpandObvious solution!
Date: 2012-06-02 05:28 pm (UTC)Buy your hardware from Linux vendors.
no subject
Date: 2012-06-02 11:06 pm (UTC)I will not accept any third party key ownership on my system, be that Microsoft, Versign, Fedora or Linux. If I want secure boot, TPM or any other sort of keys they will be created and owned by me.
Fedora should be joining the fight to stop this foolishness rather than encouraging it.
Please put this to a vote.
Security
Date: 2012-06-07 05:32 pm (UTC)There are two problems with not offering a signed bootloader. Firstly, new desktop Linux users mostly experiment with installing Linux on a computer that was bought with Windows. The scarier the process looks ("Disable secure boot in the firmware? That doesn't sound safe..."), the more potential users we lose. Secondly, secure boot is a legitimate security feature, that can benefit people who wouldn't be prepared to sign their own kernel. They shouldn't have to accept reduced security to use Linux.
It's definitely not an ideal solution. But I agree with Matthew that it's the least-worst option. 'The fight to stop this' probably isn't going to get much traction, even if Fedora & Ubuntu put their weight behind it.
no subject
Date: 2012-06-02 11:26 pm (UTC)Linux is about creating an operating system the right way... why is that button there? why is it coded like that?
Because it is more productive makes more sence as a computer scientist and it's more efficient.
Not... becuase it's pretty or because some person with no coding experience and some fake ass degree in design, decided it should be like that. Everyday I find people more and more concerned with market share and copying Windows, Mac and tablet layouts at the expensive of people who actually use the platform. Guys seriously grow the f**k up, we need to get on with our work and life and scientific research and progress the human race. We don't want to have to change distrbution every week, or window manager every day, just because you decide that some metaphorical user who has no idea about computers might in 20 years time have it on a touch screen. This is Linus territory.
Free software is about creating something that is customizable and open, if you do not like it you can change it, if it is not pretty then you can make it pretty. This is about giving people choice and stopping them being locked in to software manufacturers. And the seperation of software and hardware. This is RMS territory.
Take your pick, one or the other or both, neither of these supports the way you are taking Fedora right now.
Also please stop looking down on people who do not have a computer background, it does not really take that long for them to learn to use Gnome 2. And if they have a problem they take it to an expert anyway. People who really cannot disable secure boot; really cannot install linux or even upgrade their copy of windows anyway, they will take it to an expert.
You should be focussing on selling Linux pre-installed on hardware and not on a non-existant market of incompetent users who you think will download to a USB and install.
What if I want to run XP or MSDOS, will they have a secure boot
Date: 2012-06-03 12:32 am (UTC)I presume they will provide MSDOS and other signing rights.
And if I want to boot from a USB, will I be able to? or from a remote file? Will I be able to.
Re: What if I want to run XP or MSDOS, will they have a secure boot
Date: 2012-06-03 12:38 am (UTC)This is the dead end of PC
Date: 2012-06-03 01:39 am (UTC)How are keys installed?
Date: 2012-06-03 06:29 pm (UTC)Re: How are keys installed?
Date: 2012-06-03 06:50 pm (UTC)not so 'unworkable' + questions
Date: 2012-06-04 08:53 am (UTC)I understand your logic and I respect your opinion, I just want to say that mine, is that this is the least worst option and not the signed-by-Microsoft-key bootloader one.
Some notes (again in my opinion and assuming I have understood things correctly):
Btw, this a public-private key scheme, right? Distribution signs with and keeps secret the private key, while users get corresponding public key from distribution's site and type it into UEFI BIOS menu?
How does this public key look like? Can I write in on my DVD to remember it?
Implementing UEFI Secure Boot
Date: 2012-06-04 10:19 am (UTC)no subject
Date: 2012-06-04 12:12 pm (UTC)Does the mandatory requirement to have no option to disable secure boot also imply that there will be no option to enroll keys?
No more live CDs?
Date: 2012-06-04 01:06 pm (UTC)Re: No more live CDs?
Date: 2012-06-04 01:07 pm (UTC)Real solution: don't buy Microsoft Windows 8 hardware
Date: 2012-06-04 02:27 pm (UTC)Microsoft can take their UEFI and shove it, far as I'm concerned.
it's a bit tricky to build a laptop
Date: 2012-06-12 06:49 am (UTC)Linux Foundation as Linux key provider in the long term?
Date: 2012-06-04 08:44 pm (UTC)To me it seems that the Linux Foundation would be a natural choice for providing a Linux Key signing service. It has many or most of the hardware vendors as members, so there is an established (and reasonably distro/vendor-neutral) communication channel for convincing them to ship this key on their hardware.
Please consider pushing in that direction in the future.
-- Jon Nordby, www.jonnor.com
FOSS
Date: 2012-06-05 03:26 am (UTC)Fedora and Windows
Date: 2012-06-05 11:16 am (UTC)In your post, you suppose that anyone buys PC "Windows 8 branded".
To install Fedora (or other distro GNU/Linux), the buyer should use a bootloader/kernel/module signed to no harm to Windows. Therefore Linux becomes a protection for Windows, but GNU/Linux distros are not "a protection for something else".
Also, if i buy a PC without Windows8, should i use a "Fedora signed" ?