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}
omg
Date: 2012-06-05 06:45 pm (UTC)This way will be really hard for linux developers, the few money that now grease the free software gears will be less and too many projects will end soon... and you are helping that!
We must fight against this things, don't PAY Microsoft to destroy free software!
A little more
Date: 2012-06-05 08:59 pm (UTC)Some stuff people might be missing here:
1) While Windows 8 seems to allow you to use the machine in "unsecured" mode, it might NOT be
true in the future (Windows 9, 10?)
1.1) While (1), I'm pretty sure Windows 8 will make sure you know you're running in "unsecured"
mode. This can and will disturb dualboot users
2) It's up to Microsoft to certificate or not if they let your future distros boot in a
"secured" platform. This can be used for "evil" purposes if Linux ever picks up steam.
3) There will be users wanting to take advantage of the secure platform to run Linux. With or
without dual-boot. Matthew's work here matters.
4) History showed us "windows devices" (remember winmodems?) and how they *do* get popular
because they're cheaper because they sell more because they're cheaper.
4.1) If for any reason vendors decide to leave the off option out (to "cut costs" a.k.a. "we
simply don't care about the rest of the market") people will have true "wincomputers" unless
we have some sort of option
4.1.1) And winmodems showed us that users aren't willing to spend money to use linux. Other
situations like schools that will go for the cheaper computers and will end up locked down
to Microsoft will have no alternative.
So I believe Matthew's initiative is valid: he's being proactive in providing *option*. It's
up to all of us to make sure the vendors hear us and stop this crap.
This has a big potential of causing a lot of harm on converting users from Windows to Linux.
I personally pay more for less performance in ATI/AMD cards (or Intel's, mandatory for my
laptops) for years because I despise the lack of open source support by NVIDIA.
no subject
Date: 2012-06-06 03:23 am (UTC)Consider this...
Date: 2012-06-06 04:04 am (UTC)What bothers me about this whole thing, is Microsoft wants to also control ALL the UEFI Keys for ALL the hardware in the world starting with the release of Windows 8.
Basically, you can't boot up your machine unless your key matches or is approved by Microsoft's key process, right?
If they (MS) can screw up so bad as to let virus spread due to someone hacking their PKI keys VIA a Terminal Service licensing "Bug", what on earth is going to happen if something like this happens to all the hardware keys for every computer that uses Windows 8? (Remember, we are dealing with Microsoft - they are not at all secure in anything they do!)
You guessed it - you might not be able to boot your machine - ever!
Scary - I'll keep my Linux OS and my commodity hardware, thank you very much :-D
WTF?
Date: 2012-06-06 08:27 pm (UTC)UEFI == failed technology.
Re: WTF?
Date: 2012-06-06 08:35 pm (UTC)Re: WTF?
From: (Anonymous) - Date: 2012-06-06 08:48 pm (UTC) - ExpandWhat ifs?
Date: 2012-06-06 09:38 pm (UTC)Re: What ifs?
Date: 2012-06-06 09:39 pm (UTC)Re: What ifs?
From: (Anonymous) - Date: 2012-06-06 11:22 pm (UTC) - ExpandRe: What ifs?
From:Re: What ifs?
From: (Anonymous) - Date: 2012-06-07 02:06 am (UTC) - ExpandRe: What ifs?
From:Re: What ifs?
From: (Anonymous) - Date: 2012-06-08 04:04 pm (UTC) - ExpandRe: What ifs?
From:Re: What ifs?
From: (Anonymous) - Date: 2012-06-08 04:18 pm (UTC) - ExpandRe: What ifs?
From:Getting a license
Date: 2012-06-07 01:37 am (UTC)Thanks in advance!
-Andrew (Fewt)
Re: Getting a license
Date: 2012-06-07 01:38 am (UTC)Re: Getting a license
From: (Anonymous) - Date: 2012-06-07 01:41 am (UTC) - ExpandMore than one key?
Date: 2012-06-07 12:47 pm (UTC)Example, I have the Microsoft, Canonical, and Red Hat keys installed at the same time?
Re: More than one key?
Date: 2012-06-07 01:14 pm (UTC)Certificate Authorities?
Date: 2012-06-07 12:51 pm (UTC)Thawte, DigiCert, CAcert, GlobalSign, StartSSL, VeriSign, etc?
What happen if Microsoft say "no, we don't want to sign your bootloader anymore"?
What if Microsoft say "$99 huh? the price is now $9999"
What if Microsoft say "okay, we'll sign it, after we verify the code, it will take some months... or years"
Re: Certificate Authorities?
Date: 2012-06-11 06:50 pm (UTC)DO NOT BUY
Date: 2012-06-07 09:47 pm (UTC)Re: DO NOT BUY
Date: 2012-06-07 09:57 pm (UTC)Modify firmware?
Date: 2012-06-07 10:53 pm (UTC)This would mean Fedora only works with secure boot disabled (unless users roll their own) and freedom is maintained, etc. And that any distribution just needs their own $99 key to sign the initial boot media to disable secure boot legitimately.
-c
Re: Modify firmware?
Date: 2012-06-07 10:55 pm (UTC)@mjg59
Date: 2012-06-08 11:51 am (UTC)1. What happens to all Linux systems if Microsoft key gets compromised and has to be revoked?
After that fiasco with fake intermediary CAs that has enabled Flame malware how can we trust current security solutions and hierarchies?
Re: @mjg59
Date: 2012-06-08 12:02 pm (UTC)Re: @mjg59
From: (Anonymous) - Date: 2012-06-08 05:34 pm (UTC) - ExpandRe: @mjg59
From:Re: @mjg59
From: (Anonymous) - Date: 2012-06-08 11:13 pm (UTC) - ExpandRe: @mjg59
From:Re: @mjg59
From: (Anonymous) - Date: 2012-06-08 11:26 pm (UTC) - ExpandRe: @mjg59
From:The problem comes from where ?
Date: 2012-06-09 03:16 am (UTC)If i turn off the secured boot, windows8 will boot ?
(a) If yes, then i don't undertand the whole thing. Why manufacturer needs the w8 logo, if w8 boots unsecured too ?
(b) If not, then i need turn-it-on to boot w8 and turn-it-off to boot linux, each time i reboot to change SO. It really sucks.
What is "agressive" is that we are not speaking about an alien hardware that reachs Earth and has that characteristics. Microsoft created the "problem" and all of us must simple find a acceptable solution. Why manufacters agreed with this ?
Re: The problem comes from where ?
Date: 2012-06-12 06:52 am (UTC)Re: The problem comes from where ?
From: (Anonymous) - Date: 2012-06-13 07:14 am (UTC) - ExpandRe: The problem comes from where ?
From:No more PCs/Laptops for me
Date: 2012-06-09 11:39 am (UTC)One-time?
Date: 2012-06-11 02:50 pm (UTC)Eric
Re: One-time?
Date: 2012-06-11 09:46 pm (UTC)Re: One-time?
From:Re: One-time?
From:Sad that my favorite tech brand joining with M$
Date: 2012-06-15 12:25 pm (UTC)Is 99$ the price of freedom or is it the entry level vendor buy-in?
Date: 2012-06-22 01:05 am (UTC)b) Are you really sure the cert you buy can't be revoked? Who controls those who are controlling the BIOS vendors? You should better ask for Freedom than for Security.
My 2 cents. And yes I' switched from Windows to Fedora. But this stinks.
no subject
Date: 2012-06-22 04:30 pm (UTC)EPIC FAIL. Now you will be unable to become anyhow serious desktop competitor at all. Because I don't see what would prevent MS from f...g you up if you dare to create any real competition.
> it avoids Fedora having any special privileges over other Linux distributions.
Wrong! If I can create my own distro, I should have keys to sign it using the same scheme to be equal to you and your distro, right? Either you provide me with that key so I can sign (but then all bad guys can do the same if everyone is equal) or you don't give me the key. But then my distro and I am are certainly less privileged than you and your distro "by default". Simple as 2+2! And also forces me to go and pay another $99 for another key I guess. Hence promoting MS+Verisign services. So in your scheme you're both more privileged than those who hasn't payed for key and you're promoting MS services. And falling into dependence from MS. Can it be made worse? I doubt that. ]
Furthermore, your approach implies that you basically abandoned all opensource principles all together. If everything is signed and I don't have key, I can't modify it easily. Hence it's a vendor lock-in. Okay, I'm locked to RH instead of MS but what the ... is a difference?!
Just who pays the $99?
Date: 2012-06-24 11:59 am (UTC)I have assumed it is the end-user but on an Australian forum which I post on, one of the members is suggesting that it is the company who pays.
I find it hard to believe that such a small amount of money for a company to pay would cause so much fuss - I am assuming it is the end-user who pays.
Would be grateful if you could clarify this for me
PS Here is the Australian thread discussion I have posted on:
http://forums.whirlpool.net.au/forum-re
Re: Just who pays the $99?
Date: 2012-06-24 02:20 pm (UTC)no subject
Date: 2012-06-29 06:29 pm (UTC)How much space do you have for the blacklist in the Flash on the mainboard? It should be fairly limited. So just continue to get signed universal loaders until the space is full and no more loaders can be blacklisted.
Secure Boot Key
Date: 2012-07-08 12:48 pm (UTC)The best way to take care of malware proglems is to use current laws and process the people who violate our freedoms. These laws need to be technology upgraded and inforced. Malware/virus checker people are doing a good job at keeping systems safe.
I personally do not want any locked hardware that is counter to natural development.
PaulT
MS is a looser
Date: 2012-08-03 03:26 pm (UTC)Mathew you did a great job. People like us need something to work on it. I for one did not like the idea of UEFI. We've got no choice Microsoft wanted to control everything. Apple is using the same tactic too. To the hardware manufacturers! Give us a chance and you will get your profit for not supporting the UEFI. You will not get any form of profits with Microsoft Tactic of implementation of UEFI.