Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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."

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.)

When they put Windows-only "secure boot" on Surfaces I didn't say anything because I didn't own a Surface.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... um, wait...

SecureBoot is a standard that allows the end user to limit their system to only booting signed code. Next thing you'll be complaining about SSL and how it can also limit the end user from working with untrusted sources.

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.

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.

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.

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.

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

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).

MS has pulled some pretty underhanded things, so I don't fully trust them, but this is what I'm seeing.

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!"

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.

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.

2) SecureBoot was ratified over 4 years ago. Why did they take so long to complain?

Because Microsoft is a UEFI promoter, no Linux companies have representation at that level.

3) SecureBoot is just a dumb system that makes sure the executing boot code has a trusted signature.

It's all about the key distribution.

4) Linux seems to have bad relations with BIOS makers.

No, it has "relations" with BIOS makers that focus on Windows to a ridiculous degree thanks to their Monopoly on the desktop.

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.

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.

1) SecureBoot has no bias towards Windows or OpenSource. The only "issue" is how to manage the certs.

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.

2) SecureBoot was ratified over 4 years ago. Why did they take so long to complain?

People have been complaining about it from the start.

3) SecureBoot is just a dumb system that makes sure the executing boot code has a trusted signature.

And it happens to also give MIcrosoft a market advantage.

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.

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.

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.

" Linux was having ACPI issues and eventually MS has to step in and help them by showing the work-around"

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

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

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.

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...

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?

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?

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.

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.)

I don't see your predictions with the same surety you do. Having MS in the control of what runs in all general purpose computers is not good for anybody but to Microsoft. Even if manages to push it at first, there will be enough interest from other companies to make systems outside their control.

What's wrong with supporting UEFI secureboot by default, but still providing users a BIOS option of disabling it for legacy/alternate OSes? Secureboot should be an added feature, not a forced requirement for motherboards. If Microsoft Windows X is require secureboot, the user can toggle secureboot on. Why does this have to be such a big deal?

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

MS, as all big companies, wants control, at least enough of it to eliminate any possibility of competition. It cannot force total control out of the blue, but it can try to erode resistance with time, pushing it bit by bit. The current UEFI implementation is just one more attempt to do exactly this.

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...

I'm not saying this topic isn't cause for some eyebrow raising, but 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 (PDF format) [dell.com]. Not only that, but TPM can be disabled along with the options of booting via legacy ROM (BIOS).

....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.

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.

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.

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.

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.

Theoretically, the BIOS vendor. Or if you make a Windows RT device, Microsoft. In practice, Microsoft.

The end user, in the case of every x86 board.

Only through an irritating process that, in virtually every functional example is mutually exclusive with the Microsoft keys.

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.

Microsoft. So benevolent. We'll see how long this lasts.

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.

Not a single vendor would dare omit Windows 8 certification.

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.

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.

No, it isn't. If you can add your own keys, you can add any keys.

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.

FUD

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?

I'm sorry, but this load of bull and misiniformation is going to have to be smacked down - hard.

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

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.

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.

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

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. So I suspect that the motherboards will soon come with UEFI enabled by default (maybe) but that you can either go into the bios and turn it off or short a jumper.

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.

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.

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.

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.

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.

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

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]

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

Bullshit.
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.

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...

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

This post is a little misleading. We think Secure Boot is OK [fsf.org] so long as computer makers implement it in a way that it still allows a user to control his or her own computer. What we don't want computer makers to do is implement UEFI in such a way that a user is unable to sign their own software (e.g. bootloader) AND they are unable to turn Secure Boot off -- we call such an implementation Restricted Boot (because we want to emphasize that it instead of providing security, it exists to restrict a user from controlling his or her own device). We hope that computer makers will choose to implement UEFI in a way that truly does provide security and control, and many are implementing Secure Boot in this way.

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.

in the Apple case offering a Enterprise SDK server config that people can run the iOS devices against.

it always has been: in the community.when they kicked around ACPI as a standard that intentionally didnt 'just work' on linux, we made it work.when dvd was a big-two game, the community came together again and made that work as wellwhen windows mandated the wholly superfluous 'windows' key we simply coopted it to our own desires. Awesomewm, for example.absolutely tireless effort was spent making sure every iteration of broken windows continued to be supported as a dual-boot option in Grub.

We engineered solutions for their docs, excels, and even the very programs that ran only on windows in the form of Wine.secure boot could come, and against it will stand a threat that microsoft has consistently underestimated: Hackers. We cannot be lobbied against, or coded around. there is no NDA we recognize or understand. Im not saying UEFI shouldnt be stopped, just that if and when it comes, we have been ready since the dawn of the kernel to make it do what we want it to do.

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.

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.

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?