Free Software Foundation Campaigning To Stop UEFI SecureBoot 355
hypnosec writes "The Free Software Foundation is on an offensive against restricted boot systems and is busy appealing for donations and pledge in the form of signatures in a bid to stop systems such as the UEFI SecureBoot from being adopted on a large-scale basis and becoming a norm in the future. The FSF, through an appeal on its website, is requesting users to sign a pledge titled 'Stand up for your freedom to install free software' that they won't be purchasing or recommending for purchase any such system that is SecureBoot enabled or some other form of restricted boot techniques. The FSF has managed to receive, as of this writing, over 41,000 signatures. Organizations like the Debian, Edoceo, Zando, Wreathe and many others have also showed their support for the campaign."
Straight jacket clipart (Score:2, Insightful)
I like the straight jacket clipart - It reminds me of how this is all just insanity.
Secure Boot is a good thing people! It means I can actually lock out my machines so they'll only boot linux and never windows!
Not realistic (Score:5, Insightful)
Richard, it's a nice sentiment, but what are the alternatives? Signing something saying I won't buy a UEFI-enabled system is basically saying I've doomed myself to the stone age. Every company is switching over. Nobody's going to go for that in the long term, anyone signing that is doing it just to make a statement. Eventually, their decrepit pre-UEFI system is going to fry, and they're going to go looking for a new one.
Rather than do something useless like a petition, which have a very low success rate on the internet, why not give us something useful: Like a list of motherboards and builds that do not have UEFI and sport otherwise modern hardware and features?
UEFI Signature Infrastructure (Score:5, Insightful)
If anything, the FSF should push to have how UEFI handles its signature database, and who handles signing, fixed so that it isn't so wholly Microsoft centric. You can tell because it puts key acquisition and installation in the hands of the system vendors, and the only one they'll independently acquire with any regularity is Microsoft's. And as a result everyone goes to them for signing.
If key handling were decentralized and standardized across all vendors, and adding your own key wasn't mutually exclusive with other keys (as it effectively is now,) then it probably wouldn't be such a problem. Hell, if they included a system-specific key installed on each platform and a hardcopy of the key, that would probably eliminate most of the concerns expressed here.
Unfortunately, doing this would likely require them becoming a promoter ($200,000) and contributing code out the ass to see it happen. As it stands the only OS vendor at that level in the UEFI Foundation is Microsoft. All the Linux vendors are Contributor or lower and can't possibly have a voice as loud as Microsoft. Net result a perfectly good security concept gets twisted into a Microsoft-specific hazard.
Re:Grub? (Score:3, Insightful)
Hard? No.
The problem is how inherently Microsoft-centric and user-hostile it is.
Re:Not realistic (Score:3, Insightful)
Which will trend to zero very rapidly. The problem, of course, is not UEFI but the Microsoft-centric architecture behind Secure Boot.
Re:Grub? (Score:5, Insightful)
It's not sufficient, because it doesn't solve the problem.
The problem is that MS's implementation of secure boot allows them to control what can and cannot boot on a device.
It is entirely at their discretion.
This is already in practice with the surface tablets
See Mathew Garrett's recent blog post
http://mjg59.dreamwidth.org/21189.html [dreamwidth.org]
As you can see, locking out other OSs is already in place for the Surface tablet, which is unable to boot any other system (even with the boot-loader shims done by RedHat, Ubuntu and the Linux foundation.)
Bread buttered (Score:5, Insightful)
Other options would be to leave a weakness in the system so that it is easily hacked and thus bypassed; this way they can meet the letter of Microsoft's law but not at all the spirit. And of course they don't need to make a hole, they know people will find a hole and they won't bother patching it. But I just don't see the manufacturers coming out and directly attracting Microsoft's rage. Plus companies know that all kinds of businesses will want to put a whole range of products on their systems from oddballs like DOS with many wanting XP, Vista, and Windows 7. It wasn't that long ago that I saw an ATM running OS/2. I suspect the guts of the ATM were newish.
But in the near term Microsoft is going to ask "Who farted?" and the various manufacturers are going to pretend that they didn't.
All that said, Microsoft's worst nightmare would be for a company to start releasing Motherboards/Machines with UEFI disabled as a feature and telling the world that smart discerning high-end customers buy systems without UEFI and that the drones buy what the suits at Microsoft tell them. What microsoft seems to forget that while computer nerds running things like Linux are not a significant market share in and of themselves they are who guides, or outright chooses what systems get picked. Minimally how many slashdoter's are involved by their families when they are picking machines. Without starting a religious war about my personal tastes I can say that when people around me are buying a system I give them a fairly narrow range of choices that if they stray from I won't take their "urgent" calls at 10pm when things are going wrong a month later. "Oh your poorly designed laptop that sucks cooling air in only from the bottom overheated when sitting on the sofa and now you need your data pulled from its carcass? How about no." So while people like us probably only represent 1% of the market we probably influence 30+% of the market. So if we don't like UEFI the manufacturers will soon find that we have a bigger vote than simplistic market surveys might otherwise suggest. So even if they totally cave to MS I suspect cracks will appear fairly quickly.
Re:Grub? (Score:2, Insightful)
Re:Grub? (Score:5, Insightful)
and when will it become relevant to you?
When they push Windows-only "secure boot" on laptops?
When they push Windows-only "secure boot" on servers?
When they push Windows-only "secure boot" on desktop machines?
When, exactly, will this obviously evil and anti-competitive move be of relevance to you?
Comment removed (Score:2, Insightful)
Re:Grub? (Score:3, Insightful)
Because then it won't keep those computers Windows-only.
SecureBoot is a great idea (Score:2, Insightful)
I support FSF in most things, but this is an important feature.
Rootkits are a very real problem, and SecureBoot is a good step towards eliminating them.
As long as there is some way for the user to disable it, I'm happy. Although it could be a bit tricky to achieve that without breaking the security model. Perhaps a hardware switch that can only be accessed by removing a few screws from the case...
Re:Grub? (Score:5, Insightful)
Someone wanting to try Linux to see what it's like will most definitely see that it's there.
Re:Grub? (Score:4, Insightful)
It's not sufficient because it leaves MS, a company known for it's extreme hatred of Free software, able to decide what will and will not boot on locked down SecureBoot devices. As a bonus, it sends a message to others who implement different lick-in schemes that they could be next on the boycott list.
Even on SecureBoot systems that aren't completely locked down, it establishes a very definite class system where only MS OSes and those that pay tribute to the king are first class citizens.
Not objecting suggests that it's OK for MS to further erode the meaning and value of property rights (other than their own, of course).
Re:Grub? (Score:4, Insightful)
I.e. any user that actually wants to tinker with the system.
Re:Grub? (Score:4, Insightful)
Not exactly, but you're on the right track. A hardware spec is kind of useless—hardware changes too fast. But a BIOS spec that supports open source would be worth defining, even if it's largely what we have right now. This would allow manufacturers to badge their machines as supporting Linux, which I would expect to be a key feature in the server hardware business, and a viable niche feature in desktops and laptops.
The long term outcome of this might actually be a serious win for the open source community, because it would create market differentiation where before we've been skating on vague hopes of compatibility.
Re:Grub? (Score:5, Insightful)
This is almost as simple as "write high quality open source drivers for all graphics chips". Let's do it!
Cut and Dried (Score:3, Insightful)
freetards
I know adding "tard" to the end of thinks magically makes you cleverer than they are. It doesn't
But I love the irony of you defending Microsoft an abusive multiple offending monopolist, a nasty company by every measure, has shenanigans, by recent favourite by this awful awful company is to hirer Mark Penn who unlike you is a professional shit slinger, who has has a department to match “strategic and special projects” http://www.nytimes.com/2012/12/15/technology/microsoft-battles-google-by-hiring-political-brawler-mark-penn.html?_r=0 [nytimes.com] what a nice man
Re:Economic Disobedience. (Score:2, Insightful)
or here's an idea, just dont buy them if your that worried about it
a thousand people buy UEFI motherboards and return them you just made the company think they sold 1000 UEFI when they look at the short term numbers... later on when they look at the returns it can be spun away with "well we did a driver or firmware update, see returns are down! the product is a sucess and quality is rising"
if you are so against this why in the hell would you give a company two +1 gold stars to sell?
geez, you can protest, but dont start by shooting your foot!
Re:Grub? (Score:4, Insightful)
1) SecureBoot has no bias towards Windows or OpenSource. The only "issue" is how to manage the certs.
2) SecureBoot was ratified over 4 years ago. Why did they take so long to complain?
3) SecureBoot is just a dumb system that makes sure the executing boot code has a trusted signature.
4) Linux seems to have bad relations with BIOS makers. Linux was having ACPI issues and eventually MS has to step in and help them by showing the work-aroundw that MS figured out because hardware manufactures not following the specs. MS learned that companies don't always follow specs.
I keep hearing extreme opinions from the OpenSource group. Am I missing something, because I just don't see it.
CoreBoot may be better and I don't mind that, but I want to hear a real argument against SecureBoot other than "omg, SecureBoot!"
Re:Grub? (Score:4, Insightful)
but I want to hear a real argument against SecureBoot other than "omg, SecureBoot!"
.Because I'm lazy, I'll just copy and paste a comment I made in another thread about TPM
Ever since TPM was created, we're always just a few bits and bytes away from having it leveraged against us, by them.
And by "us" I mean "the computer users."
By "them" I mean "the hardware manufacturers and software/media companies."
Example: The newest motherboards don't *need* the ability to disable trusted boot. Heck, it'd have been easier to not include it!
We're more or less at the mercy of a small number of companies and their design decisions.
Re:Grub? (Score:5, Insightful)
If you don't like it, disable it. You can also add your own certs. This applies to most motherboards and I can almost guarantee, all servers. Ever work in the real world? IT has A TON of custom boot code that won't work with default SecureBoot. Any hardware manufacturer that targets Servers/Enterprise/Enthusiast, WILL have at least a way to disable SecureBoot and at best a way to manage certs.
Commonly used tools in IT that WILL break based on your flawed understanding:
PXE Boot
Memtest
NSA Secure Erase Linux Distro
Bart PE
Norton Ghost
Firmware Updates
Win7
WinXP
Any hardware manufacturer that ruined the above would be committing business suicide.
If IT needs to manage, test, or fix it, SecureBoot will have to be configurable.
Re:Grub? (Score:5, Insightful)
Linux seems to have bad relations with BIOS makers.
It's the other way around. BIOS makers only implement whatever minimal subset of functionality they need to get Windows to boot, and they only test it on Windows. They don't support other systems at all.
In the past it's been even worse in EFI world. I don't know how UEFI is.
Re:Grub? (Score:5, Insightful)
Secure Boot has a definite bias towards Windows, Microsoft implemented the whole thing.
Because Microsoft is a UEFI promoter, no Linux companies have representation at that level.
It's all about the key distribution.
No, it has "relations" with BIOS makers that focus on Windows to a ridiculous degree thanks to their Monopoly on the desktop.
Linux implemented ACPI to spec. Microsoft's own ACPI compiler will accept ACPI code that breaks the spec but works for Windows. MS didn't have to "step in and help them," people had to reverse engineer and lie about being Windows to get the correct ACPI parameters because Microsoft has so fucked up the standard.
Re:Not realistic (Score:5, Insightful)
Maybe you can't imagine it, but RMS imagined it a decade and a half ago [gnu.org].
Much like 1984, it was scary then, but scarier now.
Re:UEFI Signature Infrastructure (Score:5, Insightful)
AND WHAT ABOUT ARM DEVICES?
If such restrictions are allowed to happen everywhere, they will inevitably end up happening everywhere. The situation is already completely unacceptable!
Re:Secure Boot is just a waste and fixes no proble (Score:5, Insightful)
Nevertheless, you did exactly that IMO. Please allow me to reiterate for the benefit of others:
Technical solutions as proposed above are irrelevant, because the fundamental problem here is that I SHOULDN'T HAVE TO FIND A GODDAMN EXPLOIT TO RUN MY OWN CODE ON MY OWN COMPUTER!
Re:Grub? (Score:4, Insightful)
Yes, it does have a bias against open source because it is difficult in practice for open source software to do this kind of signing, and because it actually allows manufacturers to control what gets installed on a system.
Note that on ARM, Microsoft uses SecureBoot to exclude other operating systems.
People have been complaining about it from the start.
And it happens to also give MIcrosoft a market advantage.
You make it sound like the Linux developers behaved unprofessionally and a Microsoft stepped in as an adult to bmake people behave properly.
In fact, manufacturers who don't follow the specs are unprofessional, and Microsoft likes such standards deviations because they help with lock-in.
Re:Not realistic (Score:4, Insightful)
Because if you need advanced knowledge of hardware engineering and specialist tools to install linux, then linux is dead.
Re:Grub? (Score:5, Insightful)
Microsoft has made it crystal clear that they can and will use UEFI to lock computers AGAINST their owners and to anti-competively lock out any possibility to load alternate operating systems when they do not have to worry about compatibility with older versions of Windows.
Why does this matter at all on ARM? Currently, the number one selling tablet manufacturer in the ARM space does this, and it aint Microsoft. Apple does everything in their power to prevent you from running Linux on iPad. And you know what? I have absolutely no problem with that, because if I want an unlocked tablet I can just go buy any of the dozens of varieties. Choice is good. Microsoft entering the space does not take that choice away, and it doesn't appear that it will any time soon.
x86 is an entirely different land. I contend that Microsoft's requirement has less to do about backwards compatibility and much much more to do with not running afoul of antritrust regulations. Honestly, Microsoft has nothing to worry about in the x86 space. Their biggest competitor here won't even allow their OS to be installed on generic x86 hardware. Their second biggest competitor is so far removed, they're hardly worth considering. If Linux were gaining any traction before this whole thing started, I would say "yeah, maybe they are getting worried" but Desktop Linux is holding strong at
So in fact, probably the *worst* thing Microsoft could do is lock down x86 bootloaders for anticompetitive reasons, because there is no real competition on the desktop to Windows. They would be inviting DOJ and EU oversight where this is no need to, as there is no credible threat. As it stands, Microsoft's biggest threat to their desktop marketshare is the dwindling PC market due to the locked down iPad.
Apple has sold 100 million iPads so far. Microsoft has sold a mere fraction of that in ARM tablets. In that sense, your capslock-infused rage seems misdirected, as Apple is the one leading the charge in locked down bootloaders on ARM devices. I personally have no problem with it, but it seems strange to me all this rage wasn't abound in 2010. Where was the FSF campaign when Apple was getting started with iPad? Or in 2006 with locked down iPhone? Now this practice is commonplace, and the target isn't even the correct company; even if they get Microsoft to completely change their practice, 99% of ARM tablets sold will still be locked down.