The Linux Foundation's UEFI Secure Boot Pre-Bootloader Delayed

hypnosec writes "The Linux Foundation's plans for releasing a signed pre-bootloader that will enable users to install Linux alongside Windows 8 systems with UEFI have been reportedly delayed. The Foundation proposed a signed pre-bootloader that will chain-load a bootloader which, in turn, will boot the desired operating system, thus keeping Linux installations for novice users as simple as it was before. Further, this particular component is meant for small-time Linux distros which otherwise wouldn't have the required expertise or resources to develop their own system to tackle the secure boot issue. This was going as per plans up until Linux kernel maintainer James Bottomley disclosed that he has been having rather bizarre experiences with Microsoft sysdev centre. Bottomley said, 'The first time I sent the loader through, it got stuck (it still is, actually). So I sent another one through after a week or so. That actually produced a download, which I've verified is signed (by the MS UEFI key) and works, but now the Microsoft sysdev people claim it was "improperly" signed and we have to wait for them to sort it out. I've pulled the binary apart, and I think the problem is that it's not signed with a LF [Linux Foundation] specific key, it's signed by a generic one rooted in the UEFI key. I'm not sure how long it will take MS to get their act together but I'm hoping its only a few days." Update: 11/21 14:22 GMT by U L : See the Original weblog post, and one interesting tidbit: Microsoft banned bootloaders licensed under the GPLv3 and "similar open source licenses."

Comments

Ehh?

[Anonymous Coward]

How long until crackers will be able to install this loader to load their virtual machine that will run a compromised Windows 8?

Somebody should sue Microsoft anyway

[Anonymous Coward]

At least in Europe they'd succeed.

Re:Somebody should sue Microsoft anyway

[EdZ]

What for?

It's a requirement as part of the Windows 8 hardware certification (applies not just to laptops and desktops, but to anything that the manufacturer wants to put the 'works with Windows 8' logo on, e.g. motherboards) that:
a) You be able to disable secure boot
b) You be able to enter your own keys into secure boot (either through adding them to the existing keychain, or wiping the keychain and adding keys)

Here's the relevant legalese from MS:

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.

Re:Somebody should sue Microsoft anyway

[Anonymous Coward]

... And on ARM devices exactly the opposite is true, the platform MUST not allow the user to disable Secure Boot or add additional keys.

Re:Somebody should sue Microsoft anyway

[psm321]

But that fact is inconvenient for those that support this slow intrusion into control of our hardware, so they will conveniently neglect to mention it (or the fact that this concession meant to spur adoption will almost certainly disappear once secure boot is fully entrenched)

Re:Somebody should sue Microsoft anyway

[Anonymous Coward]

The problem is that MS doesn't have a monopoly in the ARM world, thus there are no grounds for a lawsuit.

Now if MS manages to upset the market and kill off iOS and Android then you will have a point, but until then...

Re:Somebody should sue Microsoft anyway

[SampleFish]

Why is MS the one signing the bootloader in the first place? Shouldn't there be a neutral root authority like there is for any other certificate in the world? To make Linux developers ask Microsoft to sign their bootloaders sounds like a very clear conflict of interest.

Re:Somebody should sue Microsoft anyway

[shutdown -p now]

ARM devices don't run Windows 8 - they run Windows RT. GGP was specifically talking about Win8.

I don't recall any single Slashdot story on the subject where the difference between Intel and ARM devices with respect to Secure Boot was not brought up.

Not surprised

[gagol]

Somehow, thay can sign town of apps and drivers on a regular basis, but signing teeny tiny code for FSF got screwed... It only validate, in my opinion, this whole secure boot shit was meant to give alternative OS a hard time.

Re:Not surprised

[Ynot_82]

town of apps

So that's why they called their UI Metro.
Always wondered about that

Re:Not surprised

[gagol]

Good catch, typing in bed is never optimal... I meant "tons" for the record.

Re:Not surprised

[wonkey_monkey]

Good catch, typing in bed is never optimal...

You're holding it wr- nevermind.

Re:Not surprised

[mwvdlee]

Something about contributing to stupidity instead of malice.
I'm guessing since MS has to sign these bootloaders for relatively few cases, they're doing it atleast part manually.

Re:Not surprised

[Anonymous Coward]

town of apps

So that's why they called their UI Metro.
Always wondered about that

They certainly let the UI designers "go to town" on Metro (or whatever it's called now ... Bob 2012?)

Re:Not surprised

[Anonymous Coward]

Attributing?

Re:Not surprised

[l3v1]

"Something about contributing to stupidity instead of malice."

Well, there's a part of an edifying story going something like: - How old are you, my prince? - 25 (*) - And you still believe in fairytales?

(*) Number doesn't really matter, but reflects age greater than childhood.

Re:Not surprised

[sunderland56]

Signing of apps and signing of drivers is handled by completely different people; I would imagine that signing of boot loaders is another, new group. This may well be their very first submission, so things may not go exactly as planned.

Re:Not surprised

[mwvdlee]

Indeed, appollogizemisations.

Re:Not surprised

[Chrisq]

Somehow, thay can sign town of apps and drivers on a regular basis, but signing teeny tiny code for FSF got screwed... It only validate, in my opinion, this whole secure boot shit was meant to give alternative OS a hard time.

Actually I'm generally not a Microsoft fan but I'd reserve judgement on this. Signing boot-loaders to be authorised by the hardware is likely to be a different procedure and done by different people to signing drivers. They probably have not done this often and when they have it will have been mostly with their own generic key. I can easily put this down to mistakes, and if they sort it out promptly I see no reason to put it down to ill will.

Re:Not surprised

[mcgrew]

Something about contributing to stupidity instead of malice.

You're referring to Hanlon's Razor, which says never attribute to malice that which can be explained by stupidity.

However, mcgrew's razor trumps Hanlon's: Never attribute to stupidity that which can be explained by greedy self-interest.

Re:Not surprised

[idontgno]

Interesting: a hierarchy of motivations.

Amoral greed > stupidity or apathy > disintrested evil

Of course, much greed is evil, or is described as such. So Hanlon's Razor appears to be contradicted in many of these "market cases".

Re:Not surprised

[camperdave]

Why should Microsoft be involved though? Surely which bootloader gets installed is between me and my motherboard, no?

Re:Not surprised

[Anonymous Coward]

Somehow, thay can sign town of apps and drivers on a regular basis, but signing teeny tiny code for FSF got screwed... It only validate, in my opinion, this whole secure boot shit was meant to give alternative OS a hard time.

No kidding, they're just bending over by playing along with this crap.

Present user test?

[SuricouRaven]

Does that mean the user has to actually be present to press a key? That renders secure boot unuseable on remote-admined or unattended servers, the very place you would most want to have a secure boot chain.

Re:Present user test?

[jimicus]

Likely to be much less of an issue on proper server hardware; most server vendors know full well a significant amount of the hardware they shift will never run Windows.

Re:Present user test?

[avarus]

One would assume that the administrator of a headless server is clued up enough to load their own key into UEFI and doesn't need this workaround in any case.

TIM

Re:Present user test?

[Skal Tura]

Automation is key here, if it takes a manual step to do that, you can forget it.

Re:Present user test?

[gweihir]

Easily rectified. If you have a "real" server, use IPMI. Otherwise something like a teensy or a programmable mouse.

Re:Present user test?

[tapanitarvainen]

Does that mean the user has to actually be present to press a key? That renders secure boot unuseable on remote-admined or unattended servers, the very place you would most want to have a secure boot chain.

User only needs to press a key during initial installation, after that it should boot unattended just fine: "If the user gives permission, the signature will be installed and loader.efi will then boot up without any present user tests on all subsequent occasions even after the platform is placed back into secure boot mode." http://www.linuxfoundation.org/news-media/blogs/browse/2012/10/linux-foundation-uefi-secure-boot-system-open-source

Re:Present user test?

[SuricouRaven]

A lot of servers aren't 'proper' server hardware. Sometimes consumer-grade is good enough, espicially when it's so much cheaper you can have redundent everything. Think clusters.

Re:Present user test?

[serviscope_minor]

A lot of servers aren't 'proper' server hardware. Sometimes consumer-grade is good enough, espicially when it's so much cheaper you can have redundent everything. Think clusters.

Even more than that. If you have a UPS and the server is never switched off, then power supplies and fans tend to last for ever if they are of an even remotely reasonable quality. The thing that kills power supplies most is heat death from inadequate cooling, and tedundant powersupplies don't help much there since they will both be much more likely to survive.

If you go for AMD, you can load the consumer boards up with ECC RAM and have a very reliable piece of kit.

If you're going to lose millions per hour if the server goes down, it's worth hedging with redundant power supplies. If it's some small departmental server for which there isn't really a budget, then the consumer parts fit the bill very well.

Re:Present user test?

[camperdave]

Does that mean the user has to actually be present to press a key? That renders secure boot unuseable on remote-admined or unattended servers, the very place you would most want to have a secure boot chain.

User only needs to press a key during initial installation, after that it should boot unattended just fine: "If the user gives permission, the signature will be installed and loader.efi will then boot up without any present user tests on all subsequent occasions even after the platform is placed back into secure boot mode." http://www.linuxfoundation.org/news-media/blogs/browse/2012/10/linux-foundation-uefi-secure-boot-system-open-source

So I won't have to go around to every classroom and every pc and click OK when I do my monthly wipe and reimage?

Re:Present user test?

[EmagGeek]

Why the fuck would you buy a boot-locked Wintel 8 PC to use for a linux server or remote application? Why wouldn't you just build your own server like the rest of us?

Re:Present user test?

[tapanitarvainen]

User only needs to press a key during initial installation, after that it should boot unattended just fine: "If the user gives permission, the signature will be installed and loader.efi will then boot up without any present user tests on all subsequent occasions even after the platform is placed back into secure boot mode." http://www.linuxfoundation.org/news-media/blogs/browse/2012/10/linux-foundation-uefi-secure-boot-system-open-source

So I won't have to go around to every classroom and every pc and click OK when I do my monthly wipe and reimage?

If I understand correctly, even reinstallation does not need user attention as long as loader.efi doesn't change. But that's based only on my reading of the article I quoted, so I could be wrong.

Re:Present user test?

[smash]

You've heard of ILO? iDRAC? Remote KVM? Real server hardware has such things.

Let me get this straight

[DMiax]

So, instead of signing with a scrap key that vendors will ignore they signed essentially with the original one, so that this bootloader will work on any PC that follows the standard? This is so awesome I don't even know at what to laugh first.

I wish LF just released this bootloader and defuse all this "secure boot" crap. Of course they will play nice and allow Microsoft to save their face... Microsoft incompetence is just appalling. They will probably end up signing malware by accident at some point, but at least you won't be able to run Linux on your PC, so mission accomplished.

Re:Let me get this straight

[someones]

If they did now, M$ would replace the broken key and its gone.
BUT, if they wait for the time when this secure boot crap really hits the market and THEN release this bootloader, M$ wont be able to revoke this key, as too many vendors allready included it and many would not go thru this crap again.

So it would be strategically wise to wait like 3 years and THEN release this one to essentially kill secure boot.

Re:Let me get this straight

[Anonymous Coward]

No need for them to sign malware, they'll end up bruteforcing the keys anyway, botnets are the best form of distributed computing.

Re:Let me get this straight

[Anonymous Coward]

At that point 99% of Linux will be able to be installed. So the only thing that releasing the key at that time would do would help Malware makers.

Re:Let me get this straight

[BitZtream]

No. Why is this marked insightful? Its pure speculation about things the poster doesn't even understand.

Vendors accept 'any key that is signed by the root ms key in the chain of trust'

That means that MS makes sub keys for each organization they sign a boot loader for. This sub key is signed by the root MS key. Boot loaders are signed by the organizations sub key. If one sub key gets compromised, it doesn't take EVERYTHING out with it making the whole thing ineffective. They can simply revoke the one sub key that was compromised. Pull the actual root key out of a vault somewhere and sign a new key for say ... Linux Foundation. That key is then used to sign works made by Linux Foundation.

The end result is that only the LF boot loader is using 'known compromised key chain'.

Hardware vendors that don't do this properly will cause themselves issues down the road as MS will also swap out their OWN 'sub key' from time to time to keep it secure, so if they implement for the MS one specifically, it will likely fail in the not too distant future even for MS software.

For those of you that understand PKI, replace sub key with intermediate and shut your yapping. Trying to explain to someone that clearly doesn't understand PKI.

Re:Let me get this straight

[DMiax]

If you start a reply with "no" you better include something that contradicts me. They signed with the root key and this would not let them invalidate it without breaking their own stuff. Even you admit it.

The problem is, even if you know a little of cryptography, you don't know shit about computers, or security for that matter. The public keys in the UEFI must not be updated from within the OS (even you are able to see that, right?) so in practice will not be updated, ever. No key will ever be revoked on a computer (apart from the microsoft testing machines perhaps) so the whole idea of segregating the different keys will do nothing to increase the security.

Consequently it does not really matter if Microsoft ever updates their own keys, they can just sign new bootloaders with the old one as well, since signing a legitimate package with a compromised key has really no bad effect. And anyway it is not like the bootloader is updated every second day: the next update should come around Windows 9... And they can just use the same trick LF was trying and chainload several of them. In conclusion yes, vendors can simply include a single key chain and forget about all others without any problem.

The tagline is: stop trying to explain and start to listen: you may learn something.

Wtf?

[ickleberry]

We have to ask Microsoft for permission now before they give us a key that lets us install Linux on our own machines?

This is seriously not good, lads. They still have the monopoly so we should sue them till the last toothpick in their Redmond HQ are belong to us.

Re:Wtf?

[Anonymous Coward]

We have to ask Microsoft for permission now before they give us a key that lets us install Linux on our own machines?

This is seriously not good, lads. They still have the monopoly so we should sue them till the last toothpick in their Redmond HQ are belong to us.

all your toothpick belong to us?

Re:Wtf?

[Anonymous Coward]

Someone set us up the gums?

Re:Wtf?

[flimflammer]

Or just disable secure boot, which is amazingly easy to do in the first place. If a novice user can properly install Linux, that same novice user can be directed to disable this stupid function.

Re:Wtf?

[Toreo asesino]

Disabling secure boot allows this no problem.

Re:Wtf?

[amorsen]

Feel free to run your own PKI and get the root keys included by the vendors. The option has been seriously considered by some of the larger Linux players, but it is just too expensive to do. Note that getting the root key included was not considered to be the main obstacle, it was the "run your own PKI" bit which killed the idea.

That is also why this is not news. PKI is hard, all of the major SSL signature vendors except one have made really stupid mistakes already. It is no wonder that Microsoft messes up too.

Re:Wtf?

[turkeyfeathers]

Or just disable secure boot, which is amazingly easy to do in the first place.

For now.

Re:Wtf?

[Anonymous Coward]

That's while you still -can- disable secure boot. If the Linux Foundation now has to ask Microsoft permission for a key that will allow distributions to boot, how much of a stretch is it for Microsoft to simply now allow any other keys besides their own to be signed?

They have the keys now, so to speak. They're the ones that get to decide what a computer can and cannot do now...and it's going to stay that way, because they have a steady stream of income from the even more tightly locked-down 360/720 platforms. As long as they have a good grasp on games and entertainment they can pretty much do whatever the hell they want to the PC.

Re:Wtf?

[kiwimate]

We have to ask Microsoft for permission now before they give us a key that lets us install Linux on our own machines?

I count three incorrect assumptions in this one statement.

Short answer: no, and see the other answers as to why it's no.

Long answer: no, and I'm not really that bothered that someone doesn't know this. What does bother me is that this got modded up to +5 Insightful.

Remember the days when Slashdot used to have technical people hovering around these pages?

Re:Wtf?

[linebackn]

> Or just disable secure boot, which is amazingly easy to do in the first place. If a novice user can properly install Linux, that same novice user can be directed to disable this stupid function.

To repeat what I have said before: how well will that really work in practice?

You: "Hey, I need to boot my Linux USB drive on your computer, is that OK?"
Friend: "Uh, sure, I guess."
Friend: "Uh, it isn't working."
You: "Oh, I need to go in to your bios and disable SecureBoot."
Friend: "Duh, you aren't disabling anything that makes my computer less secure!"
You "but...."
Friend "NO!!!".

Re:Wtf?

[flimflammer]

Really? You think Microsoft is going to be able to get permanent Secure Boot as a mandatory feature on all x86 class hardware, and then be allowed to dictate what competing operating systems are allowed on that hardware?

No one sees the flagrant antitrust issues here?

You guys take paranoia to scary levels.

Re:Wtf?

[Anonymous Coward]

So what happens when Microsoft decides to tie WindowsUpdate to having Secure boot enabled? What are you going to do then? Pretty soon dual booting will look like this:

1. Windows says updates are available, but secure boot is turned off in bios so Windows won't fetch and install until it's reenabled.

2. Reboot in to bios to enable secure boot and then into Windows.

3. With secure boot enabled, Windows downloads and installs updates.

4. Now you want to into Linux, or BSD but you can't because secure boot isn't working due to a) bios looking for string of "blessed" linux distro and won't boot even though you got legit key, b) you don't have a key, c) you've got key, you've got "blessed" distro, but it still doesn't work for some reason so you have to disable secure boot in bios.

5. boot into linux , everthing is good.

6. need to boot into windows. What's this? an out-of-band super critical security update? Great, now you have to go through the above rigmarole to get the update. Worse yet, some applications like Microsoft Security essentials or Windows Backup are also requiring secure boot be enabled before they update. Now you're fucked. If you need to boot into windows now you have to go through the pain in the ass ritual of booting into the bios everytime. Making dual booting such a painful annoying process is the goal here and Microsoft has accomplished its mission. WTG, Linux people. Maybe you should register a complaint with the FTC and the EU.

Re:Wtf?

[flimflammer]

Those theoretical friends have some serious trust issues, especially if they're not even willing to listen to the reason why it needs to be done or what it even "secures". I'm surprised he was even willing to boot a foreign OS in the first place.

Re:Wtf?

[faustoc4]

This is exactly the issue on the ARM architecture. An ARM computer in order to get the MS seal of approval must implement UEFI secure boot but manually adding keys or disabling secure boot will not be possible (Windows Hardware Certification Requirements: Client and Server Systems pages 121-122, different rules for x86/x64) So with only Windows RT key enabled in the UEFI, running anything but Windows RT will not be possible. Sound like a monopoly to me, a forced monopoly they didn't pay a dime for.

Re:Wtf?

[flimflammer]

What tangible reason would Microsoft actually have for tying Windows Update to Secure Boot or is this just theory fearmongering?

Re:Wtf?

[Anonymous Coward]

Is there anything in Microsoft's history that would convince you that they wouldn't make it mandatory? When a perp has a history of violent assault, it's not paranoia to be on your guard. Same with Microsoft. They have an long history of douchebag behavior, and they've forfeited the right to be given the benefit of doubt.

Re:Wtf?

[Anonymous Coward]

The most common and effective hack for disabling Windows 7's authentication checks involves the installation of a bootloader. Tying Windows Updates to UEFI would go a long way toward defeating that particular hack.

Re:Wtf?

[Anonymous Coward]

They are already doing this.

On ARM, in order to use the windows logo marketing crap (you know those stupid stickers all over that otherwise nice looking laptop you last bought), there can be NO way to disable sec boot. Manufactures will cave.

So, Yes. When they feel they can get away with it on x86 (no more winxp etc. out there), they will likely follow the path they ALREADY took with arm.

So, not paranoia on all of our part, but burying your head in the sand on yours.

MS has engaged in some of the most evil bus practices of any company (intentionally breaking standards so folks on wincrap have to use MS solutions for those components that should be inter-operable, stealing code, waiting out the victims money reserves in court, suing the victim back (if victim somehow was able to survive long enough to win in court, (if above failed) buying victim companies and dismantalling them, trying to sneak in fake error messages with code that detected running competitors products, senior folks like Bill G trying to steal from other senior folks while they lie in a hospital bed-- at the time, presumed to be dying, a really fucked up company. Now that apple is trying to be more evil than MS, MS seems to be doing its part to try to capture back the title of do only evil.

Re:Wtf?

[BitZtream]

No, but if you don't want to have to press the 'is this boot loader OK?' key ONCE when you install a new boot loader, you'll have to ask it.

WTF is your comment marked insightful? You don't have the slightest idea of how any of it works.

Re:Wtf?

[BitZtream]

Who the fuck lets people run alternate OSes on their computers?

What fantasy world do you live in. I don't need any secure boot shit to know I'm not letting you plugin and boot from a random thumb drive on my PC.

If you 'need to boot' you should have brought your fucking own computer.

Re:Wtf?

[DavidTC]

It's not actually a monopoly, because MS doesn't have anywhere near a monopoly in the tablet market yet. Ergo, no antitrust stuff is going to kick in...it's no more a monopoly than Apple locking down iPads is.

That said, I think it's a clear sign MS _will_ lock down the hardware as much as they can, and the only reason they've refrained from doing that on x86/x64 _for now_ is that they _do_ have a monopoly on that platform so antitrust rules would kick in if they try.

MS should not actually get any props for 'refraining' from doing something they clearly want to, but the government would slap them down for doing if they tried.

In fact, I wonder, after they sign this bootloader and Linux can boot even on locked down systems, if they aren't going to turn around and make it impossible to disable secure boot next standard revision. And they can say 'See, look, we're willing to sign anyone, so secure boot doesn't actually lock it to just us, so it's not an antitrust violation.'.

And then three years later, people are having trouble getting new bootloaders signed, and while mainstream Linux might still be fine, other, even smaller OSes like FreeBSD can't get booted, and it's a lot harder to boot off USB because of weird rules, etc, etc. They might have to put up with the current big linux distros, which they can point the DOJ to, but they can rig the game where the _next_ Linux distro, or the next OS, has a much steeper hill.

Re:Wtf?

[dch24]

I'm a technical person. To quote you: "I'm not really that bothered" that someone like you doesn't believe that I am.

Why should I have to ask Microsoft for permission to create my linux distro? You are pretty ignorant to think that this is not important.

Re:Wtf?

[shutdown -p now]

Did you pay attention to the guy you're replying to? The sole reason why it can be done with ARM is because Microsoft doesn't hold a monopoly there (indeed, no-one does). The scope of MS monopoly, as it was defined in the US anti-trust trial was "Intel-based personal computers".

Re:Wtf?

[kiwimate]

I'm a technical person. To quote you: "I'm not really that bothered" that someone like you doesn't believe that I am.

1. Very good attitude. I'm just a random person on the internet. If more people remembered that, the pages of Slashdot and other forums would be far more civil and pleasant.
2. However, if you're one of the people who modded that original comment up (and that is the group of people I was talking about), then we shall have to disagree about the validity of that moderation.

Why should I have to ask Microsoft for permission to create my linux distro?

You don't.

You are pretty ignorant to think that this is not important.

Without getting into the issue you've raised here, I said something quite different. I said I don't expect everyone to know the ins and outs of the secure boot technicalities.

However, if someone is going to moderate up a statement as insightful or informative, they should know what they're modding up.

Not surprised at all

[boorack]

As of now we know that Win8 is vulnerable to a huge chunk of malware designed for older versions of Windows. This "UEFI Secure Boot" does not prevent it at all. I suspected earlier that UEFI Secure Boot wasn't designed to make PCs more secure but rather to lock down PCs, so novice users trying to check out some Linux distribution will have tough time doing so. This fiasco makes me sure that this was the case and makes me wonder why antitrust authorities don't do anything about this. This is potentially more harmful than MSIE case after all.

Re:Not surprised at all

[Toreo asesino]

As of now we know that Win8 is vulnerable to a huge chunk of malware designed for older versions of Windows.

Citation (badly) needed.

Re:Not surprised at all

[rsmith-mac]

As of now we know that Win8 is vulnerable to a huge chunk of malware designed for older versions of Windows.

Secure Boot was designed to block malware from successfully inserting itself into the boot chain to bypass OS security measures, and that's it. Beyond that it's up to the OS to block malware from running in ring 0 or ring 3, which comes down to AV scanning, code signing, and any privilege escalation exploits abused by malware. Secure Boot closes off one important vector for malware, not all of them.

Re:Not surprised at all

[DrXym]

I'm not surprised if a chunk of malware still happens to work on the latest OS, especially through a normal BIOS which has no secure boot. Not all malware roots the system or replaces critical files and even if they did a legacy system has no way of knowing.

Even under UEFI, the secure boot would be responsible for ensuring the OS loader and firmware drivers were correctly signed before executing them. Assuming they were then it's not responsible for exploits which happen down the chain. I assume Windows 8 does attempt to validate its kernel and critical files but who knows what exploits are possible even under that model.

Re:Not surprised at all

[Wattos]

Maybe the "Secure" in "UEFI Secure Boot" referes to securing Microsofts Monopoly and existence in the OS market?

Re:Not surprised at all

[Truekaiser]

Regulatory capture.
The last fed lawsuit was less to do with them bundling i.e. With windows and more to do with them not giving the regulatory agency's $.

Re:Not surprised at all

[Paul Jakma]

What people really want is that their running code is verified to be running the way it is supposed to be. This requires formal proofs of code operation - which is notoriously difficult (and impossible to do generally with arbitrary software). SecureBoot does not give that, it only attests the code image *started* as the one it was supposed to be, according to the trust anchor. SecureBoot can however make the lives of ordinary users difficult. For now, we have the ability to use our own trust anchor, or none at all. Microsoft can't yet afford to block users from running all the non-SecureBoot OSes - as these include older Windows releases.

It's sad that so many Linux distributions and foundations are going along with this.

Re:Not surprised at all

[Anonymous Coward]

Secure Boot closes off one nowadays almost completely irrelevant vector for malware, not all of them.

FTFY.

Re:Not surprised at all

[recoiledsnake]

As of now we know that Win8 is vulnerable to a huge chunk of malware designed for older versions of Windows. This "UEFI Secure Boot" does not prevent it at all. I suspected earlier that UEFI Secure Boot wasn't designed to make PCs more secure but rather to lock down PCs, so novice users trying to check out some Linux distribution will have tough time doing so. This fiasco makes me sure that this was the case and makes me wonder why antitrust authorities don't do anything about this. This is potentially more harmful than MSIE case after all.

If you(and others here) really want to educate yourself instead of spreading karmawhoring FUD, please read on.

Here are some references about boot malware which UEFI secure boot will prevent.

http://www.chmag.in/article/sep2011/rootkits-are-back-boot-infection

http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_bit_windows/

http://www.computerworld.com/s/article/9217953/Rootkit_infection_requires_Windows_reinstall_says_Microsoft

I recommend reading atleast the first link.

Here's one juicy bit:

TDL4 is the most recent high tech and widely spread member of the TDSS family rootkit, targeting x64 operating systems too such as Windows Vista and Windows 7. One of the most striking features of TDL4 is that it is able to load its kernel-mode driver on systems with an enforced kernel-mode code signing policy (64-bit versions of Microsoft Windows Vista and 7) and perform kernel-mode hooks with kernel-mode patch protection policy enabled.

When the driver is loaded into kernel-mode address space it overwrites the MBR (Master Boot Record) of the disk by sending SRB (SCSI Request Block) packets directly to the miniport device object, then it initializes its hidden file system. The bootkit’s modules are written into the hidden file system from the dropper.

The TDL4 bootkit controls two areas of the hard drive one is the MBR and other is the hidden file system created at the time of malware deployment. When any application reads the MBR, the bootkit changes data and returns the contents of the clean MBR i.e. prior to the infection, and also it takes care of Infected MBR by protecting it from overwriting.

The hidden file system with the malicious components also gets protected by the bootkit. So if any application is making an attempt to read sectors of the hard disk where the hidden file system is stored, It will return zeroed buffer instead of the original data.

The bootkit contains code that performs additional checks to prevent the malware from the cleanup. At every start of the system TDL4 bootkit driver gets loaded and initialized properly by performing tasks as follows: Reads the contents of the boot sector, compares it with the infected image stored in hidden file system, if it finds any difference between these two images it rewrites the infected image to the boot sector. Sets the DriverObject field of the miniport device object to point to the bootkit’s driver object and also hooks the DriverStartIo field of the miniport’s driver object. If kernel debugging is enabled then this TDL4 does not install any of it’s components.

TDL4 Rootkit hooks the ATAPI driver i.e. standard windows miniport drivers like atapi.sys. It keeps Device Object at lowest in the device stack, which makes a lot harder to dump TDL4 files.

All these striking features have made TDL4 most notorious Windows rootkit and it is also very important to mention that the key to its success is the boot sector infection.

Another bit:

The original MBR and driver component are stored in encrypted form using the same encryption. Driver component hooks ATAPI's DriverStartIo

Re:Not surprised at all

[recoiledsnake]

SecureBoot does not give that, it only attests the code image *started* as the one it was supposed to be, according to the trust anchor..

Secure boot can give that, if the code image checks the signatures of the drivers and the kernel it loads and the kernel can check the signatures of the executables it runs and not load anything else that is not signed. Lets say you set up such a system today, you can be sure after 1 year that the same binaries are loading and have not been replaced with malicious ones. Even if malware was loaded into memory at runtime, cleanup will just involve a reboot + replacing any drivers, executables, kernel etc that fail the signature check(ignoring changes to data i.e).

Re:Not surprised at all

[LordLimecat]

The "best" (hardest to remove) rootkits still infect the boot sector. I just had to deal with one a few days ago.

Re:Not surprised at all

[AmiMoJo]

Actually UEFI does prevent a huge amount of it, and most important all the worst stuff that was beyond the ability of AV software to get rid of. Remember all those fake anti-virus scams? They installed a rootkit that changed the low level SATA driver which is loaded very early in the boot process. UEFI prevents an OS modified in that way from booting and the Windows 8 recovery system can detect and fix it.

Re:Not surprised at all

[hAckz0r]

Yes they can and will. That is all a part of the 'forced upgrade' plan to wealth. Microsoft will do most anything to make running an old OS more painful so you will be forced to buy from them again and again. I listen to the trials and tribulations of my coworkers trying to keep their ageing xp machines running on a daily basis. One is forced by M$ to keep the machine off the net because M$ decided that his license (part of a larger sitewide license) is now counterfit. Its used for malware testing so it does not belong on the net in the first place, but restoring and re-patching it every time it is used is a royal pain.

Re:Not surprised at all

[Chrisq]

SecureBoot does not give that, it only attests the code image *started* as the one it was supposed to be, according to the trust anchor..

Secure boot can give that, if the code image checks the signatures of the drivers and the kernel it loads and the kernel can check the signatures of the executables it runs and not load anything else that is not signed. Lets say you set up such a system today, you can be sure after 1 year that the same binaries are loading and have not been replaced with malicious ones. Even if malware was loaded into memory at runtime, cleanup will just involve a reboot + replacing any drivers, executables, kernel etc that fail the signature check(ignoring changes to data i.e).

No, once malware has run you have to assume the worst; that software has been compromised and verifies false signatures. If you had a system that never allowed new signers (all signatures built into the kernel) then you would be right, but it would be inflexible. Also you can't just include executables in your checks; anything that could be interpreted also needs verification.

Re:Not surprised at all

[Anonymous Coward]

Well, instead of demanding the BIOS to not boot anything MS-unblessed, it would have been easier to prescribe the boot order to start with the hard disk. This won't help against factory-installed malware on the disk, but that is not really the most prevalent attack vector.

Re:Not surprised at all

[marcosdumay]

Is there something about UEFI and secureboot that causes many folks' brains to be absolutely switched off?

No. But it seems there are a few points that you are making an effort to ignore. Because you just quoted them, but still don't acknowledge them.

Re:Not surprised at all

[Anonymous Coward]

Actually, the best and hardest to remove infect the bios itself, removing those are very difficult.

Re:Not surprised at all

[Anonymous Coward]

Ok here is the best solution to TDL4, which is sophisticated enough to sound like something invented by homeland security for snooping on just about anybody who has little real computer experience.

This is exactly why I always completely nuke old drives for people who buy a used computer. INCLUDING ALL SECTORS

I thought the insidious part of UEFI was that it was a bios chip signing regime, so swapping out drives or using two different drives, each of which can be independently selected within the bios meant that you couldn't just pull or add a drive to install a different OS any longer?

SO yes fucking with the bios to make it so no operating system that does not have a UEFI key is EVIL and is Ballmer's wet dream finally come true!

Lets get it straight and cut the bullshit from the Microsoft shills that jump on anything about what is really happening....IF I cannot chose to pull the drive form a device, save it for later resale with the unit and put in another one that will run whatever I chose, then the reality is that Microsoft owns the device that I just purchased.

It is time to standup again to these bastards that take away the consumers rights to real ownership of digital devices!

 

Re:Not surprised at all

[clarkn0va]

Secure Boot closes off one nowadays almost completely irrelevant vector for malware

Of course if that were really true then MS would look very silly for all the effort they've dumped into it. In fact, their efforts only really make sense once you redefine Linux and other alternative-to-Windows OSes as malware. When you consider that free software (especially operating systems, web browsers and office suites) have proven a far bigger threat to MS's bottom line than any or all real malware combined, the secure boot campaign starts to really make a lot of sense.

Re:Not surprised at all

[geekboy642]

Windows 8 was tested and found to be invulnerable to about 85% of all previous Windows 7 malware. That means there's about 15% of old malware that can infect the new hotness. Depends on your perspective for the precise phrasing, but 'huge chunk' is not completely false.

Re:Not surprised at all

[jthill]

Unless I'm missing something, the premise here is that felony monopolization is a fig leaf for not bribing bureaucrats.

Extortion, vandalism, making contracts with the intent of breaking them, none of these constitute crimes or even happened in this world you're painting for us, is that it?

Finally, Microsoft went beyond encouraging ICPs to take advantage of innovations in Microsoft's technology, explicitly requiring them to ensure that their content appeared degraded when viewed with Navigator rather than Internet Explorer.

That's one sentence from paragraph 328 of the document detailing their crimes. Them demanding exclusion and degraded functionality for a perceived threat to their market presence is nothing new, it'd fit right in with that document and with the cynics' view of their character -- and "felon" is unquestionably a characterization. Outside the courtroom it's a simple matter of perception. Legally, of course, it's an absolutely correct description of the corporation as a whole.

Re:Not surprised at all

[Paul Jakma]

No, it can not. SecureBoot verifies the code image was the one that was intended, *prior* to that code being run. SecureBoot can say nothing about what happens when that code runs. In particular, SecureBoot will not protect you from the code being modified or replaced once it is running, by design or (the typical case for security compromises) through the bugs that are rife in any non-trivial body of code. To make guarantees about the correct operation of code and be able to verify it is free of bugs that would allow the code to be replaced would require formal verification. That's a near impossible task generally.

"even if malware loaded into memory into runtime" - so you recognise this can happen, yet still can claim SecureBoot protects against it? A reboot doesn't protect, because the system can just be compromised again (e.g. by some apparently innocuous application, or even a data file that gets interpreted automatically by an application that has a bug, thus allowing code injection and further exploitation of kernels bugs - as there have been in, e.g., Javascript and Flash interpreters).

SecureBoot does not fix the problem that end-users want it to. However, SecureBoot certainly walks us down a path where large corporates could make life difficult for end-users. MS might not be able to make SecureBoot mandatory for now, for legacy compatability reasons, but do not doubt they will when they can. SecureBoot is already *mandatory* on ARM systems, in order to be supported by MS Windows there.

Re:Not surprised at all

[Anonymous Coward]

When you say "malware" you mean "DAS loader".

Re:Not surprised at all

[Zero__Kelvin]

" Beyond that it's up to the OS to block malware from running in ring 0 or ring 3"

The solution to that is as simple as it is OS independent. Simply run the ARM versionj ;-)

Re:Not surprised at all

[Anonymous Coward]

I thought the insidious part of UEFI was that it was a bios chip signing regime, so swapping out drives or using two different drives, each of which can be independently selected within the bios meant that you couldn't just pull or add a drive to install a different OS any longer?

UEFI does not do that.

SO yes fucking with the bios to make it so no operating system that does not have a UEFI key is EVIL and is Ballmer's wet dream finally come true!

Lets get it straight and cut the bullshit from the Microsoft shills that jump on anything about what is really happening....IF I cannot chose to pull the drive form a device, save it for later resale with the unit and put in another one that will run whatever I chose, then the reality is that Microsoft owns the device that I just purchased.

You're in tinfoil hat territory, dude. UEFI only requires the bootloader to be signed with a private key matched by one of the public keys loaded into the firmware. It does not attempt to lock you out from replacing your hard drive with another. You just have to run a signed OS installer and it has to install a signed bootloader.

But if you really really want to install an unsigned OS, guess what? You can do that too! Microsoft's own Windows 8 logo compliance program requires UEFI x86 computers to have a BIOS setting which disables checking the bootloader's signature. Signature checking must be on by default, and disabling it requires a physical presence check (otherwise malware could disable it without asking you), but the option to turn it off must be there or Microsoft won't let the HW manufacturer promote the computer as being suitable for Windows 8.

Another fun fact for you: you're also able to load more signing keys into the firmware. Microsoft's Windows 8 compliance program only requires a Microsoft key to be preloaded out of the box; it does not prevent you from installing others.

It is time to standup again to these bastards that take away the consumers rights to real ownership of digital devices!

Yeah yeah fight the power I'm so impressed with your rebellion. Just shut up idiot, you know nothing about anything.

Re:Not surprised at all

[smash]

What people really want is that their running code is verified to be running the way it is supposed to be

And to do that, you need to know that all code running in the system has not been compromised. Starting with the boot-loader. if the boot loader is compromised, then ALL bets are off - you can't be sure that whatever hardware/software interrogation method you are using isn't being lied to something intercepting it at a lower level.

Re:Not surprised at all

[Anonymous Coward]

UEFI prevents an OS modified in that way from booting and the Windows 8 recovery system can detect and fix it.

Uh, oh. That's just the experience I had with certain AHCI drivers. Once installed, the machine refused to boot until Windows 8 recovery system fixed it. Of course I had not made a restore point before installing. The experience of lost files can be had today, even with machines with a traditional BIOS!

Re:Not surprised at all

[Anonymous Coward]

"The price of freedom is eternal vigilance."

To be fair to M$, the reason they are a monopoly is in part probably due to the bad economy. That said, vendor lock in is the name of the game, from facebook to gmail. People are right to fear M$, and M$ should NEVER be responsible for hardware control -- both due to their monopoly control, and their incompetence.

Re:Not surprised at all

[Toreo asesino]

Windows 7 is vulnerable to 100% of malware without AV software installed - there are plenty of anti-malware solutions that catch 100% that work with Windows 8. I'm not sure what your point is other than perhaps some subtle FUD spreading.

Re:Not surprised at all

[Paul Jakma]

Yes, something like SecureBoot possibly could be a piece of a system that guarantees the operation of code - though, it need not be either (e.g. the hardware could come with a formal proof or model, and a checker could verify the loaded code follows the proof - not caring where it comes from).

However, SecureBoot is not that system, nor does SecureBoot of itself get you any closer to that system.

E.g. how many systems get their boot path compromised, without the exploitation of any software bugs? That's basically never the case with malware. If you can compromise a system, you can find a way to have some apparently innocuous data file exploit a bug in some code that interprets it to inject code (JPEG parsers, Flash, JavaScript, etc.. take your pick, the list is endless - they're all buggy, cause we don't know how to write bug-free code), and then take-over the machine - that will work for the initial exploit and it will work to re-exploit the machine after reboots. SecureBoot just doesn't do anything to stop this, and these are scenarios which exploits already regularly use.

SecureBoot doesn't stop the bad guys. It will only stop the less-technical, more ordinary users from using their computers the way they want.

Re:Not surprised at all

[geekboy642]

Windows 7 is vulnerable to 100% of Windows 7 malware and some amount of Windows 8 malware. Windows 8 is vulnerable to ~15% of Windows 7 malware and 100% of Windows 8 malware. Virus scanners and the like can reduce those vulnerabilities significantly, even close to 0% for both versions of the OS. There's no FUD in those facts, but acting as if Windows 8 is suddenly immune to malware makes you a shill.

Re:Not surprised at all

[DMUTPeregrine]

The /really/ fun ones are the ones that infect the firmware for various components of the computer, such as the NIC or the CD drive. AFAIK those are only proof-of-concept research versions, but it is possible for one to go unnoticed in the wild.

I wouldn't worry too much about all this

[Viol8]

Given the number of server side linux installs on x86 machines the PC manufacturers are not going to shoot themselves in the foot and not supply machines that linux can be (pre)installed on. They'll probably have a Windows compatable line and a Linux compatible line. At least for servers. For desktops and laptops things could get a bit tricky I suppose, but then I was under the impression all this secure boot crap could be switched off in the BIOS anyway?

Re:I wouldn't worry too much about all this

[mwvdlee]

As I understand it, UEFI is not a requirement for Win8, instead it's additional expenses for hardware manufacturers.
I'm guessing very few machines will actually have UEFI. Just some of the more expensive business models.

Re:I wouldn't worry too much about all this

[Anonymous Coward]

but then I was under the impression all this secure boot crap could be switched off in the BIOS anyway?

quote

For now... yes.
in the future..
Who knows. It wouldn't be Microsoft if they weren't putting the boot in with an innocent expression on their faces.

Re:I wouldn't worry too much about all this

[Anonymous Coward]

are you goofy? go look at the motherboards for sale.

Re:I wouldn't worry too much about all this

[Anonymous Coward]

It's *already* mandatory for ARM systems.
So you're the 'borderline retard'.

Re:I wouldn't worry too much about all this

[Anonymous Coward]

Wake up. Box builders cannot use the Windows logo if their machines are not compliant, they also lose their preferred partner license discounts.

It has nothing to do with building your own machines, or a limitation in the OS itself. Just the image and money.

Re:I wouldn't worry too much about all this

[recoiledsnake]

I thought Windows RT was supposed to fail spectacularly from all the articles and comments on Slashdot?

Why are people then worried about Surface RT etc. getting a monopoly and using it to squeeze out Android from ARM tablets?

Where is the outcry about Apple locking up "ARM systems" with >60% marketshare ?

Or even about Android tablets errr "ARM Systems" shipping with locked bootloaders?

Re:I wouldn't worry too much about all this

[FireFury03]

As I understand it, UEFI is not a requirement for Win8,

AFAIK Windows 8 doesn't require UEFI, but the vendors are required to implement it in order to be able to use the "Designed for Windows 8" stickers. I think they're also required to enable it by default. x86 vendors can have an option in the BIOS to allow it to be turned off (I imagine the vendors who largely sell servers will do this whilst the cheap brands won't because implementing a "off" option would cost them a few pennies more in coding time). As I understand it, MS has mandated that ARM machines are required to have UEFI that can't be switched off (not entirely sure how they are enforcing this last one).

Re:I wouldn't worry too much about all this

[Anonymous Coward]

You made one mistake: x86 vendors must have an option to allow it to be turned off (for now).

Re:I wouldn't worry too much about all this

[flimflammer]

Please. On locked down arm devices, yes. Get back to me when x86 is mandatory.

Continue being paranoid.

Re:I wouldn't worry too much about all this

[flimflammer]

Maybe you should wake up. You think everyone is just going to sit idly by and let Microsoft force every other OS out of the market on consumer PCs unless Microsoft says it's OK for them to exist there? You don't think any of the big names in computing are going to have a problem with this?

No one else sees the glaring legal issues here? No one thinks Microsoft could see the glaring legal issues there?

By all means, mod this down like my previous post. You people are crazy.

Re:I wouldn't worry too much about all this

[gtall]

You mean MS wouldn't possibly lean on box makers so that MS Malware is included in every box they shift. There simply isn't any precedence for this, is there?

So which box maker do you think is going to stand up to MS? The ones that were producing Linux netbooks or whatever those things were called a few years ago?

MS is a sort of like a heat seeking missile. Wherever the fires of computing hell burn, you can bet they will head directly for them.

Re:I wouldn't worry too much about all this

[BitZtream]

You do realize that with UEFI ... THERE IS NO FUCKING BIOS right?

Every time you people say shit like this you make it clear that you don't even know what the fuck you're talking about.

Re:I wouldn't worry too much about all this

[BitZtream]

You mean MS wouldn't possibly lean on box makers so that MS Malware is included in every box they shift. There simply isn't any precedence for this, is there?

No, there isn't. None what so ever. You're trying to imply that a particular round of court cases is somehow the same, but it isn't and you're just too ignorant to know it.

So which box maker do you think is going to stand up to MS? The ones that were producing Linux netbooks or whatever those things were called a few years ago?

One day you gays are ranting on about how Linux owns the server market, and the next you seem to think no one uses it. Make up your mind.

MS is a sort of like a heat seeking missile. Wherever the fires of computing hell burn, you can bet they will head directly for them.

This doesn't even make sense.

Re:I wouldn't worry too much about all this

[Anonymous Coward]

I wrote a different reply to someone else way up above where I said "BIOS setting" in the context of UEFI knowing full well that there's no classic PC BIOS left with UEFI. I was 100% conscious of the fact that technically I was wrong but I decided that as verbal shorthand people are familiar with it's absolutely acceptable. How does that make you feel, Mr. Pedant? Hmm?

Re:I wouldn't worry too much about all this

[FireFury03]

You do realize that with UEFI ... THERE IS NO FUCKING BIOS right?

Every time you people say shit like this you make it clear that you don't even know what the fuck you're talking about.

Yes, ok, there is no classical BIOS. There is, however, a user interface to the firmware to set various options, just as there is on an actual BIOS. It was pretty obvious what I was talking about, I think everyone understood it except for you, who instead chose to be a complete bellend about it for no good reason.

Jerkoffs

[Anonymous Coward]

UEFI is complete bullshit.

Microsoft banned GPL in UEFI binaries ..

[dgharmon]

Microsoft has also banned any GNU GPLv3 licences for these binaries.

'When you get to this stage, you also have to certify that the binary " to be signed must not be licensed under GPLv3 or similar open source licenses". I assume the fear here is key disclosure but it's not at all clear (or indeed what "similar open source licences" actually are).'

Re:Microsoft banned GPL in UEFI binaries ..

[bWareiWare.co.uk]

This restriction is imposed by the GPLv3 not by Microsoft. They are just being helpful in letting you know, they can't give specifics for all other licensees out there.

Re:Microsoft banned GPL in UEFI binaries ..

[recoiledsnake]

Stop raking up shit with stupid karmawhoring paranoid crap.

If the UEFI binary was GPLv3 (not GPL like in your title, GPL v1 and v2 are good), then anyone distributing the binary will have to release the signing key, which defeats the whole purpose of UEFI secure boot signing since it will allow malware creators to sign their own malicious bootloaders with the key.

Why don't you GPL v3 your bank accounts and passwords and release them? OMG DGHARMON BANS GPL FOR HIS INFO. +5 INFORMATIVE

While the ignorance in the posts here is pathetic enough, even the moderators are clueless about UEFI secure boot.

Re:Microsoft banned GPL in UEFI binaries ..

[l3v1]

What? GPLv3 doesn't allow a binary of the software to be signed with a key? Do you have a citation for that? Cause it sounds... interesting.

Re:Microsoft banned GPL in UEFI binaries ..

[l3v1]

Nevermind, I looked around myself: http://www.gnu.org/licenses/gpl-faq.html#GiveUpKeys

It says:

"I use public key cryptography to sign my code to assure its authenticity. Is it true that GPLv3 forces me to release my private signing keys?

No. The only time you would be required to release signing keys is if you conveyed GPLed software inside a User Product, and its hardware checked the software for a valid cryptographic signature before it would function. In that specific case, you would be required to provide anyone who owned the device, on demand, with the key to sign and install modified software on his device so that it will run. If each instance of the device uses a different key, then you need only give each purchaser the key for his instance."

Re:Microsoft banned GPL in UEFI binaries ..

[sunderland56]

So does that mean that the FSF is going to release a binary without source code? How ironic.

Re:Microsoft banned GPL in UEFI binaries ..

[Barefoot Monkey]

So does that mean that the FSF is going to release a binary without source code? How ironic.

No, the Linux Foundation. And no, it doesn't mean they'll release a binary without source code - it just means that the binary presented for signing must not be licensed as GLPv3 (or similar, whatever that means).

Re:Microsoft banned GPL in UEFI binaries ..

[idontgno]

It's "Tivoization": GPL software that can be modified and compiled, but the intended hardware will refuse to run it unless the binary is cryptographically signed...and the hardware vendor holds the keys and isn't sharing.

GPL 2.0 had no protections against this particular end-run on the "anyone can modify, anyone can use" philosophy of Free Software. Tivo very cleverly used this loophole to "protect" their devices from "unauthorized" software modifications (i.e., they used Linux kernel and GNU userland, but didn't want the user hacking around with it). "Sure, you can have the source code... modify it to your heart's content. However, you can't run it on Tivo hardware, sorry."

GPL 3.0 put in a fairly explicit clause (cited elsewere in this thread) to prevent that end-around. It ain't GPL'd (per 3.0) if you can't modify it and run it on the platform it was intended on.

This is applicable in the UEFI boot software case: If the UEFI bootloader in Secure Boot mode is GPL 3.0, the signing key is as much part of the end-user redistributable as the source code... and Microsoft ain't giving away that signing key. (Besides, everyone having the key to the bootloader is exactly the same as not having Secure Boot at all... the bad guys could sign their rootkit and the loader would very happily load it.)

What am I missing?

[wonkey_monkey]

So the Linux Foundation, quite rightly, are trying to make available a signed bootloader which will then anyone boot whatever we want without having to disable secure boot - have I got that right? What stops someone monkeying around with the next level of abstraction?

Re:What am I missing?

[Anonymous Coward]

As you have noticed, the system is retarded and unworkable.

Re:What am I missing?

[recoiledsnake]

So the Linux Foundation, quite rightly, are trying to make available a signed bootloader which will then anyone boot whatever we want without having to disable secure boot - have I got that right? What stops someone monkeying around with the next level of abstraction?

Not exactly. It will require a physically present user to click though a warning message before booting the "next level of abstraction".

Re:What am I missing?

[Anonymous Coward]

Since users have go through a warning message everytime before such a system is booted , it is noticed that it's Slashdot posters and moderators that are retarded and falling for all the FUD about secure boot.

Re:What am I missing?

[Anonymous Coward]

I doubt it, if I install linux on my computer as the only OS I want it to boot without user interaction. I don't see why they would make a bootloader without that function, and I suspect that will be the case. And then someone can take that bootloader, boot their malware first, and then boot windows after inserting code into windows. Even if you got the warning it will only do so much if you erase the bootable windows copy and provide only the bootable malware that chain loads the infected unsigned windows.

Re:What am I missing?

[gl4ss]

Since users have go through a warning message everytime before such a system is booted , it is noticed that it's Slashdot posters and moderators that are retarded and falling for all the FUD about secure boot.

why would there be a warning for running this (eventually to be) signed linux foundation bootloader?

maybe you were referring to switching uefi sec off to run _any_ bootloader. but this one would be as legit as any for the bios.

Re:What am I missing?

[DavidTC]

What are you talking about? Why would a signed bootloader prompt anyone?

Godspeed

[Anonymous Coward]

Freedom is getting fucked harder and harder every day.

Re:Godspeed

[Anonymous Coward]

Security and Freedom is a balancing act. A purely free computer has no security and a purely secure computer is not usable. Many people have wondered if there is a way to use PKI to make computers more secure.

Can I have a secure system if someone has physical access to it? Yes, with PKI I can. Am I willing to make things a bit more annoying when dual booting to have a more secure system? I know I am.

Disabling secure boot and dual booting?

[efornara]

I know that new laptops shipping with Windows 8 preloaded have to allow the user to disable secure boot.

Now that some laptops are out there, does anyone know if disabling secure boot will still let you run Windows, ideally even after its partition has been resized? Or will the preinstalled Windows just refuse to boot if secure boot has been switched off?

Another anti trust case?

[zaax]

Sounds like another anti-trust case. I will be putting Unbuntu on my next machine and if I can't do it I will be asking for my money back and getting pi, though I might getting a pi anyway as they are much cheaper than a 'nomal laptop / netook'.

Re:Another anti trust case?

[Anonymous Coward]

You can just disable it in the bios you retard.

Enjoy uisng your 'netook'.

That won't work because netooks ues bananos instead of bios.

This

[symbolset]

is my surprised face:

Of course it was defective.

[Anonymous Coward]

Which part of "Microsoft Product" did they not understand?

support free software & hardware and prices dr

[Anonymous Coward]

Stop buying MS hardware! Prices will drop...

The free software and open source software advocates merely need to stop buying hardware dependent on and designed for proprietary operating systems. There are options that are becoming very popular. The major issue right now is there are a lot of people too cheap to realize the difference between a $400 POS laptop with Microsoft Windows which has higher specs and your typical higher quality laptops smaller companies are shipping with Linux. Even if the hardware is lower spec'd at a higher price doesn't mean it is a rip off. What your getting is significantly better in a number of different areas.

As an example your not going to be dealing with wireless issues related to digital restrictions. HP, Dell, Lenovo, and Toshiba ship laptops that prevent the replacement of incompatible wireless cards with third party options. This is because they make money off selling replacement cards to users whose wireless cards have died after the warranty period.

There are other good examples such as the loss of support because manufacturers have discontinued the proprietary drivers/firmware for your hardware.

While System76, ZaReason, and most others are shipping good quality hardware they do need to improve in certain areas. Right now pretty much every typical user is being disadvantaged by bad policies or simply the lack of a policy that advocates the use of chipsets which are free software friendly where such chipsets are available. A quick search will turn up a lot of customers who are running into issues because of these non-free drivers/firmware dependencies. And from what I'm reading nobody cares. People are just being shafted.

The only company which seems to be making a difference in this area is ThinkPenguin. ThinkPenguin is funding a number of major and minor distributions, the Free Software Foundation, and investing in the manufacture of hardware which is free software friendly. This amongst many other projects to bring better support for hardware to users around the world. And this irregardless of the distribution. If you want to run Ubuntu one day and switch to Trisquel the next you actually can (Trisquel is a distribution that doesn't ship drivers/firmware/and other software dependent on non-free software- there are many other distributions with similar policies). Even Debian doesn't ship with non-free drivers/firmware any more. They have released a derived kernel even which removes pieces from the mainline kernel.

Ultimately it is the actions of people using such distributions which funds the ecosystem which improves support for hardware that works with Linux rather than against it.

Standardizing on a binary application interface is not the answer. Supporting free software is.

And I'm not a loony. I'm not saying get rid of all the non-free stuff. There being distributions which support bad hardware will help in introducing people to free software. What I'm saying is be conscious of the negative effects of your actions when purchasing hardware down the road. Encourage distributions to inform users of the technical (and optionally ethical) issues of using such hardware. If you can avoid hardware dependent on non-free code do so.

Linux will not take off without wider availability of such hardware because the average user isn't going to stat up a terminal window to install some proprietary driver. They aren't going to apply some hack because the manufacturer refuses to fix a bug. The source code needs to be maintained (not just included) in the mainline kernel and/or similar. That is what leads to the best hardware which works out of the box. And this is not to say that the code itself is necessarily better. However it certainly doesn't hurt it when anybody can submit fixes, improvements, etc.

Need to replace UEFI with CoreBoot

[LinuxNeverWindows]

The way of breaking that monopoly is to replace UEFI on machines with CoreBoot (http://www.coreboot.org/Welcome_to_coreboot). This still does not support enough hardware but given a bit of support from Linux friendly companies (e.g. Clevo, IBM etc) it could be done. To see CoreBoot in action have a look at the Samsung ChromeBook with CoreBoot (http://www.youtube.com/watch?v=RypqMqtTPs8).

Microsoft as gatekeeper

[lasermike026]

Microsoft as gatekeeper to PC hardware is a non-starter. You can not have one company determine who will and will not use a PC. When I mean use I mean loading the operating system of the user's choice. That is using a computer, running the programs and operating system that the owner of the computer wants. One company determining how a user will use their computer best example of a monopoly.

Sup Dawg, I herd you like bootloaders

[Anonymous Coward]

So I put a bootloader for your bootloader to boot

Not good

[Anonymous Coward]

In earlier news as I remember it the fact that Verisign/Symantec provided the keys was seen as a sign that Microsoft did not put itself in a position of too much power over the process. Now I read they are very much part of the process. No matter what their intentions are (at the moment) it is not good that OS suppliers have to go through a competitor to access hardware features.

The things that went wrong hopefully weren't intentional. They do show that Microsoft still lives in a dream world where all IT is Microsoft. Checking if a file is a Win32 binary and requiring Silverlight is not the way to interact with a world where other operating systems exist.

They don't go into specifics about the contract, but it reminds me of me having reason to contact Microsoft a few years back about an issue I ran into as a result of others using their software, without me using any of their products at all. A support guy on the phone pointed me to a contact form on their website. It turned out I had to agree to a EULA just to talk to them, making me agree to all kinds of things about products I didn't even use. I refused to do that, and sent my complaint by paper mail instead, mentioning that I thought it was a bit wierd that an IT giant effectively blocked me from using the computer to communicate with them. I never got a response to my complaint. The message as I interpreted it: if you don't use their stuff you don't exist for them. It seems to be happening here too.

Cant work out

[Anonymous Coward]

How people still trust a pathological liar (Microsoft) which always showed their true colours. Grow up.

Antitrust!

[Anonymous Coward]

This "secure boot" is nonsense. I say we all sue Apple until we can run Ubuntu on our iPads!

Wait, we're supposed to be mad at Microsoft today, aren't we? My bad.

Re:Antitrust!

[jbengt]

MS can do all the lock-down they want on the hardware they make and sell. But for them to be in charge of locking down 3rd party hardware and software that I buy from other vendors is just nuts. Especially as the 800 lb gorilla in the room means that I will have almost no choice of vendors that don't restrict my use. I want my computer to be mine, not Microsoft's and not Apple's.

Re:Antitrust!

[Anonymous Coward]

Essentially, Microsoft is turning into the IBM of yore...

I'm not sure I give much of a crap

[pointyhat]

It has been proven recently that the whole WinTel PC thing and the associated lock in is on its way out as UEFI Secure Boot would be as well. ARM and Linux is where everything appears to be heading. Look at all the Android tablets and phones, Chromebook, Raspberry Pi, Beagleboard etc. Even Apple is rumored to be looking at ARM for newer laptops and are throwing their own cores together.

It's only a matter of time...

Re:I'm not sure I give much of a crap

[marcosdumay]

(Failing != failed) && (going down != zero)

MS has a hold on the PC strong enough to survive several years, even if their management insist on their current suicide style of doing business. They can make a lot of problems even if they fail, and they can be a huge problem if they somehow get their heads over their shoulders.

Cripes! How shocking!

[Arancaytar]

I don't see how anyone could have seen this coming.

Oh, the irony

[Anonymous Coward]

Apple will soon be the maker of the most open PCs. OSX, Windows, Linux, whatever you want to run on it.

That's a win

[RMingin]

"I've pulled the binary apart, and I think the problem is that it's not signed with a LF [Linux Foundation] specific key, it's signed by a generic one rooted in the UEFI key."

Please, "leak" that one immediately. It would tear huge holes in "Secure Boot".

Re:That's a win

[Anonymous Coward]

My thought is that if this researcher can do that what stops someone making malware from doing the same thing? Maybe I just don't understand how it works, but it would seem to me that if you are allowing a certificate that can be extracted and spoofed then the whole defense mechanism has been circumvented.

Re:That's a win

[BitZtream]

'Leak' what? All he has is a public key and a digital signature at most.

The point is that the root key is supposed to sign a new key generated JUST for signing binaries from LF. LF will not see that key either.

The public key and digital signatures are public knowledge (or will be when it gets going fully) as they are required to be public knowledge for the whole thing to work. UEFI machines supporting secure boot will have the public root key embedded in them.

IF they released this boot loader to the world all they would accomplish is being obnoxious and not following protocol, creating more headaches for the infrastructure handlers. They'd just be dicks, like you. Except you're too ignorant to know why it doesn't accomplish your retarded goal of making things LESS secure.

Do you REALLY want to promote the ability of installing root kits on your own PC? Are you really that fucking stupid?

Re:That's a win

[smash]

Unfortunately, most of the 'tards here these days are in fact that fucking stupid.

"Designed for Windows 8" sticker

[r00t]

Last I heard, Apple had clawed it's way back to the top in some fashion... maybe the most profitable PC vendor? Anyway, they are pretty big and successful. Do they have this sticker? I doubt it. I'm thinking that a bunch of stickers all over your product detracts from the styling. A PC covered in gaudy do-dads looks like shit next to a PC with nice clean styling.

Not if the SATA change happens after boot.

[Anonymous Coward]

It only stops a changed boot process booting. But if once booted, the OS then changes the drivers, you're open again.

And though this may be "the worst to remove", multiply the effort by the probability of catching one and you're being penny wise and pound foolish.

Re:Not if the SATA change happens after boot.

[Anonymous Coward]

1. Firmware checks signature of bootloader before permitting it to load and execute.
2. Bootloader checks signature of kernel before permitting it to load and execute.
3. Kernel checks signatures of each driver before permitting them to load and execute.

Sorry, but I'm not seeing how a moderately well designed OS with a full chain of trust going all the way back to the bootloader is going to get compromised through driver loading. Yes, there's a possibility of design errors. It's not very likely, though. Unlike a lot of other attack surfaces, these are very small pieces of code and they should be relatively easy to get right.

Personally, out of the three loaders involved I'd be most concerned with #1. If you use a relatively mainstream OS, the other two are going to get audited and hammered on by real experts. If you insist on using cheap hardware, though, #1 might have been less well tested and audited.

As for penny wise / pound foolish, I'm not seeing how it applies here. Secure boot isn't a huge investment (code signing is not a radical new technology), and it's a valuable piece of defense in depth.

So "no" then.

[Anonymous Coward]

There is no reason why MS cannot sign a GPL program if asked other than it doesn't want to.

Re:So "no" then.

[Goaway]

Technically, yes, but the reason they don't want to is because if they did, they would be forced to distribute signing keys to everyone who ever installed that binary, which would sort of ruin the security of the system, as a rootkit developer could just grab a key too.

Re:So "no" then.

[DavidTC]

Why would Microsoft, which is not distributing the Linux bootloader, be worried about the Linux bootloader license?

You are correct in that the bootloader cannot be GPLv3, because the GPLv3 does not allowed the distribution of signed-binaries that cannot be recompiled from source and signed again...but the fact is, this has _nothing_ to do with MS, which cannot possible be required to do anything at all.

MS was handed something to sign, it signed it. If there are distribution limitations on the thing signed, that is not MS's problem, because MS IS NOT DISTRIBUTING IT. There is absolutely no theory of law under which MS would be required to give up their incredibly valuable signing keys because a third party was in violation of yet another third party's license.

Now, it's certainly possible for MS to be nice and telling people that by saying 'Oh, and developers might want to check to see if the license their code is under is anything like the GPLv3 because that added restrictions on signed binaries that the developer cannot meet, as we have the keys and we sure as hell aren't giving them to random users, so the developer will be in violation of that license.'

But what MS is doing is clearly something else. There's no reason to make people 'certify' anything, especially that's it not under 'GPLv3 or similar open source licenses', which is fairly clearly worded in such a way to try to scare people away from using the GPL at all, when the GPLv2 has no such problems.

MS is using a specific issue with a specific OSS license in specific circumstances to try to scare people away from licenses 'similar' to the GPLv3.

Quick poll: Who here would assume the GPLv2 is 'similar' to the GPLv3 if you didn't read this site and didn't know 'signed binaries' was one of the big GPLv3 changes?

Re:So "no" then.

[Anonymous Coward]

If you had MS sign a GPLv3 bootloader, and you distributed it.. you would be in violation of the GPLv3, since you can't provide MS's key.

So it's just a helpful message letting you know that the key signing service should not be used with gplv3 binaries.

Re:So "no" then.

[Anonymous Coward]

Why would Microsoft, which is not distributing the Linux bootloader, be worried about the Linux bootloader license?

You are correct in that the bootloader cannot be GPLv3, because the GPLv3 does not allowed the distribution of signed-binaries that cannot be recompiled from source and signed again...but the fact is, this has _nothing_ to do with MS, which cannot possible be required to do anything at all.

MS was handed something to sign, it signed it. If there are distribution limitations on the thing signed, that is not MS's problem, because MS IS NOT DISTRIBUTING IT. There is absolutely no theory of law under which MS would be required to give up their incredibly valuable signing keys because a third party was in violation of yet another third party's license.

Now, it's certainly possible for MS to be nice and telling people that by saying 'Oh, and developers might want to check to see if the license their code is under is anything like the GPLv3 because that added restrictions on signed binaries that the developer cannot meet, as we have the keys and we sure as hell aren't giving them to random users, so the developer will be in violation of that license.'

But what MS is doing is clearly something else. There's no reason to make people 'certify' anything, especially that's it not under 'GPLv3 or similar open source licenses', which is fairly clearly worded in such a way to try to scare people away from using the GPL at all, when the GPLv2 has no such problems.

MS is using a specific issue with a specific OSS license in specific circumstances to try to scare people away from licenses 'similar' to the GPLv3.

Quick poll: Who here would assume the GPLv2 is 'similar' to the GPLv3 if you didn't read this site and didn't know 'signed binaries' was one of the big GPLv3 changes?

They may not be required to hand over the keys since it's not their distribution. I get the feeling they just don't want anything to do with the ensuing shitstorm that would come down from signing GPL3 code and giving it to someone else to distribute.

Re:So "no" then.

[Goaway]

MS was handed something to sign, it signed it. If there are distribution limitations on the thing signed, that is not MS's problem, because MS IS NOT DISTRIBUTING IT.

They are distributing it to you when they give it back to you after signing. At that point, the GPL3 specifies that MS must also give you the key.

When you distribute it further, you must then pass that key on to anyone you distribute to.

Re:So "no" then.

[DavidTC]

They are distributing it to you when they give it back to you after signing.

Erm, no, they are not. That is not how signing works. They get a binary, they give you a signature back, which you then embed in the binary. They do not give you an actual binary back, that would be stupid and pointless.

At that point, the GPL3 specifies that MS must also give you the key.

And that wouldn't be true even if they gave you the binary back. MS is not magically bound by the GPL because you copied a file to them and then downloaded it back from them.

Hey, look, everyone, I can bind MS to the GPL by writing a GPL program, compiling it, putting the binary on SkyDrive, downloading a copy back, and now MS is bound to distribute the source of that binary for 7 years! Mwhahahaha!

Uh, no. Just no. If the copyright holder asks someone else to make a copy and to distribute it back to them (Or to anyone else), that copy is ipso facto legal and does not require MS agreeing to any sort of license. That is, in fact, the entire premise of what 'copyright' is...the right to authorize copies being made.

This, of course, pretending that putting a copy into a machine of someone else's and having it make a copy means that other person made the copy. This is not actually true. If MS owns a signing machine, and the way that signing machine works is to make copies, and I put something in it, I made the copy, not MS.

tl;dr: Getting a binary signed does not involve distributing copies. And even if it did, legally those copies were made by the person who put the binary in the signing machine not MS. And even if MS counted as the one making the copies, they're obviously allowed to do that upon request of the copyright holder so don't need to agree to the GPL to make copies.

Re:So "no" then.

[DavidTC]

No, this is not a 'helpful message'. In fact, it's extremely unhelpful, because it does not explain what the problem is, and does not explain what 'similar licenses' are. As I said, the GPLv2 is a 'similar license' to GPLv3 by almost anyone's definition, but it's fine to use.

A message saying 'Note: The GPLv3 section X.Y prohibits redistribution of signed binaries without the signing key. As you will not receive a copy of the signing key, you cannot comply with that. Thus you will need to use a different license like the GPLv2 or the Ms-RL(1) if you wish to redistribute signed binaries. Other OSS licenses may have similar restrictions, please read them carefully. Click to continue.' is a 'helpful message'.

Saying 'Click to certify that this is not licensed under GPLv3 or similar open source licenses.' is not a helpful message, and is pretty clearly there to cause FUD.

It doesn't explain the issue, it doesn't bother to mention the problem is specific to GPLv3 and GPLv2 is fine, and it doesn't even explain things enough to let you check the GPLv2 or other licenses.

And there is no reason anyone needs to 'certify' anything, MS legally doesn't give a damn whether or not you follow the GPLv3 or not, and is no more liable for your GPL violation because they signed a program than if you compile GPL-violating binaries using their compiler.

1) Note I would have no problem with MS plugging their own OSS license as an alternative to the GPLv3, and I actually find it somewhat funny they failed to mention whether their own open source license would be a 'similar open source license'. I guess it would have looked really bad if they had mentioned the Ms-RL but not the GPLv2, and FUD was more important than reassuring their own developers that it was okay to use their own services. ;)

Re:So "no" then.

[DavidTC]

I get the feeling they just don't want anything to do with the ensuing shitstorm that would come down from signing GPL3 code and giving it to someone else to distribute.

It would be incredibly stupid to blame MS for that. Now, of course, there will always be idiots on the anti-MS side who will blame them for anything...but, uh, those people will blame them for anything, so who the hell cares what they think? And refusing to sign binaries for a random reason looks just as bad to those people, so there is no actual way for MS to win.

In the real world, MS did not write the GPLv3, so can't possibly be blamed that the GPLv3 is incompatible with their binary signing system. (Which existed long before the GPLv3) Some people might decry the entire code signing system, which is, in fact, the reason the GPLv3 has that clause in it, and that's fine, but no one can complain that MS isn't giving out their own private signing keys, that would just be stupid and make the entire system pointless.

The real question is: Why does MS care enough to make people certify anything? Heck, MS has no reason to even know the license of the code it's signing.

In fact, legally speaking, they'd probably be better off refusing to know anything about what they were signing except what it does. The second they start trying to be the license police, they find themselves in dubious legal waters if they miss a violation. They're signing that binary code does specific, safe, things, not that someone has the right to redistribute it.

But MS using that opportunity to spread FUD about the GPLv3 and 'other similar open source licenses' and making people 'certify' they aren't using them (Instead of actually explaining what is going on, and not making people 'certify' anything, which is nonsense.) looks bad to those of us who aren't rabid anti-MS but do still remember MS's history.

Call us the 'MS-wary', and we remember this is exactly the sort of bullshit attacks on OSS that MS liked to do. MS and OSS are on fairly good terms right now, and there's generally cooperation...but this is either FUD, or it is accidentally indistinguishable from FUD, and is not acceptable, and needs to be changed.

Hey, why do they single out 'open source' licenses anyway? Surely there are commercial licenses that would have problems with signing. Somehow those are not mentioned.

Give bootloader signing to a third party!

[linebackn]

Bootloader signing must be controlled by a neutral third party. Not Microsoft. Anything less is simply anticompetitive and will end badly.

Reading between the lines, you can clearly hear Microsoft management waffling around muttering "Uh, we need to find a way to fuck open source harder"

in the long run...

[DriveDog]

Even if MS assured everyone that cooperating was in its own long term best interest, and even if we all believed that, believing that they would actually cooperate is foolish. Have we not all heard of The Scorpion and the Frog?

will not boot whatever you want

[Chirs]

When running in secure mode the system will run only code signed by your distro. If you want to run arbitrary code you need to install your own keys and sign your code or else disable secure boot.

Windows 8 is cheap...

[Anonymous Coward]

... so maybe its time to stop buying it on OEM install? Seriously, when Win 8 is only what, $60 retail? I might as well buy a totally unlocked laptop from System76 and then install Windows 8 as the secondary OS. In contrast to the old days, when I would typically go for the cheap OEM Windows license, then install Linux on it.

Why go through Microsoft to run software we want?

[Prozzaks]

Please lease explain again why we need to go through Microsoft to run the software
we want on the hardware we bought?

I can understand why so many hardware vendors jumped into Microsoft's ploy.
To be able to sell hardware certified for Windows 8, they need to implement
Secure Boot and be able to put a little sicker on their product. However, I
don't trust all hardware vendors to also implement the means for users to add
their own keys or to disable Secure Boot altogether.

Regardless, if Microsoft goal is truly to prevent malware from contaminating
the system's boot process, why do they care about the license of the
bootloader? For me, this clearly demonstrates that Microsoft isn't just doing
this to thwart some malware, but that they have ulterior motives. Making it
more difficult for users to run anything other than the software they sell looks
like a pretty good thing from their business point of view.

What rubbish

[Trogre]

What clowns thought that giving Microsoft, I mean, Microsoft, the keys to PC bootloader was a good idea?

Re:What rubbish

[smash]

No one gave microsoft anything. They are simply requiring compliance with secure boot to get a made for Windows 8 logo. Don't want secure boot? Don't build/sell/buy hardware with it.

Re:What rubbish

[shutdown -p now]

Users, for whatever reason, want to buy hardware that has "Designed for Windows" logo stickers on it. So, OEMs want those stickers. To get them, they have to pass a certification program. For Win8, part of that program is that the hardware in question must have UEFI with Secure Boot, which must be turned on by default (but must also have an option to be deactivated by the user).

only in this case

[Chirs]

The Linux Foundation pre-bootloader will boot anything (including unsigned OS's) so they use the "present user" test to ensure that they don't become a vector for installing malware (and thus get the key revoked).

The "proper" RHEL/Fedora/SuSE distros will have their own signed bootloader which will only boot distro-signed OS code. These will presumably support automated installs.

bah...correction

[Chirs]

As noted above, the Linux Foundation pre-bootloader will use a "present user" test, but will then install anything.

The RHEL/Fedora/SuSE bootloaders will not have a "present user" test, but will only load distro-signed OS code.

Nope....not signed by the actual root key

[Chirs]

It's signed by a key "rooted" in the generic key. If leaked, Microsoft would just revoke that key.

What is "secure boot" all about?

[Anonymous Coward]

Is it there for security? Or just to protect Micro$oft's monopoly?

There is no need to guess, there's a very simple test: Can the user and owner of a computer decide what runs on her computer?