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."
Grub? (Score:5, Interesting)
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.)
Re: (Score:3, Funny)
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?
Re:Grub? (Score:5, Funny)
When they put Windows-only "secure boot" on Surfaces I didn't say anything because I didn't own a Surface. ... um, wait ...
When they put Windows-only "secure boot" on laptops I didn't say anything because I didn't own a laptop.
When they push Windows-only "secure boot" on servers I didn't say anything because I didn't own a server.
When they push Windows-only "secure boot" on desktop machines I didn't say anything because I didn't own a Desktop.
Boy, am I glad I own an iMac, iPad and iPhone
Re: (Score:2)
So how many laptops, servers and desktops does Microsoft produce?
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, Informative)
On systems where you can. Microsoft is already leveraging it on ARM against the owner of the device. This is completely unlike SSL.
Through a painful and convoluted process.
I have, have you? I deal with UEFI and vendor-to-vendor, board-to-board inconsistencies daily. IT hardware also costs many thousands more than consumer level hardware.
That's fine. All this has to do is hinder the adoption of other platforms and force everything through Microsoft. That's what they've always wanted, really.
Re: (Score:3)
Adding to list: Checkpoint / Truecrypt / insert disk encryption solution.
Re:Grub? (Score:5, Informative)
If you don't like it, disable it. You can also add your own certs.
Oh really?
Microsoft confirms UEFI fears, locks down ARM devices [softwarefreedom.org]
On x86 systems Microsoft needs computers to be compatible with older versions of Windows. On x86 systems the Microsoft Hardware Certification says that manufacturers must include an option to disable UEFI SecureBoot, and must allow the owner to load his own keys. However on systems with an ARM processor Microsoft doesn't need to worry about hardware being compatible with versions of Windows because there are no versions of Windows for ARM. On ARM systems Microsoft has mandated that MANUFACTURERS ARE FORBIDDEN TO INCLUDE ANY OPTION TO DISABLE UEFI SECUREBOOT. On ARM systems Microsoft has mandated that MANUFACTURERS ARE FORBIDDEN TO INCLUDE ANY POSSIBILITY OF OWNERS LOADING THEIR OWN KEYS.
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.
Currently ARM processors are primarily used in smartphones, however at least one manufacturer, Qualcomm, has announced they will be manufacturing ARM based PCs. Microsoft has mandated that owners of these PCs be denied any possibility of disabling the system and denied any possibility of loading your own keys.
Microsoft has announced the Windows 7 End Of Life date to be January 14, 2020. On that date Microsoft is no longer concerned with x86 computers being compatible with pre-UEFI operating systems. On that date Microsoft can drop the "Disable SecureBoot" legacy support. On that date there is every reason to expect Microsoft take their ARM-style no-legacy-support terms and impose them on all PC manufacturers.
Your "If you don't like it, disable it" is already false on some systems today, and there is good reason to suspect Microsoft may forbid it on all systems in a few years.
-
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.
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: (Score:2, Insightful)
Re: (Score:3, Insightful)
Because then it won't keep those computers Windows-only.
Re:Grub? (Score:4, Interesting)
Probably because people may still want to update their MOBO firmware without opening the case, same with installing a new OS.
It's one thing to do it on your machine at home. It's another to deploy 500 machines where you have to change a jumper on each one, and then change it back.
Re:Grub? (Score:5, Interesting)
What Ubuntu did was very unsatisfactory. You still cannot easily compile your own kernel. What that ex-RedHat guy did was a lot better since you can load anything you want as long as you confirm your choice on boot.
Here is what RMS should be doing instead of this petition which is going to get nowhere:
1. Restart work on coreboot
2. Make coreboot work with Windows and Linux as is
3. Convince more motherboard manufacturers to support coreboot
4. Ask Linux users on install if they want to backup their old BIOS and install coreboot as their default BIOS
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!
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: (Score:3, Insightful)
Hard? No.
The problem is how inherently Microsoft-centric and user-hostile it is.
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)
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:Grub? (Score:5, Informative)
A quick perusal of the UEFI members shows several Linux companies, and a number of hardware vendors that contribute to the Linux kernel, including Red Hat, IBM, Canonical, Cray, etc...
Re:Grub? (Score:5, Informative)
Because Microsoft is a UEFI promoter, no Linux companies have representation at that level.
A quick perusal of the UEFI members shows several Linux companies, and a number of hardware vendors that contribute to the Linux kernel, including Red Hat, IBM, Canonical, Cray, etc...
The post you replied and "corrected" is still accurate: only Microsoft has promoter status.
Re:Grub? (Score:5, Informative)
The article confuses Secure Boot and Restricted Boot. The linked FSF page clearly explains the difference.
Correct, and that's why the FSF is opposing Restricted Boot, not Secure Boot.
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:Grub? (Score:4, Informative)
1) Not inherently, no. But it does have a bias towards whatever the OEMs consider to be worth permitting. Obviously they will have to permit Windows. They *can* also permit GRUB and thus linux. If they want to. But they have no incentive to. It's hard enough getting driver support when so many manufacturers don't care about linux, this will just make it worse.
2) Secureboot was written as an optional feature of the UEFI spec four years ago, but there was no indication it was going to be used in non-server equipment until Microsoft announced they would be mandating it for Windows 8 OEM certification.
3) And there lies the problem. A trusted signature, but trusted by who? Not the equipment owner, but the equipment manufacturer.
4) Not so much 'bad relations' as 'no relations.' Outside of the server, Linux is a very niche OS. Its market share is measured in single-digit percentage. BIOS and hardware makers aren't so much hostile as apathetic - they see no reason to perform any testing under linux. So long as it works under Windows, which the vast majority of their customers use, it's considered done.
Re: (Score:3)
Linux wasn't "having ACPI issues". Microsoft's compiler for DSDTs didn't follow the standard that Microsoft created and published, and instead allowed erroneous ASL files to compile "successfully" even though they were horribly broken. Microsoft didn't come to the rescue here, "stepping in and showing the the work-around". They merely finally shared what they already knew, which was that their standar
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)
I.e. any user that actually wants to tinker with the system.
Re: (Score:3)
I.e. any user that actually wants to tinker with the system.
Doesn't Motherla...Fath...erm, Homeland Security say that type of suspicious activity makes you a likely pedoterroristinfringer? Will they even still issue passports and allow such people to leave the country anymore? /sarc
Strat
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!
Re: (Score:3)
Good thing that the FSF isn't against Secure Boot, but against implementations of it that don't allow the user to install free software OSs.
The threat is not the UEFI specification itself, but in how computer manufacturers choose to implement the boot restrictions.
Concealed defect (Score:3, Interesting)
It should be mandated that any restriction on a general purpose computer has to be stated clearly as such on the packing, otherwise it would a intentionally concealed defect.
Re: (Score:3)
Microsoft has been pretty clear about where UEFI is and the spec. They've been publishing papers, having websites, publishing books, giving talks, having videos on channel 9 for over a dozen years. You may disagree with them, but you can't accuse them of lack of disclosure.
Re: (Score:3)
i didnt have any problems booting from usb, although it was turned off by default, but i am not buying tablets and what not so they just going to loose money on me..
Anything that wants the "Made for Windows 8" sticker must ship with Secure Boot enabled, whether it's tablets, laptops, desktops or whatever. In practice that is any Win8 machine shipped from a major OEM, I'm guessing there's smaller stores who might install Win8 without enabling it but try it on any HP, Dell, Lenovo, Acer, Asus or any other big name machine shipping with Win8. Clearly the machine you tried isn't one of them, because you will find it is very, very hard to boot anything else...
Re:Concealed defect (Score:5, Informative)
Re:Concealed defect (Score:4, Informative)
Any x86 machine must also include the ability to turn secure boot off as well, according to ms win8 certification guidelines.
Yeah.... but they don't have to make it easy. Here's one tale [distrowatch.com] of the new future.
Re:Concealed defect (Score:5, Informative)
How is going into your motherboard's menu and disabling SecureBoot not easy?
Well you could read the link I just posted and find out, but in case you didn't getting into the BIOS wasn't obvious, he had to ignore a big red warning and after doing that he had to enable legacy boot, then a specific legacy device, then hold a secret button while rebooting to boot into it. If that's your understanding of easy, have you ever had the feeling other people perceive the world differently than you?
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?
Re: (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: (Score:3, Informative)
Which will trend to zero very rapidly.
If there is a demand there will be the offer. I will personally make m/boards for you that run whatever CPU you want and use whatever booting technology you want. If you insist I can use an entirely FPGA-based design that is 100% F/OSS. It may not be as good as an Intel CPU, but it will work.
OpenCores Projects [opencores.org]
The only way to block this is to make it illegal. But I cannot imagine how you can make microcontrollers illegal today. Would I need a license to own a debu
Re: (Score:3)
I will personally make m/boards for you that run whatever CPU you want (...) It may not be as good as an Intel CPU, but it will work.
So which is it, can you make me a LGA1155 socket motherboard or can't you? Or did you mean "any CPU you want, as long as it's an ancient and outdated one with open specs"?
Re:Not realistic (Score:4, Informative)
So which is it, can you make me a LGA1155 socket motherboard or can't you? Or did you mean "any CPU you want, as long as it's an ancient and outdated one with open specs"?
I can make any motherboard, with LGA1155 or any other socket - or with direct attachment of a CPU that is packaged as a BGA. Why not? It's not rocket science. The pin grid is 0.91 mm [intel.com], which is pretty generous today. My last BGA design involved a part with a 0.5 mm pitch; that was expensive. You may want to have Intel's reference designs, but they are obtainable today, and I have some for Atom (because that's what I need.) The DDRx routing will have to be carefully done, but that's also not an impossible task. I built 20A, 0.9V polyphase power supplies before, for a PowerPC project. There is hardly anything else that is notable.
But super-fast and super-hot motherboards of this kind are not what the digital rebel needs, IMO. He needs a small, lightweight, portable system - a tablet would be ideal, especially if it accepts external attachments like the monitor and USB. In reality all modern tablets are already suitable for the task. Communication, not data crunching, is the primary use of computers today - and any low-power system can do it just as well as a hot desktop.
Another reason for a digital rebel to not depend on Intel is that Intel can be asked (or forced) to make sure that their CPUs don't even start until they authenticate with the BIOS. You can build such a system already. For example, the CPU will refuse to access most of its address space until it issues a challenge to the BIOS (or TPM) and receives a correct response. The pre-auth mode would be just good enough to boot up, but if you need to run an OS you need the CPU unlocked. The private key to the CPU is in the mask, and the chances of getting to it are nearly zero.
In this situation it is essential to have an entirely free CPU design that is not constrained by artificial barriers. There are already lots of good CPUs that are ready for an FPGA. If there is a need, a SoC can be synthesized from existing RTL components and then manufactured as an ASIC. If that is illegal, use FPGA and program your own bitstream. Either way, computers are here to stay, and the only way to restrict access to them is not technical but social (like public beheading of underground engineers.)
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: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: (Score:2)
Re: (Score:2)
there will be enough interest from other companies to make systems outside their control.
Absolutely true. There is enough of a Linux presence in the server market to insure appropriate motherboards are available, and there will always be niche companies providing PC boards as well.
Re: (Score:2, Insightful)
Re: (Score:3)
Re: (Score:3)
What you are describing is what Microsoft is doing on x86 systems, pretty much.
Re: (Score:3)
What's wrong with supporting UEFI secureboot by default, but still providing users a BIOS option of disabling it for legacy/alternate OSes?
Because the definition of 'UEFI secureboot' is that you can't disable it. Disabling it would defeat the entire point of the Trusted Computing Module... which is to fuck you, the customer, over a barrel--er, I mean, provide the customer with the security and reliability they've come to expect in a modern operating system...
Re: (Score:3)
ways to obscure any path to freedom (Score:4, Informative)
....it doesn't do anyone any good to be spreading FUD! If you actually spent some time researching this topic, you will find that what you said isn't entirely true. Take the Dell Latitude 6430u that comes with Windows 8. You can disable secure boot in BIOS. I refer you to page 44 of its owners manual....
Well, I don't have a 6430u, but I just looked at page 44 of the owner's manual. It's written in gobbledygook language with double negatives and obscurity about what exactly is being enabled/disabled.
What's more, one of the controls 'described' on the page has a big warning that it's for one-time use only and "Activate and Disable options will permanently activate or disable the feature and no further changes will be allowed".
Maybe I could navigate that path to freedom if I had plenty of information from elsewhere, but that 'owner's-manual' page looks like it's exploiting complexity and obscurity to hinder the use of freedom.
It's unfair to call 'FUD' when information about available features has been obscured to the point of incomprehensibility.
-wb-
Re:Not realistic (Score:4, Interesting)
Conspiracy? Well, yes. This is *Microsoft* we're talking about here. The company convicted of antitrust violations by both US and EU regulators. The company which has a history of using every dirty trick in the book to get ahead, and which for many years waged a campaign against open source that seemed at times like some sort of personal vendetta. And the company which has now announced they are building a big 'Kill linux' button which they can press by revising a single clause in a contract. Based simply on the past actions of the company, it would seem a very bad idea to trust them with such power.
Re: (Score:3)
Is there really some conspiracy going on in which Microsoft will own the PC market with Intel as the -unofficial- official Microsoft hardware developer locking out all other OSes?
Yeah, pretty much.
Re: (Score:2)
The pledge does NOT demand non-UEFI systems. It demands:
To respect user freedom and truly protect user security, manufacturers must either allow computer owners to disable the boot restrictions, or provide a sure-fire way for them to install and run a free software operating system of their choice.
Where in there do you see UEFI being rejected? It says the signers will not buy a system that doesn't allow SecureBoot to be disabled by the owner or offer a reasonable alternative for loading any Free Software OS of the owner's choice.
Re: (Score:2)
No it doesn't. You don't want the key to be loadable at all you want it installed in hardware and unchangeable. You might want the OS to change, but you don't want to change how the OS is signed.
Re: (Score:3)
You are confusing Secure Boot with UEFI. UEFI is a necessary technical advancement, whereas Secure Boot is just vendor lock-in disguised as security.
Antitrust in EU? (Score:5, Informative)
The secure boot crap could be an antitrust issue.
German goverment has spoken abit about it
http://www.h-online.com/open/news/item/German-government-advocates-security-in-the-hands-of-users-1753715.html
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:UEFI Signature Infrastructure (Score:4, Informative)
fixed so that it isn't so wholly Microsoft centric
Good news, it's already fixed then!
So who decides what keys can be added to the bootloader? The end user, in the case of every x86 board. Microsoft requires any system vendor to allow end users to add their own keys (either directly, or by wiping the existing keys and requiring the user to add their own and microsofts back in). No user-modifiable Secure Boot, no Windows 8 for you. No windwos 8 certification? The manufacturer can do whatever they want, from locking down the loader to only one key of their choice, or not implementing secure boot at all/ Basically, the current state of affairs.
If key handling were decentralized
It is decentralised. It's so decentralised, that it's handled on a per-end-device basis. Because you manage the keys on your device by entering them.
and adding your own key wasn't mutually exclusive with other keys (as it effectively is now,)
No, it isn't. If you can add your own keys, you can add any keys.
The level of FUD over Secure Boot, and it's non-relation to Windows 8, is astounding.
Re:UEFI Signature Infrastructure (Score:4, Informative)
No, it isn't!
Theoretically, the BIOS vendor. Or if you make a Windows RT device, Microsoft. In practice, Microsoft.
Only through an irritating process that, in virtually every functional example is mutually exclusive with the Microsoft keys.
Microsoft. So benevolent. We'll see how long this lasts.
Not a single vendor would dare omit Windows 8 certification.
The "decentralization" is a joke. It's so decentralized that the only vendor with any guarantee of getting their key on the system is Microsoft. That's why EVERY LINUX VENDOR is going to Microsoft for a signature. Which, of course, such a supposedly vendor independent system shouldn't result in.
It's totally biased in Microsoft's favor and they know it.
Go show me one system that lets you add one with out forcing you to clear the Microsoft key? Or without having to rebuild the entire key database from scratch and installing it? It puts a nice high, high bar on being able to leverage that security and even more so for any system not approved by Microsoft to use it.
Please. Why is it that every time this subject comes up we're told to just, y'know, shut the fuck up and trust Microsoft?
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: (Score:3, Informative)
So who decides what keys can be added to the bootloader? The end user, in the case of every x86 board.
No they fucking don't. There will be one key in there, and that will allow you to boot Windows. How many motherboard manufacturers do you think are going to implement a whole key management system in their firmware that Windows does not require, you silly idiot?
However, I'm seeing this deliberate misiniformation coming up more and more, probably because it's all certain people have left to tell us that there i
Re:UEFI Signature Infrastructure (Score:4, Informative)
No they do not, so I don't know where you're getting this from.
The Windows 8 Hardware Certification requirements published by Microsoft [microsoft.com]. To quote the relevant section:
Mandatory. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following: It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), which puts the system into setup mode.
Mandatory. Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of PKpriv.
Re: (Score:3)
If the FSF were more responsible about these things, they could register with Microsoft as a signing authority and have their key be one of the default signing keys embedded in hardware. Then we have asian manufacturers, Microsoft and FSF and everyone is going to trust one of them.
Re: (Score:3)
Oh, I see. Microsoft is now a de facto authority without which we can't use a computer. Who gave them that prerogative?
Re: (Score:2)
Only if they abuse it, which is why Microsoft is treading carefully.
What about severs and web hosts / ECT (Score:4, Interesting)
What about severs and web hosts / ECT.
Windows 7 UEFI secure boot??? enterprise use is way to big for that to get locked out.
Where is HP and DELL in this???
Supermicro??
Tyan??
Linux in Medical Devices (do really want MS windows to be the only choice there??)
http://blogs.windriver.com/medical/2011/11/using-linux-in-medical-devices-what-developers-and-manufacturers-need-to-know.html [windriver.com]
Re: (Score:3)
You can easily disable secure boot for all but the ARM tablets (tablets are rarely open to begin with).
The only way secure boot will ever be a serious problem is if Microsoft actually grows the balls to force OEMs to enable secure boot and force it locked on at all times. To be honest, I'm all for doom and gloom but I just don't see this ever happening. The legal jungle gym Microsoft would thrust themselves into would be so ridiculous that it would make the monopoly charges over Internet Explorer look like
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.
windows 8 stink as well hurts ms a 7 boot loader (Score:2)
windows 8 stink as well hurts ms a 7 boot loader will help alot of this may be DOA as it will be a hard sell with a MB that can only boot windows 8
Re: (Score:2)
Desktop motherboard manufacturers know that in the past and in the present that following the dictates of Microsoft is how to survive. But those days are mostly over. I doubt any of the MB manufacturers are going to stand up and fart in Microsoft's face and say NO. But I suspect they know the trend is moving away from Microsoft and with the Linux noises that companies like Valve are making that Microsoft will only get weaker. Thus they will probably pretend to put UEFI onto the motherboard but make it really really easy for anyone with the capability to install linux to turn it off.
Whether Microsoft is experiencing competition from Macs or iPads or Android tablets doesn't matter, the only thing is how many repurpose a machine that came with Windows installed. That market share is still 1% and more importantly the motherboard manufacturers don't care - they got their sale back when it had Windows on it. Hell if Linux fans have to buy a different motherboard to run Linux on it, they get double sales.
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.
And Microsoft will, if they're kind, sign MS-DOS, XP, Vista, Windows 7 and anything else
Re: (Score:2)
what about SBC cpu / chipset cards with a backplan / MB with all the pci-e slots on them.
Secure Boot is just a waste and fixes no problem. (Score:5, Interesting)
Let's put on our thinking caps folks. Return Oriented Programing is an exploit engineering technique that uses the existing signed and/or encrypted code to create the exploit code. That means Secure Boot is defenseless to stop this type of exploit. If the application or OS code has mistakes in it then a function pointer on the stack, or in the heap (read/write memory) can be overwritten and be used by exploits via return oriented programming, and SecureBoot won't help one bit -- The code that's running is signed and/or encrypted. So if the Application or OS code isn't secure (which it won't be) then SecureBoot is pointless. What that? It won't be able to infect a boot sector? Well, if you've got malicious code running on your system then there exists an exploit vector that cane simply be re-exploited next time you boot up. See? Pointless.
Ah, but what if the Application and OS code could be written to be secure against stack smashing and undesired code pointer manipulations? Well then, there wouldn't be any exploit vectors that you needed SecureBoot to protect you against. See? Pointless.
Well, I say "Pointless", but what I mean is useless from an end user perspective. I don't mean to gloss over the only real use SecureBoot has: To prevent you from installing your own OSs and Applications, and having control over your own computers.
Re: (Score:2)
So if the Application or OS code isn't secure (which it won't be) then SecureBoot is pointless.
SecureBoot is about booting securely, anything after the boot is up to the OS to handle.
I hear the OS/Apps can be by exploited, so no point in using a firewall.
SecureBoot can protect you against against physical access.
I am not saying SecureBoot is the best implementation, but the basic idea of it is good. We need some form of DRM system that the user can manage to protect their system from physical access or general boot exploits.
It depends on who controls the keys (Score:3)
I was going to mod you up but then I read your final sentence:
We need some form of DRM system that the user can manage to protect their system from physical access or general boot exploits.
Secure Boot is *not* (necessarily) DRM. It all comes down to who controls the keys. If the owner controls the keys then Secure Boot is a good thing. If the owner does not control the keys then Secure Boot is a form of DRM and it is a bad thing. If the user/owner has control and can use Secure Boot to protect their system then it is not DRM.
The big danger of Secure Boot is that, unlike conventional DRM, it can be actually be made secure.
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!
$50 Minimum Donation (Score:2)
I'm supportive of this campaign, but I'm turned off by their $50.00 USD minimum for individual donations. I don't have a lot of spare income, but will often donate $5 or $10 to what I think is a good cause. I've always assumed that if enough people do likewise, my small contribution will add up to something significant.
The only reason I can think of to justify a minimum contribution amount would be if they are issuing receipts for tax deductions and there is some cost involved in doing so. Even if that case
Re: (Score:3)
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 [nytimes.com]
we abide by U.S. and foreign tax laws (Score:3)
posting a inflammatory rant off topic doesnt make you look any smarter. I am not defending microsoft, I just happen to notice every time FSF gets worked up there's always a required "donation".
How you magically tie this in to being a YAY GO MS post is beyond me, and your ongoing blather about some nytimes writer is pointless in context
I like you Osgeld, I admire a man prepared to defend a Mega-corporation fearlessly. I love the way you tried so hard to create something nefarious against an organisation that relies on donations...asking for Donations like Freebsd and Wikipedia, or lets be honest these people produce something of value, Richard Stallman is who he is because he created a compiler that produced faster binaries than the competition at a time when they cost thousands of dollors...and gave it away...and yet your painting this o
Re: (Score:3)
see right there is the problem, some odd reason many of you freedom fighters see it as black and white, if I am not 100% dedicated to your cause then I am appalling and hurtful to your cause
my argument though ... is your cause so weak it cant take one simple observation without going off on a witch hunt? (which you have for hours now)
you have offered no evidence why I should actually care, and yet shown so much of why I don't want to be associated with your kind
good day
I have no problem with UEFI as long as.... (Score:3)
As for OS's that won't run with UEFI disabled. I have no use for them.
Re:I have no problem with UEFI as long as.... (Score:5, Informative)
1) Windows 8 runs perfectly fine without Secure Boot
2) For a manufacturer to provide a computer with Windows 8 pre-installed, or to label their product as compatible with Windows 8, they MUST allow end-user modification of the bootloader keys. If they don't, then no Windows 8 for them, as per MS' own hard certification requirements.
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: (Score:3)
Rootkits are a very real problem, and SecureBoot is a good step towards eliminating them.
In Windows. So how about Microsoft just allows us users of other operating systems to turn the "feature" off and just leave us the hell alone?
Oh yeah, because then they can't squash their competition so easily--they would be forced to continue competing on fair terms like performance, features, software, and other real factors. When they release a dud like Windows ME, Vista, or Win8/RT, their customers will be unable install an alternative operating system on it, or even a different version of Windows. P
We, the FSF, like Secure Boot (Score:5, Interesting)
Joshua Gay
Licensing & Compliance Manager
Free Software Foundation
Re: (Score:3)
A signer for what? For UEFI?
First, Microsoft refuses to sign anything under the GPL. Second, the FSF would have to get every motherboard vendor to accept their key, but at the same time anything signed and released under the GPLv3 would need to include said key. Not that the motherboard vendors would listen to the FSF since their goal is Microsoft compliance and nothing else.
This need
Comment removed (Score:3)
Re:i wont buy hardware like that (Score:5, Funny)
Re: (Score:2)
Obama says I am not a tech guy and free markets are good.
Re: (Score:2)
Yes, saying they don't want my measly $20 or $40 doesn't really endear them to me. The cause is good, but I will look for other ways to support it where my meager contribution would actually be appreciated.
What do distros where signing isn't an option do? I would think that a good portion of LFS and Gentoo users chose it because it gives them control over what they put on their systems, not because of any perceived speed benefits.
Re: (Score:2)
The user is able to edit the keys database on x86 based and not arm based uefi implementations.
You can put the microsoft keys on a black list if you want and it will not boot.
41,000 signatures! (Score:2)
41,000 isn't even a small drop in the bucked
Lets compare it so something more tangible and relevant, where are the 41,000 requesting this feature...with this particular solution?
Steve Jobs had a neckbeard (Score:2)
neckbeards, unite!
I like the way that ad hominem works better than rational discussion. The sad fact is I was watching an article a video about replacing Ballmer...and the main reason given was he wasn't telegenic (I had to look it up). Have we really reached a stage where what we look like is more important than what we are. I do think you would benefit a little more if you looked at he issues in hand.
Re: (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, bu
Re: (Score:3)
So basically you are upset that you use hardware from shitty companies who don't follow the spec (in both examples you use) and are blaming something ENTIRELY UNRELATED on secure boot.
You then proceed to say something silly about relying onBIOS makers to give you something back as a bad thing when you would have no functioning computer at all if not for those same bios makers?
You are a joke. You clearly don't see how silly you make yourself look. You rely on those bios makers anyway and have for y