SUSE Slowly Shows UEFI Secure Boot Plan
itwbennett writes "One blog post at a time, SUSE is revealing its plan for getting SUSE Linux Enterprise Server (SLES) to boot on machines with UEFI Secure Boot. The short version: 'For now, it seems, SLES will implement an approach similar to that used by Fedora,' writes Brian Proffitt. '[Director of the SUSE Linux Enterprise Olaf] Kirch's first blog entry on Tuesday merely introduced the problem of UEFI Secure Boot. Today's blog only specified the use of the shim bootloader.' Just dying to know what's next? Tune in to the SUSE blog."
Run!
does UEFI secure boot bring any value to users or only to our corporate masters?
“Common sense is not so common.” — Voltaire
But most of all: Fuck trolls.
How long until firmware yays or nays the OS your trying to install? Windows 8 Tablet is just a baby step into that future...
Seeing how Microsoft is currently pissing off Hardware vendors (and surface isn't even out, so I guess the worst is still to come), I sure hope the first of those two options will come to pass. I'm not sure if I dare be optimistic, this whole thing crazy to begin with. I mean, who the fuck is Microsoft's Windows Logo Certification anyway, and why are they putting their penis in my soup? Waiter?!?!
Don't knock it till you tried it. I mean, people have no qualms talking about Ubuntu with a straight face here... wtf is up with that?! OpenSUSE is as awesome as they can be in a crappy world.
running on Chromebooks. All source is there. You can download it and study it and build something good on it.
So what are the "open source OS companies" putting all their effort into? Satisfying a closed, proprietary system designed to lock users in. Very disappointing.
I don't get it.
So after several decades of fighting for free software (and computer freedom in general), all these distributions are just going to roll over on command for Microsoft?
You know what? Anyone who goes along with this UEFI bullshit is a fucking traitor, a coward, and a goddam disgrace to the open source community.
Playing along here is NOT THE ANSWER. Doing NOTHING is the only appropriate course of action. Why? Simple, because then you're shifting the problem to the hardware manufactures who are going to get shafted in sales because their stuff doesn't run Linux OOTB (not without configuring UEFI first). They're going to realize this mighty fast and either produce cheaper "Linux" versions of their motherboards without UEFI restrictions (or even better, without UEFI at all)- or just drop the whole Secure Boot thing all together.
Again, playing along with this mockery is the WORST POSSIBLE THING anyone could do. It's like letting the Germans into your country during 1945 because they promised they'd only ask for your papers when you're entering or leaving your own city. How long do you think it'll be until they have the same guards stationed everywhere? Train stations, food stores, clothe stores... How long before you're walking down the street in your own community and you're getting stopped for papers, only blocks away from your house?
I'm sick and tired of people saying "it's only the bootloader man, chill". Yeah, it might be today. What about tomorrow, when they drop the ability to manually disable Secure Boot permanently? What then, huh? Well, then Microsoft has the power to revoke your keys and doom your operating system to death. After everything Linux has been for, after everything Linux has stood for- why the fuck would you EVER want to give Microsoft this power?
Fedora, Ubuntu, and SUSE can kiss my fucking ass. All these distributions are a disgrace. A total fucking disgrace. The least they could do is show some goddam balls, stand up and say "No, we're not going to be your bitch". So what if your users have to manually disable Secure Boot for now. At least then they'll realize what is going on here and you might actually educate a few of them as to why CLOSED PLATFORMS ARE BAD.
-AC
I'm used to a little bit of healthy paranoia here, but the amount of FUD and flat-out misinformation in Slashdot's UEFI reporting is frankly astonishing. Let's get a few things straight.
UEFI is not a Microsoft technology. It is an industry standard intended intended to replace the archaic x86 BIOS. Microsoft participated in the standard, as did Slashdot favorites Red Hat, Canonical, IBM, and AMD. You can freely download the full specification from the uefi.org website.
Secure Boot is part of the larger UEFI specification. See section 27 for the technical details. Of particular interest to Slashdot readers will be section 27.7 which describes the key update mechanism.
Secure Boot is intended to solve the real-world security problem of boot-time malware. No operating system can defend against malware at boot-time; this would be equivalent to defending against the hardware itself. If it helps, imagine how you would defeat a keylogger embedded in your keyboard.
Secure Boot uses code-signing to defeat boot-time malware. This is the optimal solution and should be full-proof provided (1) the machine is physically secured, and (2) the private keys are secure. (I am defining "full-proof" here to mean the keys and hashes involved are adequately difficuly to brute-force with modern hardware. I am also explicitly discounting scenarios outside of UEFI's area-of-responsibility, such as vulnerabilities in the operating system's signed image.)
For some real irony, see the Slashdot article Windows 8 Secure Boot Defeated. Both the headline and much of the discussion in this article were flat-out wrong. The exploit in question targetted the legacy BIOS and MBR. This is exactly the problem that Secure Boot addresses, and it reinforces the need for this technology.
Secure Boot is not a DRM scheme, nor it is explicitly a tool for Microsoft lock-in. Remember that on x86 platforms, the end-user can edit the key database, and can disable Secure Boot entirely. I concur that Microsoft's treatment of ARM is a dick move, but is also typical for other vendors in that market segment. In either case, remember that Secure Boot is a logical solution to a real-world problem affecting all operating systems, and evaluate it on this merit first.
Just because the technology can be mis-used is no reason to completely boycott it. For my part, I intend to use Secure Boot when it becomes generally available, but only buy parts that allow me to edit the key database.
Links:
UEFI membership list: http://www.uefi.org/join/list/
UEFI specification: http://www.uefi.org/specs/agreement
Fuck trolls like you, moron. SUSE has nothing to Novell after Attachmate and Microsoft is committing to open source a lot, you undercomplete idiot!
Disabling secure boot, or manually installing a new vendor key, may be easy enough for us. But it adds another large hurdle for joe average user to try another operating system. That alone is reason enough to complain about it and object to it.
As it stands now the UEFI standard doesn't specify how the user can install a custom trusted key.
IMHO, hardware vendors should be required to leave the trusted key set empty from the factory. UEFI should then have a standard prompt to enable secure boot and install a key found on bootable media. If Microsoft were forced to guide the user through the same process that a linux installation would require, this process would get the attention it deserves to make it as user friendly and standardised as possible.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
It is sad that the Linux distributions are bending over so easily, together they might have been a force to be reckoned with... they better f-well not say "we could not have known..." in a few years time, seriously.
What the linux distro distributors have failed to do, the Linux Kernel folks should pick up the slack
Do not forget, there exists a spokeperson for Linux - Linus Torvalds
It's up to Mr. Torvalds to decide which direction Linux should proceed on this UEFI issue
Muchas Gracias, Señor Edward Snowden !
Maybe this is more of an issue with machines that have Windows pre-installed but I'm upgrading my motherboard and it has UEFI and the gentoo wiki doesn't make it seem so bad.
http://en.gentoo-wiki.com/wiki/UEFI
Laptops, of course are going to be an issue.
-- Its survival of the fittest...and we got the fucking guns!!!
Don't knock it till you tried it.
Guess what, I'm servicing SuSE in corporate environment. We're moving on, though. To Debian.
Upward mobility is a slippery slope - the higher you climb the more you show your ass.
Microsoft is committing to open source
Beware of Greeks bearing gifts
Upward mobility is a slippery slope - the higher you climb the more you show your ass.
Oh ok. So it's all good and fine on x86 systems. Lets completely ignore the amount of "computing devices" which are today being released on an ARM platform rather than x86.
I was looking forward to UEFI and ARM devices with a proper BIOS and a way to run various operating systems on them. I mean we currently have people running Android on iPhones and on PCs, we have small embedded ARM devices running Linux, but who cares about that when in the future the vast majority of ARM devices will be locked to Windows only at the bootloader level.
I mean Linux is such a small market share so screw em whenever we make a change that may affect them in the slightest bit. They shouldn't have a say in this Windows only world right?
I for one look forward to a future where mega corporations are able to control my very thoughts, that way I'll never possibly think of doing something unauthorised with a device I own... err I mean contracted to use.
But it is the ROOT of the chain of trust that is wrong. Instead of some corporation being the root of trust, the owner of the computer should be that root of trust. A proper UEFI boot system needs to include an option in the BIOS to add ANY boot partition (such as the new OS you just installed) as trusted. That same menu should allow you to delete trust for any, as well. When you add trust, it scans the image to be loaded, calculates a checksum, and stores it into an area of Flash memory that can only be written to during the BIOS run from a hard reset or power cycle. Once BIOS runs an OS, that area of Flash is write protected, or maybe even completely out of addressable space so no OS can reflash (all of BIOS should be like this, of course).
There is NO need for Microsoft or even the manufacturers to sign stuff. They are doing this WRONG. Of course, they chose to do this wrong so they would be in control.
now we need to go OSS in diesel cars