- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
UEFI Secure Boot
|
|
|
Comments (36)
16 earlier comments in the full thread.
In previous comments I faulted Red Hat for rushing into a solution that includes MS. Including MS can never be but dangerous.
But, could it be that Red Had is purposely doing that to trigger more interest in finding a solution before it is too late? After all, they did say this isn't final and open to suggestions.
May be including MS was mostly to demonstrate how dangerously serious it could get if nothing was done about it before hand and MS ends up making the decision for us all.
Just thinking.
But, could it be that Red Had is purposely doing that to trigger more interest in finding a solution before it is too late? After all, they did say this isn't final and open to suggestions.
May be including MS was mostly to demonstrate how dangerously serious it could get if nothing was done about it before hand and MS ends up making the decision for us all.
Just thinking.
Quoting:For all those who are upset at Red Hat, please answer this: What was the alternative? What would have happened if the Linux community stud up against UEFI and it went ahead anyway?
At this point the alternative is to make do with the other solutions (something that most distributions will have to do anyway). Those are:
1. Ask users with a Secure Boot capable UEFI firmware to disable Secure Boot before installing any operating system other than the one(s) their computer has a key for in its list.
2. Take advantage of systems that allow users to add their own Secure Boot keys to the list on their computer.
Of course, by naming it "Secure Boot" Microsoft is also giving the impression that disabling it is a security risk, so users should think twice before installing this other operating system that compromises the security of their computer. Secure Boot doesn't actually stop your system from being compromised, though, it only stops it from running once a particular type of compromise (a rootkit) has happened. That actually could help stop some malware from propagating as quickly. The problem is that Secure Boot can't really tell the difference between malware and legitimate software.
Secure Boot will not only stop you from installing alternative systems like Linux or BSD. It could also easily end up stopping you from installing newer or older versions of Windows than the one that came with the machine.
I'm pretty sure this has already been answered, but I missed it.
People talk about having to sign the OS kernel, but wouldn't the firmware be irrelevant once past the boot loader?
So wouldn't it be GRUB/LILO that's needing to be keyed?
People talk about having to sign the OS kernel, but wouldn't the firmware be irrelevant once past the boot loader?
So wouldn't it be GRUB/LILO that's needing to be keyed?
@Bob_Robertson: Yes.
@CFWhitman: You are assuming OEMs will produce hardware that either doesn't have UEFI or allows users choices. I don't make such an assumption. I assume Microsoft will strong arm OEMs to make sure that their hardware is 100% locked in to Windows-the-latest.
Does anyone remember what happened with ASUS at Computex in 2009? Their lovely little Snapdragon (ARM) powered EeePC that they apologized for showing? A Microsoft VP was on stage for that apology.
How about IBM's testimony during the DOJ's pursuit of Microsoft? Anyone else remember how OS/2 really died?
How about HP? Their Linux laptop/netbook offerings disappeared the day Windows 7 was releases. Does anyone believe that was a big coincidence? I didn't think so.
Red Hat had two options: cut a deal or get locked out of the desktop market entirely. Considering many of their enterprise server customers also demand a desktop product that reduced their options to one.
@CFWhitman: You are assuming OEMs will produce hardware that either doesn't have UEFI or allows users choices. I don't make such an assumption. I assume Microsoft will strong arm OEMs to make sure that their hardware is 100% locked in to Windows-the-latest.
Does anyone remember what happened with ASUS at Computex in 2009? Their lovely little Snapdragon (ARM) powered EeePC that they apologized for showing? A Microsoft VP was on stage for that apology.
How about IBM's testimony during the DOJ's pursuit of Microsoft? Anyone else remember how OS/2 really died?
How about HP? Their Linux laptop/netbook offerings disappeared the day Windows 7 was releases. Does anyone believe that was a big coincidence? I didn't think so.
Red Hat had two options: cut a deal or get locked out of the desktop market entirely. Considering many of their enterprise server customers also demand a desktop product that reduced their options to one.
@Fettoosh
If you must use RedHat kernel binaries without the ability of running a self-compiled kernel, what does open source means ? How is it still relevant ? These binaries may contain trojans specially delivered to you if you work on sensitive data. It's really a conspiration, perhaps blessed by the DOD, CIA, MI6... who knows... Security remains a paranoid affair and the situation is already alarming.
If you must use RedHat kernel binaries without the ability of running a self-compiled kernel, what does open source means ? How is it still relevant ? These binaries may contain trojans specially delivered to you if you work on sensitive data. It's really a conspiration, perhaps blessed by the DOD, CIA, MI6... who knows... Security remains a paranoid affair and the situation is already alarming.
You would not have to use Red Hat kernel binaries and the kernel source will still be open. Geez! Welcome to panic and misinformation central. Bob_Robertson got it right: the key has to be in the bootloader, not the kernel. Otherwise it will be pretty darned easy to bypass this entire mess.
@caitlyn
According to http://mjg59.dreamwidth.org/12368.html
kernel and modules will have to be signed Fedora won't give away their signing keys (logical) Not only the bootloader is signed.
And that's a Fedora Guru writing on how Fedora will implement secure boot.
No we are not in Daisy land !
kernel and modules will have to be signed Fedora won't give away their signing keys (logical) Not only the bootloader is signed.
And that's a Fedora Guru writing on how Fedora will implement secure boot.
No we are not in Daisy land !
Quoting:People talk about having to sign the OS kernel,...
I thought the OS would have some sort of a way to communicate with UEFI or have its own application CA list. Or is that a future feature?!
Does anyone have good information on how this whole thing is being implemented by MS, if it had been released?
Quoting: Does anyone have good information on how this whole thing is being implemented by MS, if it had been released?
Uhmmm,... Badly?!?!
> Uhmmm,... Badly?!?!
That's a given.
That's a given.
Quoting:You are assuming OEMs will produce hardware that either doesn't have UEFI or allows users choices.
No, I'm not assuming anything; I'm just listing the alternatives. Remember that most Linux distributions will not have the option to purchase a key from Microsoft. However, it is true that Microsoft has promised that OEMs will be allowed, even encouraged, to make Secure Boot an option in CMOS for x86/amd64 based UEFI systems. Of course a promise like that doesn't mean much coming from a large corporation like Microsoft.
On the other hand, it's fairly certain that the demand for Linux is not going to disappear overnight because of the release of Windows 8. There will be companies that produce hardware that will support Linux. The problem is that there is no reason for Secure Boot to be an issue you should have to worry about, but they are making it one.
By the way, my current home desktop system has UEFI firmware. It's not UEFI that's the problem; it's very specifically the Secure Boot feature that is problematic.
Quoting: Remember that most Linux distributions will not have the option to purchase a key from Microsoft.
It should be easy enough to buy cheap workarounds off the warez 'n' crax market within a couple of weeks of release.
Read the IBM testimony from the DOJ case. They were given a choice: drop OS/2 or never receive a copy of Windows at any price. They almost went with OS/2 but the PC Company convinced upper management that would be suicidal for their business. The 11th hour compromise was that IBM would no longer market OS/2 or provide ISV support, effectively dooming the OS.
Quoting: On the other hand, it's fairly certain that the demand for Linux is not going to disappear overnight because of the release of Windows 8.What if Microsoft told a manufacturer that their desktop (not server) hardware will run Windows 8 exclusively or they would never be able to buy Windows again. How many would cave in? All of them. Considering there is precedent for Microsoft doing exactly that I am not sanguine about the availability of hardware that will run Linux without hacking.
Quoting:It should be easy enough to buy cheap workarounds off the warez 'n' crax market within a couple of weeks of release.That's fine for individual users. Linux distributors would be opening themselves up for legal action in a big way.
Hmmm. caitlyn, you seem to have close relationship with RedHat, your posts are not objective and do not sweat 'straightness', a compiler would sparkle lots of errors at these !
@CFWhitman
If 'option # 2' was something we could actually count on, we wouldn't have a problem.
And we should be able to. But we can't.
It's perfectly sensible that MS would insist that Win 8 systems be shipped with "Secure Boot" mode enabled -- that could rightly be labelled a "sane default".
And it's fine that "Secure Boot" can be disabled (for x86 only though, not ARM). That's also sensible.
But MS has very cleverly and very sneakily and with malice aforethought (does anybody familiar with Microsoft's history think MS did this 'inadvertently' or without full understanding of the competitive implications?) made absolutely no mention of UEFI Secure Boot key management in its formal specifications for Win 8 certification.
-- -- -- -- --
I think that the clinching detail is that Microsoft appears to have co-opted the terminology, managing to re-frame the issue, successfully labelling the sensible, full, managed-key UEFI implementation as "Custom Mode" (!) and the Windows-only Secure Boot implementations as "Standard Mode".
Perhaps it would be an effective tactic to refuse this framing -- pointing out if necessary the biased re-labelling that Microsoft has been so cleverly pushing -- and consistently call them by more sensible terms, instead,
such as "User Mode" or perhaps "Managed Mode",
versus
"Microsoft Mode" or "Custom Microsoft Mode", or "Microsoft 'Default' Mode...
Quoting: At this point the alternative is to make do with the other solutions (something that most distributions will have to do anyway). Those are:
1. Ask users with a Secure Boot capable UEFI firmware to disable Secure Boot before installing any operating system other than the one(s) their computer has a key for in its list.
2. Take advantage of systems that allow users to add their own Secure Boot keys to the list on their computer.
If 'option # 2' was something we could actually count on, we wouldn't have a problem.
And we should be able to. But we can't.
It's perfectly sensible that MS would insist that Win 8 systems be shipped with "Secure Boot" mode enabled -- that could rightly be labelled a "sane default".
And it's fine that "Secure Boot" can be disabled (for x86 only though, not ARM). That's also sensible.
But MS has very cleverly and very sneakily and with malice aforethought (does anybody familiar with Microsoft's history think MS did this 'inadvertently' or without full understanding of the competitive implications?) made absolutely no mention of UEFI Secure Boot key management in its formal specifications for Win 8 certification.
-- -- -- -- --
I think that the clinching detail is that Microsoft appears to have co-opted the terminology, managing to re-frame the issue, successfully labelling the sensible, full, managed-key UEFI implementation as "Custom Mode" (!) and the Windows-only Secure Boot implementations as "Standard Mode".
Perhaps it would be an effective tactic to refuse this framing -- pointing out if necessary the biased re-labelling that Microsoft has been so cleverly pushing -- and consistently call them by more sensible terms, instead,
such as "User Mode" or perhaps "Managed Mode",
versus
"Microsoft Mode" or "Custom Microsoft Mode", or "Microsoft 'Default' Mode...
I want to be clear here that I am not saying that Red Hat didn't have to do this because there are alternatives and everything will be hunky dory. I'm only saying that what Red Hat is doing is not a solution for the problem in any way.
That may or may not be a problem with OEMs (it's the type of thing that could draw anti-trust attention, though, particularly in Europe). Regardless, there are motherboard manufacturers who do not want to lose out on component sales to do-it-yourselfers, and there is no practical way to make Secure Boot an absolute necessity when selling computers as components because the array of operating systems involved is too unpredictable (even when you are talking about only different versions of Windows). There will be places you can get computers. As I said before, though, there should be a very set way of dealing with Secure Boot issues so that users won't have a problem, but Microsoft is not pushing things in the right direction.
Microsoft feels that they can get away with enforcing Secure Boot on ARM devices because no market for unlocked devices has been established so far (the other ARM device makers are doing essentially the same thing).
To an extent, though, I think that Secure Boot is an attempt to put the genie of custom software installations back into the bottle, and I don't think it will hold up in the end (I just think it will cause a lot of headaches in the meantime). Eventually, there will be a significant amount of unlocked ARM hardware on the market (there already is some). It will gradually become harder to convince the geek market (the core of the computer sales market) that they don't want unlocked hardware.
Quoting:What if Microsoft told a manufacturer that their desktop (not server) hardware will run Windows 8 exclusively or they would never be able to buy Windows again. How many would cave in? All of them.
That may or may not be a problem with OEMs (it's the type of thing that could draw anti-trust attention, though, particularly in Europe). Regardless, there are motherboard manufacturers who do not want to lose out on component sales to do-it-yourselfers, and there is no practical way to make Secure Boot an absolute necessity when selling computers as components because the array of operating systems involved is too unpredictable (even when you are talking about only different versions of Windows). There will be places you can get computers. As I said before, though, there should be a very set way of dealing with Secure Boot issues so that users won't have a problem, but Microsoft is not pushing things in the right direction.
Microsoft feels that they can get away with enforcing Secure Boot on ARM devices because no market for unlocked devices has been established so far (the other ARM device makers are doing essentially the same thing).
To an extent, though, I think that Secure Boot is an attempt to put the genie of custom software installations back into the bottle, and I don't think it will hold up in the end (I just think it will cause a lot of headaches in the meantime). Eventually, there will be a significant amount of unlocked ARM hardware on the market (there already is some). It will gradually become harder to convince the geek market (the core of the computer sales market) that they don't want unlocked hardware.
@nmset: Thanks for the false accusations. I have not had any relationship at all with Red Hat since November, 2005. Perhaps you are the one who can't accept a view other than yours and assume it must be bias. It isn't.
Quoting: What if Microsoft told a manufacturer that their desktop (not server) hardware will run Windows 8 exclusively or they would never be able to buy Windows again. How many would cave in? All of them.
MS won't actually say that -- if only because they simply don't need to.
Margins are thin enough, (and for that matter, Branding strong enough) that not qualifying for co-marketing funds, "Windows 8 certified" logos and stickers, etc, makes for a pretty heavy hit on an OEM's bottom line.
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post
Its' only how MS compels defaulting to secure boot on OEM vendors the problem. The manufacturers may not give the choice to disable secure boot and they are not required to do so.
Would you run your Fedora/Red Hat host without ever recompiling a kernel ? How would you sign it ? If you can disable secure boot on OEM hardware, you can still use UEFI and work normally as nowadays.
Moreover, the OEM vendor is not obliged to allow the buyer to install his own keys in the UEFI stuff. If you fear rootkits that much, you could sign your kernel youself. It all depends on what options OEMs allow. We know that MS can influence them much, even politicians, so hardware manufacturers... !