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."
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
Re:Not realistic (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 debugger or a soldering iron?
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: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.
Re:Concealed defect (Score:5, Informative)
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: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: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: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: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)
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.
This is one big giant NON-ISSUE... (Score:2, Informative)
And OMFG, you can turn off SecureBoot and/or make any key and/or signature whichever way you want it to be.
Precisely according to the UEFI spec as it requires.
MS has EVERY right to lock their own ARM's and such proucts down, and they will do exactly that.
But public mobo makers and third-party chinese ARM'ers and tablet'ers never will.
So this whole thing is TOTALLY and FALSELY blown out of proportion and only applies to people insisting on buying MS-Windows products, for which they'd never want to run any other OS in the first place... precisely because they're self-defined MS-Windows fans. So even they don't care about this.
Everyone else is simply not going to buy MS products.
It's that simple.
http://usa.asus.com/Motherboards/AMD_Socket_FM2/F2A85V_PRO/
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:Grub? (Score:2, Informative)
cause
Hasn't Ubuntu made GRUB a SecureBoot [h-online.com] boot loader? How isn't this sufficient?
read the parent ... geez
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: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?
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: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:UEFI Signature Infrastructure (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 is no problem.
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 they do not, so I don't know where you're getting this from. No motherboard manufacturer is going to lose any certification if they do not implement certificate management or Secure Boot disabling. The only reason any manufacturer is forced into being able to disable it right now is because there are existing versions of Windows people will want to install and ghosting and imaging tools. It's not being required by Microsoft.
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.
Utter bullshit. Nothing more can be said.
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.
I believe we've dealt with this untrue bullshit.
and adding your own key wasn't mutually exclusive with other keys (as it effectively is now,)
No idea what this nonsense means.
The level of FUD over Secure Boot, and it's non-relation to Windows 8, is astounding.
The level of bullshit we're getting from various people who desperately want to paint a picture of there not being a problem is astounding now, right down to plucking untruths out of thin air about what Microsoft does or does not require. The point here being that we are relying on Microsoft to tell us what can and cant be run on hardware.
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.