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}
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)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.
no subject
Date: 2012-06-03 05:03 am (UTC)Now, we have the ability to turn off the feature in BIOS. So the work-around exists. But without changing that BIOS setting, you are creating a condition whereby the code in grub (under GPLv3) cannot be changed, for if it is changed, it won't be usable. This violates the license.
This is an example of the exact reason GPLv3's TiVo-ization clause was added.
If you do this, you're going to have to provide some access to allow modified versions of grub to be installed by those who wish to do so because it's under GPLv3. If you don't, you cannot use grub or you'll be violating the license.
But more importantly:
Why are you doing this? It is the duty of free/libre open source software companies to stand up for user rights, not just on software but also on hardware. The Linus Torvalds camp believes in the "I don't care, so long as I have powerful and reliable software", but this only takes you so far. At some point you must realize that what you lose by capitulating to dictated terms by monopoly companies like Microsoft is in fact intolerable, and that you cannot continue down that path for one minute longer.
Microsoft has crossed the line here. There were initially demanding that all ARM-based devices be locked down 100% so the disable feature did not even exist. But they BACKED DOWN because of a huge public outcry. This means they are not so dominant after all. So why are you now giving in to their demands?
Fedora is currently the #3 distro. You have weight. You can stand up to Microsoft and win with everybody else who hates this insane policy behind you. But more importantly than that, it's the right thing to do.
I hope Fedora rethinks this decision. It's a bad move and it's going to lead down a very dark path.
no subject
Date: 2012-06-03 05:15 am (UTC)Re: What if Microsoft won't sign the bootloader?
Date: 2012-06-03 05:20 am (UTC)Don't agree to anything with Microsoft. Stick with all the other FLOSS companies and be united against this overt, unethical, monopoly move by a tyrant company who hates its users. :-)
Re: What if Microsoft won't sign the bootloader?
Date: 2012-06-03 05:24 am (UTC)Education works far better than just nannying the users!"
-----
An awesome response!
Re: what about video driver blobs?
Date: 2012-06-03 05:31 am (UTC)http://www.geek.com/articles/chips/amd-f
Re: Totally unacceptable
Date: 2012-06-03 05:35 am (UTC)Hardware vendors want to do what's right too. They just can't do it alone. They need our help.
Re: Just say NO. Loudly, and clearly.
Date: 2012-06-03 05:37 am (UTC)Re: Amazing
Date: 2012-06-03 06:57 am (UTC)My post makes no such assumption at all.
My post says that we all know that Microsoft will eventually have most of the OEMs sown up creating Windows computers for sale. If RedHat and Daniel had not negotiated this deal then all of those computers would not be available to you at all. Now that would be good wouldn't it?
It also says that this doesn't mean that Linux devotees will be restricted to using Windows computers, you can use whatever you find, it just means that all those millions of Windows computers will be available and here is the kicker, ONLY IF YOU WANT TO USE THEM. No one is holding your arm up your back.
You could, of course, go and line up your own OEMs to build Linux computers but I'm sure you won't be as industrious as Microsoft will be and you'll end up with precious few computers to use, but no one is stopping you.
Can you give us proof of these claims please or is it, as I expect, just your imagination running wild?
What a load of poppycock!
No one is forcing you to do this and no one is forcing you to agree with it. You can move forward without ever using a windows computer to install your Linux on. You're a free man.
This is simply a very smart move on the part of RedHat to secure Linux access to every Windows computer produced once the UEFI comes in. They know that Windows will tie up 90% of the worlds desktops and laptops and you can't afford to let that many computers bar Linux from existence.
No one is saying it is an ideal situation, in fact Daniel explained that in the blog, but it does make sense. Remember, you don't have to use these computers, no one is forcing you.
Personally I hate the whole issue. I'd like it to just go away and leave us alone but it's not going to and these guys have worked out one way to get Linux devotees access to the majority of future computers. If you can come up with a better way we'd all be very happy but you can't solve all your problems by going to court. You need a real case first and there just isn't one here, at least not against Microsoft as the trolls would have us believe.
We all know that Microsoft were getting ready to lock up all their future boxes and we were cursing them for that but now, with a bit of maneuvering by RedHat, that is no longer going to happen. It is without doubt, the best result in a lousy situation.
no subject
Date: 2012-06-03 08:33 am (UTC)Re: Very disappointed
Date: 2012-06-03 10:05 am (UTC)And no, you will not get a secure Secure Boot, rather an unsecure Secure Boot.
Blacklists
Date: 2012-06-03 10:50 am (UTC)Secure Boot will refuse to boot anything not signed by Microsoft. If any bootloader is installed by malware to trick a linux system info thinking it is secure boot, it will not boot because it is not signed. No problem so far.
But wait, Microsoft will sign any bootloader as an accessible service. Now malware can install such signed bootloader and trick my linux system, I will not notice that.
Blacklists are a remedy: Microsoft can issue blacklist updates to protect Windows. However, Linux users will not get these updates, so:
Secure Boot for linux with a Microsoft signed shim loader is not secure anymore.
I would certainly like to hear at which point I am wrong.
Re: Blacklists
Date: 2012-06-03 02:21 pm (UTC)Re: Blacklists
Date: 2012-06-03 05:42 pm (UTC)Re: Amazing
Date: 2012-06-03 05:44 pm (UTC)True shill tactic
"My post makes no such assumption at all."
Of course it does. Your post assumes Microsoft can just simply take control of an entire PC hardware sector and manipulate standards by the size of their market sector.
"Can you give us proof of these claims please or is it, as I expect, just your imagination running wild?"
I don't need to give you "proof" of anything. This move by Microsoft is meant to block computer users access to other operating systems by blocking the ability to boot other operating systems That would clearly affect dual booting and run from cd Linux discs as well as interfere with the ability of alternative operating systems to compete against Microsoft. This move is also meant to interfere with alternative operating systems being able to use standard PC hardware without permission from Microsoft.
"No one is forcing you to do this and no one is forcing you to agree with it. You can move forward without ever using a windows computer to install your Linux on. You're a free man."
While you would be correct to use the term "Apple Computer" and say "no one is forcing you to do this" you again are assuming these are "Windows computers". They are NOT. There is no such beast. Microsoft does not manufacture "Windows Computers" Apple does manufacture Apple computers. Microsoft only manufactures software and operating systems used on standard open PC architectures. This move is clearly an attempt by Microsoft to force its will upon completely separate companies to set up an environment that excludes alternative operating systems and products. THAT IS a antitrust issue.
"We all know that Microsoft were getting ready to lock up all their future boxes and we were cursing them for that but now, with a bit of maneuvering by RedHat, that is no longer going to happen. It is without doubt, the best result in a lousy situation."
Again....Microsoft has NO "boxes" in the past, now, or in the future unless of course you are speaking of the XBox. If allowed to go on it is certainly only a "best result" for Microsoft and no one else.
Re: Blacklists
Date: 2012-06-03 05:53 pm (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)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: Amazing
Date: 2012-06-04 12:07 am (UTC)Are you the same person that wrote the first post? Who knows?
Can you please explain to me where I assumed that ...
There is absolutely nowhere that I even intimated that was the case.
OF course you do. You can't go around making such outrageous claims without proof? Do you expect everyone is going to believe any rubbish you make up just because it is bad and about Microsoft? Give us proof or keep your malicious fantasies to yourself.
No I'm not. It's just semantics your playing with there. I'm just describing them that way because, like it or not, Windows do tie up lots of computers and people have always described those computers that way. Now, with this stupid UEFI thing happening, if there were no arrangements in place like this one that RedHat have organised and you object to, that would be even more correct.
As strange as it might seem, I actually agree with you on this point, in as much as I even hate Apple locking their stuff, so I'm never going to be happy about anyone locking hardware. It's the reason that I hate the UEFI.
Now, like it or not, you are entirely missing the point. I am not, in any way, defending or condemning Microsoft for any steps they might be taking in this action, I am praising RedHat for their remarkable insight and vision that has allowed Linux users to maintain the status quo.
It is a stunning solution. Microsoft will go and work their hearts out getting OEMs to create 'Windows computers' and how good is this, Linux will get their own access to every one of those computers. On it's own, Linux could never get access to that many computers under this new scheme. I think it is amazing that, for a change, Linux will use Microsoft to get their own way.
When this UEFI thing was first mooted, I really believed that Linux users, along with all those other OSs that are not mainstream,would be destroyed because there would be no computers available for them to use but RedHat have found one solution to the problem. I cannot understand why you can't see this?
If you want to go on purposely not trying to understand what they have done and using it as an excuse to shout obscenities at Microsoft while you look at the world through your blinkered view, well you go right ahead but please, if you must come back again, can you get a name? I hate talking to someone who wants to talk nasty to me under the cover of 'Anonymous'.
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)