Red Hat Clarifies Doubts Over UEFI Secure Boot Solution

sfcrazy writes "Red Hat's Tim Burke has clarified Fedora/Red Hat's solution to Microsoft's secure boot implementation. He said, 'Some conspiracy theorists bristle at the thought of Red Hat and other Linux distributions using a Microsoft initiated key registration scheme. Suffice it to say that Red Hat would not have endorsed this model if we were not comfortable that it is a good-faith initiative.'" Color me unimpressed, and certainly concerned: "A healthy dynamic of the Linux open source development model is the ability to roll-your-own. For example, users take Fedora and rebuild custom variants to meet personal interest or experiment in new innovations. Such creative individuals can also participate by simply enrolling in the $99 one time fee to license UEFI. For users performing local customization, they will have the ability to self-register their own trusted keys on their own systems at no cost." From what I can tell, the worst fears of the trusted computing initiative are coming true despite any justifications from Red Hat here. Note that the ability to install your owns keys is certainly not a guaranteed right.

Comments

So where's the security?

[TheRaven64]

If anyone can pay $99 to get a key that lets them install malware in anyone's firmware, then there is obviously no security in the system. I'd have thought this would be excellent grounds for an antitrust investigation...

Re:So where's the security?

[ledow]

The point is probably that it wouldn't be "anyone's" firmware. What they are saying is that you can get a personal key, which you can manually add to your machines as a trusted key. For $99.

It doesn't mean that you can take you personal key and automatically install it on every computer and thus destroy their trusted boot mechanism or "replace" the Microsoft key with your own. You still can't tamper with the OS on any machine for which you don't have permission or access to modify the trusted boot keys. All you can do is affect machines you already control (i.e. you get to pay for the privilege of installing your own OS on your own computer).

That said, I think Red Hat are being too blinkered here. The whole point of the fight against UEFI is not that you can get a key, it's that you need to be able build machines where you CAN change the key, add your own, or turn off the damn functionality yourself. And those machines need to be the default standard, not some "premium" service available only to the Google's and Dell's of the world.

Hopefully, the whole trusted-key junk will die a death soon or someone will enforce a standard that lets you turn it off. Why *can't* I be given machine that can boot whatever the hell it likes, including legacy OS? That's a question for big businesses that has real implications for keeping their systems running. If I were running a military-grade system, yeah, UEFI boot with trusted keys is a good extra layer to have, but on a home PC (and thus, in ten year's time, everyone's tablets, smarphones, etc. following suit)?

Re:So where's the security?

[gbjbaanb]

that's true, except the scammer would have to first appear legit, I wonder if the russian mafia has any fronts that can do that???

What would be useful is if RH got themselves a key, based on the Microsoft one (and therefore effectively un-cancellable) and then allowed downstream distros (including self-rolled ones) to use it too (yes, you know where I'm going with this).

As there's about as much security in the system as windows update, they might as well do this if they can't scrap the idea completely.

Re:So where's the security?

[itsthebin]

notwithstanding that we have just had news of a major security breach that used Microsoft security certificates

Re:So where's the security?

[Anonymous Coward]

If anyone can pay $99 to get a key that lets them install malware in anyone's firmware, then there is obviously no security in the system

Not really. If you get a signing key, you will be registered, and any malware can be tracked back to you. So "anyone" cannot do this. Only large corporations, with no liability, and lots of money, will be able to install malware from now on. YEAH!

Re:So where's the security?

[drinkypoo]

I wonder if the russian mafia has any fronts that can do that???

I don't know about that, but any government can issue a passport and fake credentials to a person, and make sure they get on the priority visa list.

Re:So where's the security?

[neokushan]

Not quite, summary:

For users performing local customization, they will have the ability to self-register their own trusted keys on their own systems at no cost.

The $99 license is for if you want to distribute yours to other machines. The point is that it's a price that hits a line between "too expensive and will put vendors out of business" and "So cheap any asshat can get one". What it boils down to is the CA correctly authenticating the buyer, if malware vendors get a key signed by them it's the CA's fault.

Now someone who buys a key and recklessly leaves it lying around an insecure place, on the other hand, is a different matter....

Re:So where's the security?

[Hatta]

Microsoft learned after their last antitrust investigation, and increased their political contributions by an order of magnitude, without changing their business practices at all. Now that Microsoft has paid the appropriate protection money, they can do whatever they want.

Re:So where's the security?

[vlm]

So "anyone" cannot do this. Only large corporations, with no liability, and lots of money, will be able to install malware from now on

Luckily large corporations never have data breeches, so its not like you'll be able to go to wikileaks or pirate bay to get a copy of the MS secret key, or the Dell key, etc.

That large integer will of course be made illegal, so only private citizens will have unsecured systems. The hard core crooks and the slightly-bent will of course have free reign over everyones system.

I'm sure they'll be another moronic legal battle where some 256 bit or 2048 bit or whatever integer is declared persona non-grata on the internet, stupid restraining orders, blah blah blah, all over again.

Who wants to buy a tee shirt with Microsofts UEFI secret key on it? I give it a couple months till someone releases it, maybe even before the hardware hits the shelves, and a couple hours later I'll fetch it from pirate bay or whatever, and a couple hours later I'll put up a shirt design. Just to be a complete A-hole I'll also make shirts that have equations, too, so it'll be something like 32523136136 minus 1.

I'll go further with my prediction. Malware will be found signed with a legit "major corporate" key BEFORE legit hardware/software using "major corporate" key hits the shelves, in at least one instance. In other words your new Dell, for example, will be ownable before you can even buy it.

Re:So where's the security?

[vlm]

Oh genius hits milliseconds after I hit the Fing submit button... A tee shirt with a QR code of the official microsoft secret signing key with iconic 1984 or maybe animal farm styling.

Coming soon, from VLM enterprises...

Re:So where's the security?

[betterunixthanunix]

the scammer would have to first appear legit

Microsoft: What do you think gives you the right to install your own bootloader, Mr. Mafia Guy? Scammer: I am deploying my own Linux Distro! Microsoft: $99 please!

Re:So where's the security?

[Anpheus]

You're confusing the keys that have previously been publicly available and the private keys here. Unlike the previous keys, this isn't part of a DRM scheme where the user has to be able to decrypt content and simultaneously "not have" the key to do so. DRM is fundamentally flawed in that regard, and DRM schemes are routinely broken because they cannot both obscure the content and show it to you at the same time. At some point, your computer has to possess the ability to unlock the next frame, and smart people figured out how to copy that. Ta-da, AACS key, or HDCP master key. Those weren't failures of public key cryptography, they were leaked because the universe is at odds with DRM.

What private keys of note have been hacked? Recently, a weak Microsoft intermediate certificate key was exploited to use to generate code signing certs, but that was a weak key with a poor algorithm (MD5 hashed thumbprint). Or Sony's private key for the PS3? Well, they implemented their crypto wrong, one of the supposed-to-be-random parameters was instead hardcoded as a constant. Oops.

Dell, Microsoft, the big players, they all work very hard to make sure their private keys are secure. Would you care to take a wager on whether or not the Microsoft root key will be released within the next year? (By root I mean whatever key is the common root used to sign a plurality of UEFI signed bootloaders, if they use many intermediate CAs, it would have to be whatever key is for all of those CAs. If they use one intermediary that signs a majority of the bootloaders, then it must be that one - does not have to be _the_ Microsoft key.)

Re:So where's the security?

[betterunixthanunix]

If you get a signing key, you will be registered, and any malware can be tracked back to you. So "anyone" cannot do this.

So all it really takes is a stolen credit card?

Re:So where's the security?

[Anonymous Coward]

What it boils down to is the CA correctly authenticating the buyer, if malware vendors get a key signed by them it's the CA's fault.

Don't worry! They will swiftly disclaim all liability and describe their service as "best effort only" long before issuing these keys. See, they thought of that just like you did.

A little background: CAs are not known for their thorough application of due diligence when it comes to "authenticating" people who want to give them money. I mean some are better than others but it's not going to remove the need to maintain good host security. Besides, assuming UEFI perfectly prevents all malware from modifying the OS (installing rootkits etc), that won't protect you from malware that can run as unprivileged users.

Re:So where's the security?

[Anonymous Coward]

I sure am glad that there have been so many incidents to solidify my faith in CA actions over the last year...

Re:So where's the security?

[Anonymous Coward]

How does this affect those of us that support family members computers?

I for one, support a number of computers that I don't _personally_ own, but eventually will have to do OS upgrades or reinstalls due to Malware/Virus infection.

Does this mean I will have to get a key for A) each machine, or B) everytime I reinstall?

This has not been made clear, and really would like to see the option to shut this mechanism off.

Re:So where's the security?

[Vanderhoth]

Dude, I'd buy that shirt. Seriously not joking, I'd buy that.

Re:So where's the security?

[MickyTheIdiot]

Not to mention that you have one of two choices if a key is breached:

1) The hardware is forever "untrusted" or

2) You have to put in a way to *easily* (i.e. not some BIOS procedure magical to the user) fix breached keys, in which you necessarily create a way for malware writers to install their own key.

BRILLIANT. Well thought out, M.S... as always.

Re:So where's the security?

[MickyTheIdiot]

Money equals Speech therefore corporations can scream the loudest by far.

Re:So where's the security?

[Anonymous Coward]

Actually, this is not quite correct. For ARM systems, Windows forces hardware manufacturers to make it IMPOSSIBLE for someone to install another OS. (It's in their license for Windows 8)

Re:So where's the security?

[Rogerborg]

If anyone can pay $99 to get a key that lets them install malware in anyone's firmware, then there is obviously no security in the system

Oh, tish, where would organised criminals come up with that amount of money?

Re:So where's the security?

[ZeroSumHappiness]

The software you put on the machine should be signed. So long as you use signed software the whole thing is a no-op for you. If you want to install a Linux distro that has not been signed with Microsoft's keychain, however, you'll have to either turn off secure boot or install that distro's key into the UEFI.

Re:So where's the security?

[ZeroSumHappiness]

RH considered this but decided that they don't want to take on the job of vetting all those downstream distros that want to use their key.

Re:So where's the security?

[ZeroSumHappiness]

Yes, because it's completely impossible to fake up your registration details.

Re:So where's the security?

[ArsenneLupin]

There are attacks other than mathematical or algorithmic. What do you want to bet that Microsoft's key management infrastructure is lacking, and is accessible to temps and students who only stay there for 6 months. Somebody is going to sneak away the key on an USB stick, and release it into the wild after they have long left Microsoft. And on which one of the thousands of students who passed by during that time will they pin the blame?

Re:So where's the security?

[vlm]

There are attacks other than mathematical or algorithmic.

Financial? somebody@something.ru offers $100K to someone at microsoft.com who is being outsourced to India to ... plus or minus an order, or two, of magnitude.

Religious/political? Somebody of a certain religious persuasion is contacted by a guy on line who convinces him that the only way to save *.il from a second holocaust is to provide the secret signing key to enable the stealthy deployment of stuxnet 2.0 to really shut down the iranian nuke program this time. Of course the guy doing the convincing is secretly J Random Malware Author, whoops. Or maybe he really is from *.il and he really is preventing a nuclear holocaust using the key, but his kid / coworker / ex wife / competitor / guy trying to set him up to take the fall / something else releases the key to the public. Or he just loses the thumbdrive with the key. Or the story for plausible deniability, is he loses the thumbdrive containing the key and another dude just happened to find it, although in reality it was all scripted out.

You trust *.microsoft.com to keep it safe, well that's a little optimistic of you, but whatever. The problem is the random collection of "friends of microsoft" in the govt and govt contractors trying to write undetectable cyberwarfare software. So now you have to trust all of *.mil and quite a bit of *.com not to screw up.

Re:So where's the security?

[badfish99]

So I'm a philanthropically-minded linux user with $99 to spare. I give that money to Microsoft, and they give me some magic key that lets me write linux kernels that will run on anyone's machine. I immediately publish that key on my website, for anyone to use. Now any criminal can use this key to run their malware on any machine.

Obviously it doesn't work like this, or the whole scheme would be useless. So how is it going to work?

I read TFA, and as far as I can tell, it *does* work like that: for $99, I get my key sent to the hardware vendors to be put into their UEFI boot chips. So will everyone get a free "bios upgrade" when I deliberately leak my key?

Re:So where's the security?

[vlm]

Oh how about this political attack - I predict the key used for all Chinese military cyberwarfare will be the Lenovo key.

Another "fun" thing to think about - what happens during bankruptcy, purchasing, downsizing, etc? Who owns Gateway now, or rephrased, who owns Gateway's key? If you want a legit key, the best way might be to legit buy it.

Re:So where's the security?

[neokushan]

Who said UEFI was a magic bullet that protected you from all kinds of malware? Nobody did, nobody is dumb enough these days to say that their security is unbreakable. The point is to make it harder, the harder you make it then the less likely someone will break it. There will always be one person smart enough to get around it, (or someone dumb enough to let them in) but the alternative is just giving up.

As for the CA's, be thankful of all the recent exploits of them because now that we know they're the weak link, we can regulate the shit out of them. Don't do your job right? We'll shut you down and give your authority to someone else. I'm not saying that's what's going to happen, merely that it's what should happen.

Re:So where's the security?

[neokushan]

This is a good point and I would also like to know how it works. Keep in mind though, UEFI and BIOS are two separate things and many of the limitations of BIOS don't apply. There's no reason why your OS shouldn't be able to add or revoke certificates while running, in much the same way that a good UEFI motherboard lets you overclock and adjust settings on the fly, in Windows (And possibly other OS', I cannot comment on that).

If that's the case, then a leaked certificate is no worse than it is today - your OS just updates the certificate store.

Re:So where's the security?

[neokushan]

This is true and I completely agree that it's wrong in every way. Then again, it's no different to current Windows Mobile devices which is why Microsoft will probably get away with it.

To me, it's not much different to HTC locking their bootloaders either, but most Android manufacturers at least offer a way to unlock them.

Re:So where's the security?

[bws111]

Untrue. The requirement is that secure boot can not be disabled. If you have a signed bootloader (like one from Red Hat, Fedora, or any other distro that pays the $99 to use this service) you can boot any OS you want.

Re:So where's the security?

[ArsenneLupin]

Oh how about this political attack - I predict the key used for all Chinese military cyberwarfare will be the Lenovo key.

Another "fun" thing to think about - what happens during bankruptcy, purchasing, downsizing, etc? Who owns Gateway now, or rephrased, who owns Gateway's key? If you want a legit key, the best way might be to legit buy it.

Just a small note: they key belongs to the OS, not the hardware. The hardware just checks the OS key, but isn't signed itself.

So, you couldn't usurp the key of a failed (or nationalized) PC maker. You'd have to use the key of a failed OS instead.

Re:So where's the security?

[hairyfeet]

But the whole damned thing comes down to an argument that doesn't make any damned sense! To install an OS you need to go into BIOS anyway because you have to select the boot order so the ONLY difference on a machine with secure boot is you change ONE more setting while you are there. that's it, that is all you do, you flip a setting setting from secure boot to no secure boot.

Lets face it IT WOULD NEVER WORK ON LINUX ANYWAY because the kernel changes too damned fast and the key would be tied to a particular kernel so for Linux the whole thing would be completely pointless. It is NOT pointless for Windows as Windows does NOT change its kernel so for THAT OS AND THAT OS ONLY it can be used to keep rootkits out of the kernel.

So the whole damned thing is just bitching for the sake of bitching, the ONLY way it would do a damned thing for a Linux OS is if you have a dumb as fuck PHB that wants a checkbox AND you have a Linux that never changes the kernel. Its been years since I looked at RHEL so maybe they never change the kernel and it would be worth it for them, I don't know, but I find it seriously hard to believe that someone would be smart enough to 1.-Know what Linux is and that they want it, 2.-download and burn an ISO but 3.-Too fucking stupid to flip a single switch in BIOS. I'm sorry folks but that just doesn't compute, if you are smart enough to download and burn ISOs you are smart enough to flip a damned BIOS switch.

And I'm sure if you are buying enough boxes that you need to flip the switch on multiples you will be able to buy them pre-flipped from the factory or if you are a lazy type just hire a damned college kid for a day or two to flip the damned switch. That is what i used to do when we had low level IT grunt work, its good for the economy and helps out a kid.

Re:So where's the security?

[psm321]

Except that Microsoft is already forcing some vendors to eliminate "the damned switch" and will almost certainly make more do so in the future, under the guise of "security".

http://linux.slashdot.org/comments.pl?sid=2898709&cid=40232929

Re:So where's the security?

[mpe]

Or Sony's private key for the PS3? Well, they implemented their crypto wrong, one of the supposed-to-be-random parameters was instead hardcoded as a constant. Oops.

Was this before or after someone did the same sort of thing in Debian? Getting crypto correct is hard, even with OSS, where proprietary software is involved it's likely to be several orders of magnitude harder.

Re:So where's the security?

[mpe]

You trust *.microsoft.com to keep it safe, well that's a little optimistic of you, but whatever. The problem is the random collection of "friends of microsoft" in the govt and govt contractors trying to write undetectable cyberwarfare software. So now you have to trust all of *.mil and quite a bit of *.com not to screw up.

Probably best not to assume that such "friends" will be confined to the US (and Israeli) governments either. Or that "friends of friends" or "friends of friends of friends" will not also be a potential issue.

Re:So where's the security?

[mpe]

Oh how about this political attack - I predict the key used for all Chinese military cyberwarfare will be the Lenovo key.

I predict that the Lenovo key is more likely to be used by those who don't like the PRC. The PRC military would be more likely to use the key of an ROC company.

Re:So where's the security?

[dew_the_fifth]

Even if the key is stolen as you predict, then the net result is that any program can install itself as part of the boot process, and we've done nothing but return to our current state. If however, the key is kept protected or some malware fails to use it, then we have a more secure boot process. Note that I've said more secure, and not secure.

Re:So where's the security?

[dew_the_fifth]

As a CA, MS will revoke the certificate. This will not help already infected machines, but will instantly protect any machines not already infected by removing the certification of the malware. Think SSL when a site has been compromised, and remember that if the scheme fails we are simply back where we started.

Re:So where's the security?

[Microlith]

I'll believe what you say when I see an ARM tablet running Windows 8 booting Fedora directly.

Re:So where's the security?

[Lonewolf666]

ARM is bootlocked (as are IOS and quite a few android devices). Try to keep up.

An interesting difference is that Microsoft makes bootlocking a requirement for other vendors to get their hardware certified for Windows.
See also http://www.softwarefreedom.org/blog/2012/jan/12/microsoft-confirms-UEFI-fears-locks-down-ARM/.

I guess Microsoft's approach could be viewed as a form of "exclusive dealing" as defined by Wikipedia (http://en.wikipedia.org/wiki/Exclusive_dealing), because it excludes other operating systems from being used with Windows-certified tablets.

That looks pretty anti-competitive to me, and I hope the EU jumps on them for this. Aaron Williamson (see softwarefreedom.org link above) thinks it won't happen in the US, but the European Commission seems to have a somewhat wider concept of what is unacceptable. They also are not afraid of stepping on some corporate toes. Which includes European corporations, as the auto industry found out the hard way ;-)

Re:So where's the security?

[Just Some Guy]

I'll also make shirts that have equations, too, so it'll be something like 32523136136 minus 1.

Without verifying, I'm fairly sure that's not prime.

Re:So where's the security?

[psm321]

And there's nothing preventing them from extending this to other platforms like they're mandating it on ARM. You try to keep up.

Re:So where's the security?

[AmiMoJo]

It doesn't say you can't let the user add their own certs and self-sign either. Slightly more work for us but much more security for the clueless majority.

Re:So where's the security?

[shutdown -p now]

I'm sure that governments wouldn't need fake credentials in the first place.

Re:So where's the security?

[gbjbaanb]

depends how rigorous the vetting process is, it could be really strict, or it could be about as good as, say, verisign's validation methods.

Re:So where's the security?

[snakeplissken]

are you here all week?
should i try the fish? :)

Re:So where's the security?

[bws111]

It does not work like that. Here is a very simplified overview of how it works:

Someone writes a bootloader. That bootloader gets digitally signed.

At boot time, UEFI finds the bootloader, and verifies that it was signed by someone trusted by the UEFI, and that the code is intact based on the signature.

If the above test passes, the boot loader is loaded, and UEFI uses TPM to leave a trace that UEFI (signed by x) says that the boot loader is OK. Control is passed to the boot loader

The boot loader finds the next thing in the boot sequence (kernel, probably) and performs the same validation of it and leaves another TPM trace that says the bootloader (signed by y) says the kernel is OK.

This process repeats with everything that is loaded, right up to the application.

At any point, a piece of code can use TPM to check all of the traces leading up to itself. If any of those traces were made by someone you don't trust, the whole thing can be considered to be untrusted.

So, in your scenario, you give your $99 to Microsoft, and get a key that can be used to sign your bootloader. If you want, you can hand that key out, and anyone can sign a bootloader, including malware writers. However, just because someone verified that your bootloader was not tampered with (ie UEFI verifying the signature) does not mean that anyone has to trust your bootloader. As soon as the Windows kernel gets running and checks with TPM and finds out that the bootloader was signed by badfish99 it can switch into 'untrusted' mode, whatever that means. And if you somehow manage to replace not only the bootloader but also the kernel, the next thing loaded can find out that the kernel was not signed by someone trusted. And so on. In order to effectively install something untrusted without being detected you pretty much have to replace the whole system, from bootloader to applications and everything in between.

Re:So where's the security?

[chrb]

What private keys of note have been hacked?... Dell, Microsoft, the big players, they all work very hard to make sure their private keys are secure.

That I can remember right now:

* ASUS secure boot key
* JMicron and Realtek Windows driver keys
* RSA's SecurID seeds
* Yahoo's private key for signing plugins
* Motorola's bootloader key
* HTC various engineering bootloaders (not an actual key, but signed bootloaders that allowed chainloading of non-signed code, which is just as good as a key in this case)

Funnily enough, I used to have legitimate access to a private key that could be used to load firmware onto a certain brand of credit card payment terminals. So did hundreds of other developers over the years - the key was required to do any form of development, but once you had it, you could reprogram any device in the field to grab card details, pin numbers, modify transactions etc. It was only the goodwill and honesty of the developers that prevented the key from being leaked. I'm sure there are some companies that work hard to protect their private keys and hold those with access accountable, but there are also those who handout private keys to internal staff and contractors alike.

Re:So where's the security?

[bws111]

It does not exclude anyone from doing anything. It simply says that secure boot can not be disabled. You can run whatever you want, as long as it has a signed bootloader.

Re:So where's the security?

[hairyfeet]

And the difference between them and Apple IS....what? I didn't hear the FOSS crowd screaming bloody murder when Apple did it so frankly you have no right to complain when Ballmer just apes Apple, especially since as CEO he has shown time and time again aping is the only thing he knows how to do.

And don't pull that monopoly horseshit, because MSFT has less than 5% of the ARM market which is as opposite as one can get from a monopoly. Again if anything that word should be directed at Apple as they own the PMP market and have enough clout with the appstore to affect the prices COMPETITORS get when it comes to eBooks. Remember one doesn't have to have 100% to be considered a monopoly, only to be able to use your power in one market to unduly influence another, which Apple has been doing lately in the eBook arena. MSFT's desktop power don't mean jack shit in mobile which is why WinPhone 7 went absolutely nowhere, as power in the X86 market don't mean shit when we are talking ARM.

And finally WHO THE FUCK CARES as its not like FOSS guys are gonna buy the damned thing anyway! it would be like complaining about where the ashtray is on an SUV you have ZERO intention to buy, it doesn't affect you in the slightest so get over it. There are a bazillion ARM devices out there that aren't locked down, hell in ARM because anybody can license and build their own CPUs you have everything from little home grown projects like the Pi to big companies cranking out Android tabs, the market as far as hardware is wide open.

So even if it was a hit it wouldn't do shit about changing the market, the absolute BEST they can hope for is 20%-25% simply because of how much competition there is already out there. In X86 it would matter as there is only 2 companies that make X86 units (Via is supposedly still making chips but you never seem 'em) but since secure boot is REQUIRED to be easy to bypass the entire question of lock in there is moot. So seriously, get over it. if you don't like it build a better mousetrap, make a tablet that kicks Apple's ass and kick back and enjoy your rewards. MSFT has never been and most likely never will be a major player in ARM so its pointless to get your panties in a wad over a niche device that hasn't even been released yet and will be lucky if it gets double digit sales.

Re:So where's the security?

[MarcQuadra]

> the kernel changes too damned fast and the key would be tied to a particular kernel

That's not true, and it's not how it would work.

Your distribution will be able to package signed bootloaders (GRUB) and kernels. The kernels from your distribution should work fine as long as they Play The Game (which I suspect some, like Debian, will not).

As for the 'kernel changing too damned fast': First, you should know that Windows kernels are ALSO updated between service packs, the Windows kernel components change fairly frequently. Second, the kinds of distributions that get used in managed environments (like RedHat) don't get changed often at all, maybe twice a year. RHEL is still running patched revisions of 2.6.32 from January 2010.

I suspect that in the future, we'll have to 'root' our computers just like we have to root our phones today to load alternate firmware.

Re:So where's the security?

[MarcQuadra]

Actually, there is. Microsoft is prohibited from doing this on x86-based stuff by the antitrust agreement they're in. They can't prohibit vendors from allowing other operating systems and locking-in 'wintel' hardware/software. The agreement does NOT cover ARM.

Re:So where's the security?

[Alex Belits]

UEFI and BIOS are two separate things

No.

Re:So where's the security?

[bws111]

Not true at all. First, this is not about installing firmware, it is about boot loaders. Second, there are two issues involved in secure boot: authentication and trust.

The authentication part is what the key and UEFI are doing. UEFI is simply making sure that the bootloader is signed by someone it trusts. In other words, the bootloader has not been modified since being signed.

The trust part is checked by the thing being loaded by the bootloader. As soon as the Windows kernel comes up it can check with TPM and find out it was loaded by an unmodified boot loader signed by TheRaven64, and say 'who the hell is TheRaven64? I don't trust him'. That is where the security comes in. If that chain of trust is broken anywhere from UEFI up to the application then the system is untrusted.

It is sort of like having a document notarized. I can write a document that says I am the rightful king of the world. I can take that document to a notary, and they will put their seal on it saying that in fact it is I who have signed the document. However, just because you know that the document is authentic does not mean you have to believe what is in it.

Re:So where's the security?

[freeweaver]

People who want to infect computers for whatever reason, do it because they benefit. adding secure boot does not thwart their desire to benefit, thus, they simply change tac. So "Secure Boot" will do absolutely nothing to make Windows computers safer, as it does not change the cause of the problem.

But Microsoft people already knew this. I mean lets face it, they don't get to make the decisions for a massive corporation unless they have at least a few braincells.

So now, anyone who wants to distribute their own linux, which historically is what drives innovation amongst the free software world, must pay $99 to a CA through Microsoft. A company who always has been, is now, and always will be, looking for a way to undermine competition.

ITS FUCKING GENIUS!

>>>>>coreboot gets my vote!

Re:So where's the security?

[PhunkySchtuff]

Anyone can pay $99 to get a key that lets them install software in their own firmware. Their key needs to be loaded into the UEFI firmware first before they can load their signed software in as well.

Loading your keys into my firmware will be considerably more difficult than getting malware to me to try and run.

Re:So where's the security?

[segedunum]

Untrue. The requirement is that secure boot can not be disabled. If you have a signed bootloader (like one from Red Hat, Fedora, or any other distro that pays the $99 to use this service) you can boot any OS you want.

Which is the point the OP was making. Someone has to pay for you to get the OS you want to run on your hardware, and they have to say yes to it, and they have to keep saying yes to it for every new piece of hardware. I wish people would stop making these crap throwaway comments that have nothing to do with the absolute central problem with this. They are not interesting or insightful in the slightest.

Re:So where's the security?

[Alex Belits]

the owner of the X86 machine is allowed to install his own keys or bypass completely at his/her discretion.

The problem is, there is no way to prove to the machine that you are its owner. Until there will be a mandated big red physical switch that unlocks the key installation procedure while the box is running (everything else is hopelessly obfuscated), the device is effectively tivo-ized or worse.

Oh, that's hairyfeet, our resident Microsoft marketing representative...

Re:So where's the security?

[Alex Belits]

by the antitrust agreement they're in

It's expired.

Re:So where's the security?

[Forever Wondering]

Actually, this is not quite correct. For ARM systems, Windows forces hardware manufacturers to make it IMPOSSIBLE for someone to install another OS. (It's in their license for Windows 8)

Now that would be grounds for antitrust.

Re:So where's the security?

[KingMotley]

In the interest of freedom of choice, some users may not want to utilize this secure boot capability. In the UEFI system menu, they are able to disable the feature and things should operate like they do currently.

I know it's impossible to expect people to read the article, so I quoted the relevant portion here.

Re:So where's the security?

[hairyfeet]

And here's Alex, resident FOSSie whackjob. First of the month, out of your meds already? Sadly you should take them as then you might be able to actually use logic because all of that is documented in the UEFI spec. It says that if you have physical control, then guess what? YOU are the owner! I know, what a concept, right?

You see this is why I enjoy laughing at FOSSies, just like the religious nutters even the tiniest bit of logic blows away your arguments. Your "talking points" are nothing but the classic circle of loon, in fact every argument you've EVER presented here can be covered in the top 10 TM repos because THAT is how predictable they are.

So go back to your circular logic and your magical mystical all powerful OS oh and DO be sure to ask MSFT for a check, because frankly your kind of batshit does more to sell Windows than a dozen powerpoints or even a lecture from RMS because it is YOU sir that make the entire Linux community look about as sane as the guys talking about the lizard people on Above Top Secret. Way to go there Sparky, way to make FOSS look like a bunch of crackpots and conspiracy theorists.

Re:So where's the security?

[psm321]

I've always hated how consoles have this killer hardware that is so locked down i can't do a damned thing with it that isn't approved by the corps without breaking out a soldering iron and a modchip. But that doesn't change reality and that is reality. Don't take my word for it, talk to the people in front of you in line somewhere and see what THEY say, they'll tell you "Its a phone" or "Its a tablet" which to them means its a device NOT a computer.

And you honestly don't think Microsoft (and Apple and Red Hat and Canonical for that matter) are trying to take computers in EXACTLY that same direction with app stores, Windows 8 apps, Unity, TPM, etc.? Mark my words, if we don't stop the movement in this direction, computers WILL be "just an appliance". The lack of foresight burns.

Re:So where's the security?

[Alex Belits]

THIS IS WHAT MICROSOFT EMPLOYEES REALLY BELIEVE.

Sane and intelligent people look like wackjobs to them.

Re:So where's the security?

[reve_etrange]

To install an OS you need to go into BIOS anyway because you have to select the boot order

I believe many systems are still shipping with the CD-ROM drive at highest boot priority.

Re:So where's the security?

[reve_etrange]

You don't have to verify it somehow, it ends in 5.

Re:So where's the security?

[exomondo]

Now that would be grounds for antitrust.

Why? Windows RT has no marketshare, in fact Windows has virtually no presence on the ARM platform at all, anti-trust requires a monopoly position which MS does not have on ARM nor is their ARM version of Windows tied to their x86 version so there is no leverage of monopoly position either.

Re:So where's the security?

[exomondo]

The problem is, there is no way to prove to the machine that you are its owner. Until there will be a mandated big red physical switch that unlocks the key installation procedure while the box is running (everything else is hopelessly obfuscated), the device is effectively tivo-ized or worse.

It's all through UEFI setup, where you can setup custom mode or turn Secureboot off.

Re:So where's the security?

[exomondo]

An interesting difference is that Microsoft makes bootlocking a requirement for other vendors to get their hardware certified for Windows.

So? There's no law against that. No one has to make ARM Windows tablets, they have no market share and they aren't tied to MS's monopoly product x86 Windows.

I guess Microsoft's approach could be viewed as a form of "exclusive dealing" as defined by Wikipedia (http://en.wikipedia.org/wiki/Exclusive_dealing [wikipedia.org]), because it excludes other operating systems from being used with Windows-certified tablets.

Wrong, because it doesn't stop the makers of those tablets from using any other OS, in fact they could use Android on the exact same product! They just can't sell that product as a Windows-certified device.

Re:So where's the security?

[exomondo]

And there's nothing preventing them from extending this to other platforms like they're mandating it on ARM. You try to keep up.

errr...of course there is, it's called anti-trust law. You try to keep up.

Re:So where's the security?

[Kalriath]

Unfortunately, Slashdot doesn't have a "-1, Wrong" moderation.

UEFI is not BIOS, and BIOS is not UEFI. In fact, most brand name computers these days don't even have a BIOS, they have a BIOS emulator running on the UEFI platform.

Re:So where's the security?

[neokushan]

Parent post:

Besides, assuming UEFI perfectly prevents all malware from modifying the OS

My response:

Who said UEFI was a magic bullet that protected you from all kinds of malware? Nobody did

You're right, reading comprehension is a wonderful thing.

Re:So where's the security?

[neokushan]

I just want to clarify one point above - you don't give your $99 to Microsoft, you give it to a CA (I think it's verisign?).

Re:So where's the security?

[vlm]

and we've done nothing but return to our current state.

"Major corporations promised me this boot process is crypto secured, so we don't waste money on anti-virus anymore"

"Yeah, I know his isn't mil-spec hardware, but this is a secure boot system so it must be safe for our 3rd world country"

"So its a life and safety critical controller, so we're using more expensive secure boot hardware instead of cheaper non-secure boot. Oh we just wasted an extra $10 times one million production run, whoops, well I'm sure the CEO won't mind the extra expense"

Re:So where's the security?

[TheRaven64]

Nope. Anyone can install stuff on their own device by just turning off the secure boot mechanism. The $99 buys you a signing key that lets you install your software on anyone's machine. Essentially, paying $99 gets you back to the situation you were in without secure boot being enabled, at least with respect to your software.

Re:So where's the security?

[bws111]

You may have heard of this new thing called 'cryptography'. It means that things like 'captured legitimate TPM traces' are useless.

The whole point of TPM is to prevent attacks such as you describe.

Re:So where's the security?

[spike hay]

FOSS people may have looked like wackjobs 10 years ago, but now we are have a very real steady erosion of openness in computing. It's happening, and UEFI secure boot is another step. The walled garden model of smartphones and tablets is coming to desktops.

Re:So where's the security?

[Just Some Guy]

That was quick.

Re:So where's the security?

[AdamWill]

Well, there's only about ten problems with that.

One, it's not how Secure Boot works. You just can't do that.

Two, why would a sub-key of the Microsoft key not be cancellable? The whole point of sub-keys is they can be cancelled without invalidating the master key.

Three, why exactly would Red Hat want to take on the considerable legal responsibility for everyone else's distributions?

Re:So where's the security?

[AdamWill]

That's for x86. The OP of this sub-thread is correct that the requirements for Windows certification for ARM devices are different.

However, far fewer ARM devices are going to care about Windows certification.

Re:So where's the security?

[AdamWill]

If you did that, the key would be revoked.

People seem to be discussing this as if there'll be some sort of automatic online marketplace where you fill in your credit card details, pay $99, and get sent a signing key that you can use to sign whatever the hell you want. This is not at all how it works. You go through a somewhat onerous registration process, send your code to Microsoft/Verisign, they check it and decide if they want to sign it, and if they think it's okay, they ask you for $99. Then you give them $99 and they sign it. Then you can release it.

Re:So where's the security?

[Forever Wondering]

Now that would be grounds for antitrust.

Why? Windows RT has no marketshare, in fact Windows has virtually no presence on the ARM platform at all, anti-trust requires a monopoly position which MS does not have on ARM nor is their ARM version of Windows tied to their x86 version so there is no leverage of monopoly position either.

If MS put it into their contract, that would be grounds for antitrust. IIRC, they were sued [by the Feds in the 90's] because [amongst other things] they wouldn't allow you access to their developer documentation [which wasn't posted on their website as it is now] unless you agreed to not develop software for any other platform (e.g. Linux, Solaris, etc). As part of the settlement of that case MS agreed to not repeat certain such behavior in the future.

Re:So where's the security?

[exomondo]

If MS put it into their contract, that would be grounds for antitrust. IIRC, they were sued [by the Feds in the 90's] because [amongst other things] they wouldn't allow you access to their developer documentation [which wasn't posted on their website as it is now] unless you agreed to not develop software for any other platform (e.g. Linux, Solaris, etc). As part of the settlement of that case MS agreed to not repeat certain such behavior in the future.

So? That has no relevance to this situation, there is absolutely no requirement that the OEM purchase ONLY Windows for ARM and not purchase from anyone else, in fact they could sell the exact same hardware running Android, it just wouldn't - as you would expect - have a 'designed for Windows 8' sticker on it. There is no anti-trust issue here.

Re:So where's the security?

[reve_etrange]

Is quick 9 hours to get someone to verify it or 19 hours for that person to get the joke?

Re:So where's the security?

[Alex Belits]

And how do you enter it on all those machines?

Re:So where's the security?

[Alex Belits]

UEFI is a standard implemented by BIOS. UEFI implementation is BIOS. There are no "emulators", it's the same old BIOS with UEFI functionality bolted on.

Re:So where's the security?

[exomondo]

With your keyboard.

Re:So where's the security?

[Forever Wondering]

So? That has no relevance to this situation, there is absolutely no requirement that the OEM purchase ONLY Windows for ARM and not purchase from anyone else,

No, that is exactly the requirement that MS does have [according to the original poster].

in fact they could sell the exact same hardware running Android,

No, they could not.

it just wouldn't - as you would expect - have a 'designed for Windows 8' sticker on it. There is no anti-trust issue here.

So, perhaps you know differently. If so, do you have a copy of the contract in question? Or, is your argument based solely on the seeming incredulity that MS would never put anything that nefarious into one of their contracts? The 90's incident is a history that shows that MS will do such things, it was an antitrust violation then, and if it's in the current contract, it's an antitrust violation now.

Re:So where's the security?

[exomondo]

No, that is exactly the requirement that MS does have [according to the original poster].

That's rubbish, the OEM is free to purchase any OS from anyone to use on any of their systems, they just can't run an OS besides Windows on an ARM system that carries the 'designed for Windows 8' branding, which there is no problem with.

in fact they could sell the exact same hardware running Android,

No, they could not.

Why not? There's nothing stopping them, your claim is false.

So, perhaps you know differently. If so, do you have a copy of the contract in question?

What contract?! There is nothing stopping them! If you believe there is something stopping them from doing that then show me proof.

Or, is your argument based solely on the seeming incredulity that MS would never put anything that nefarious into one of their contracts?

My argument is simply that your claim is based on something that doesn't exist, if you believe MS are restricting the sale of this hardware or restricting the ability of a hardware vendor to purchase an OS from someone else then prove it. But you can't, because your claim is rubbish.
The only thing they cannot do (as stipulated in the Windows 8 certification agreement for ARM systems) is sell a device with a 'designed for Windows 8' sticker that runs other OSes and there is no anti-trust issue with that.

Re:So where's the security?

[Kalriath]

No, that is incorrect. The BIOS is the old firmware interface burned into the ROM, not the chip itself. The UEFI is also a firmware interface burned into the ROM, not the chip itself. UEFI software can pretend to be BIOS software, but it is not BIOS software.

Re:So where's the security?

[lsatenstein]

Not quite, summary:

For users performing local customization, they will have the ability to self-register their own trusted keys on their own systems at no cost.

The $99 license is for if you want to distribute yours to other machines. The point is that it's a price that hits a line between "too expensive and will put vendors out of business" and "So cheap any asshat can get one". What it boils down to is the CA correctly authenticating the buyer, if malware vendors get a key signed by them it's the CA's fault.

Now someone who buys a key and recklessly leaves it lying around an insecure place, on the other hand, is a different matter....

I'm retired, I live on $20k per year, of which rent is $12k, taxes and medical expenses $3k, so for me, I guess I must be an asshat.

Re:So where's the security?

[lsatenstein]

Untrue. The requirement is that secure boot can not be disabled. If you have a signed bootloader (like one from Red Hat, Fedora, or any other distro that pays the $99 to use this service) you can boot any OS you want.

Does this include any brand of VM that I want to boot under Linux? A VM wants an emulated UEFI bios. Is it too going to need the certificate?

Re:So where's the security?

[Alex Belits]

No, that is incorrect.

Said Kalriath to a person who actually had a displeasure working on BIOS sources.

The BIOS is the old firmware interface burned into the ROM, not the chip itself

What "chip"? Initially there is no CPU-visible ROM other than BIOS flash, attached to LPC (pseudo-ISA) bus/Intel FWH interface or some equivalent. Before the code in it runs, CPU can't even access RAM. Hell, it can't even run properly because it didn't get Intel microcode updates buried inside the BIOS image.

The UEFI is also a firmware interface burned into the ROM, not the chip itself. UEFI software can pretend to be BIOS software, but it is not BIOS software.

And what, do you think, does hardware initialization on boot, using the code that was piled up over 25 years? What implements idiotic standards such as ACPI? What installs non-removable SMI handlers to mess with your ECC RAM and break your realtime OS? BIOS, that's what! UEFI implementation is a microscopic addition to a festering pile of shit that is PC BIOS. Go, look how they are proud of themselves: http://www.phoenix.com/docs/BridgingBIOStoUEFI_July2007.pdf They taken their BIOS and "made it compatible" by bolting Intel code on top of it. That's the only implementation you will find on anything except, maybe, Apple.

Re:So where's the security?

[neokushan]

Perhaps, but how many times can you really afford to shell out $99? Theoretically (lol, theory and all that) it should be no more difficult to revoke these UEFI certificates than any other certificate system. I strongly suspect it'll get sent via the likes of Windows update. So say you release your $99-signed malware and it infects a bunch of machines, suddenly the machines get updated and your malware is rendered inert and all future installations are stopped dead (aside from those who don't update, but they're a lost cause). Poof, you've just wasted your $99. Now you have to go buy another cert and do it all over again. Unless you're going to make $99 per "release", it won't be worth your time and that's all the point there is.

Re:So where's the security?

[Alex Belits]

I repeat -- dedicated hardware switch accessible by the user. If the intention is to provide security, no other solution is acceptable.

Re:So where's the security?

[hairyfeet]

Uhh...this is the SAME guy that says everyone that doesn't worship at the feet of RMS is a "sekret M$ Ninja" that works in a hidden cove in Redmond to destroy FOSS. The guy is the new twitter without any of twitter's style, he just screams "Shill" while he craps all over himself with impotent nerd rage.

And as far as loss of FOSS "freedoms"...whose fault would that be? its because the FOSS products have frankly been piss poor knockoffs of other real products that we see ourselves in the situation that we are in. Frankly the FOSSies have had 20 damned years to make a better product and the ONLY time they gained is when google bitchslapped them and took Linux away from them and made an actually usable product. Hell Gnome has ripped off Apple's OSX so badly I'm shocked they don't just use their wallpaper while they are at it which is extra hilarious as Linux is a windowing OS while OSX is an application based OS so having a top mounted menu bar doesn't even make any damned sense!

In the end its not a "conspiracy', its not MSFT hiring Ninjas to kill FOSS, its piss poor half baked products that frankly never get any better. look at ANY forum after a release and see how many "update broke my drivers" post you see, i bet my last buck they'll number in the hundreds. there is NO QA, no QC, its ALL half baked and poorly built. they can get by with this in the server space because MSFT charges ass raping prices there, but that shit just won't fly in the consumer space. And if you think I'm a "M$ Ninja" for saying this perhaps you'd like to tell this Red hat developer that says the same thing only nicer he is a "M$ Ninja". For the record MSFT hasn't even given me so much as a T-Shirt, I'm simply not slurping the FOSSie koolaid. if a product works it works, if its shit its shit, and right now Linux on the desktop is firmly in the latter category. As for why read the link above, he lays it out better than I ever could.

Re:So where's the security?

[Kalriath]

Said Kalriath to a person who actually had a displeasure working on BIOS sources.

Which is completely irrelevant. I work on Patient Administration Systems for a living, but be damned if I can perform heart surgery.

What "chip"? Initially there is no CPU-visible ROM other than BIOS flash, attached to LPC (pseudo-ISA) bus/Intel FWH interface or some equivalent. Before the code in it runs, CPU can't even access RAM. Hell, it can't even run properly because it didn't get Intel microcode updates buried inside the BIOS image.

Quit being disingenuous. You and I both know the BIOS or UEFI is implemented as firmware running on an EEPROM chip located on the mainboard.

And what, do you think, does hardware initialization on boot, using the code that was piled up over 25 years? What implements idiotic standards such as ACPI? What installs non-removable SMI handlers to mess with your ECC RAM and break your realtime OS?

The UEFI drivers, of course.

BIOS, that's what! UEFI implementation is a microscopic addition to a festering pile of shit that is PC BIOS. Go, look how they are proud of themselves: http://www.phoenix.com/docs/BridgingBIOStoUEFI_July2007.pdf They taken their BIOS and "made it compatible" by bolting Intel code on top of it. That's the only implementation you will find on anything except, maybe, Apple.

You didn't even read the document you linked. It goes on about how older operating systems and hardware still require a BIOS, and how we can't migrate from BIOS to UEFI until these old systems are finally gone. It then goes on to talk about how Phoenix built a UEFI-BIOS hybrid chip that contains both a UEFI firmware image and a BIOS firmware image so that hardware and software that don't support UEFI will still actually work. Which is most important for old OSes like Windows XP, or any 32-bit Windows which don't actually work with UEFI.

Re:So where's the security?

[Alex Belits]

Which is completely irrelevant. I work on Patient Administration Systems for a living, but be damned if I can perform heart surgery.

We are talking about BIOS. That I had to debug and write pieces of.

Quit being disingenuous. You and I both know the BIOS or UEFI is implemented as firmware running on an EEPROM chip located on the mainboard.

First of all, it's flash, not EEPROM, though the difference is relatively minor.

Second, you seem to conflate BIOS software with its interface exposed through interrupt handlers and data structures. Interface provided by BIOS is a tiny part of its operation, and that interface, at least its original part before PnP and ACPI were stuffed into it, is no worse than one provided with UEFI. The true horror of BIOS design is in its internals, its initialization procedure (that is still called POST), its configuration management (configuration stored in CMOS RAM that is still present in all modern chipsets and in ESCD area that is still present in BIOS flash), and its handling of devices/OS boot. Those things are severely mis-designed, have no usable software interface, implement weird standards wherever they provide interface (including aforementioned ACPI), and full of idiotic bugs.

UEFI only "solves" the problem of boot device and some additional hardware handling, however it does not change the fact that it's the same blob of BIOS code that implements it. The rest is still there. POST (broken initialization) is there, ACPI (broken resource and power management) is still there, remote/console interface (completely broken and unreliable) is still there, all the part of the BIOS that everyone hates so much, are still in place and can not be removed without losing hardware support.

It then goes on to talk about how Phoenix built a UEFI-BIOS hybrid chip that contains both a UEFI firmware image and a BIOS firmware image so that hardware and software that don't support UEFI will still actually work.

No, they didn't mention any kind of "BIOS image" or "UEFI image". They talk about BIOS product that implements UEFI and keeps its BIOS interface and all its BIOS internals. Because they can't ever remove that crap, it's the core of their product and their business.

Re:So where's the security?

[Kalriath]

BIOS software is just a blob which implements the BIOS interface standard. UEFI implements a completely different interface standard. Ergo, it is not BIOS.

But I can see that this is a complete waste of time. You'll never admit you're wrong, you'll just keep saying you used to write BIOS software and how that automatically means you're right on any topic regarding it (i.e. you're arrogant and egotistical).

Also, I do note you refer to remote/console interface. Presuming that you're referring to KVMoIP/iLO, that isn't implemented in BIOS OR UEFI. It's a separate chipset or separate PCI card (depending on implementation).

Re:So where's the security?

[Alex Belits]

BIOS software is just a blob which implements the BIOS interface standard. UEFI implements a completely different interface standard. Ergo, it is not BIOS.

No. BIOS implement things, most of those with no interface whatsoever. "BIOS interface" is a paper-thin layer on some of its functionality. UEFI is just more functionality and more interface, so it's just implemented as a part of BIOS. There is no "UEFI implementation" that you can burn into a flash chip, stick it on a modern x86-based motherboard, and see it boot. There may be one used by Apple because Apple isn't afraid of re-doing things from scratch (and I never had access to any of their sources, so I honestly don't know), but all modern "PC" desktop and server computers have BIOS, and only BIOS, licensed from one of the few BIOS vendors.

But I can see that this is a complete waste of time. You'll never admit you're wrong, you'll just keep saying you used to write BIOS software and how that automatically means you're right on any topic regarding it (i.e. you're arrogant and egotistical).

Oh, I didn't "used to" work on it, I am still maintaining that particular piece of crap. I didn't write most of it, but I had to adapt it for hardware, because original developers sell half-baked source trees that every hardware manufacturer is supposed to edit (and fix whatever bugs jump out in the process if those bugs make that particular hardware unusable). So yes, unfortunately I had to dig through then-current in 2008 version of that crap, deeper than any sane person would ever want. I didn't use UEFI, and opted for storing a fixed custom bootloader in a separate section of the same flash (I used GRUB legacy stage 2) because UEFI offered no benefit whatsoever. If I chosen UEFI, I would probably be able to stuff GRUB2 in it, getting exactly the same functionality from more code and more bugs.

Also, I do note you refer to remote/console interface. Presuming that you're referring to KVMoIP/iLO, that isn't implemented in BIOS OR UEFI. It's a separate chipset or separate PCI card (depending on implementation).

Oh no, I am not talking about that shit -- having a separate piece of hardware imitating key presses on IBM AT keyboard and screen-scraping CGA text buffer because some moron has to keep those things as primary configuration interfaces on a server, 20 years after those interfaces themselves became obsolete. I am talking about BIOS serial (and usb/network/... variants) console redirection, a piece of code that I had to rewrite heavily, because as initially developed it was completely unsuitable for development of embedded systems. In the implementation I had to provide, it had to be usable for diagnostics, so it had to activate before BIOS initialized CPU and RAM (but after it initialized SIO chip for the first time), and certainly before PCI initialization. As devices initialize, console support had to be passed between multiple mechanisms, so it would not break BIOS' internal handling of interrupts, implementation of devices, common console output procedures, screen-scraping for setup program, flushing buffers before booting the OS, etc. Finally, GRUB has to take it over (in regular or screen-scraping mode) and OS boots, using the same device as its boot console (this time, without any BIOS involvement).

As one would expect, existing implementation had this (and the only available on an embedded system) console completely dark, mute and deaf until complete initialization of BIOS' internal representation of serial devices and PCI[e], so development was extremely difficult, and any resemblance of testing was completely impossible until that was changed. Some really fun bugs came out once I was able to watch early initialization and POST.

I have to apologize to anyone reading this for not being able to disclose any details, as NDA keeps me from doing that. I have to limit myself to pointing out public information on the subject.

Re:So where's the security?

[gottabeme]

Careful, man, you're starting to sound like APK there.

Re:So where's the security?

[lsatenstein]

One of the requirements of UEFI secure boot is that your system has to be able to go online to validate a certificate. What if you are in a secure environment without www internet access? I have not read anywhere that this UEFI system will not require the Internet for validation.

Here is the big weakness with UEFI. With UEFI, certification, your system is not asking if another system is OK, your system is going to Verizon certificate authority to see if your software is OK.

All you have to do is user your router to fake the authority. You do IP and port forwarding, to your own certificate server and just do what CA does and that's it.

And once you are validated, the Linux community can set up it's own secure boot UEFI certificates and licenses.

User key management

[Junta]

self-register their own trusted keys on their own systems at no cost.

How? Most reasonable mechanisms that could be envisioned would likely be considered an 'attack vector' in certain scenarios. I'm genuinely curious as to the mechanisms allowed for end-user key management in this sort of system.

Re:User key management

[robmv]

Using to the UEFI settings in your firmware. there is no automated way to do it, the 'attack vector' possibility is the reason. Red Hat will use this method of signing the bootloader using Microsoft signing services to help the common user to install a Linux distribution without messing with scary UEFI screens. The real problem now is: Will hardware vendors always provide a screen to add/change the keys?. Unless it is enforced by Microsoft Windows OEM licensing rules (not know about this) or government regulation, The answer is not every manufacturer will provide that

Re:User key management

[MickyTheIdiot]

See my other post...

If the signing key is breached (not out of the question with MS's track record recently) then the hardware is permanently untrusted.

So you have to make the hardware trusted again.

Sounds like a boon to Dell and to computer shops to me, unless you create a simple way for a user to fix the problem, at which point your purpose was defeated.

Re:User key management

[SuiteSisterMary]

You, as the user, can generate a key. You can then reboot the computer, hit 'f2' or whatever to get into the bios, specifrically enable 'allow self-signed keys', and type in a given key, after acknowledging all the various warnings.

Much like self-signed ssl certs for personal webpages.

Anybody who gets an email that says 'screenshot of sexy babes! To view, reboot computer, enter bios, and do the following things,' and does, deserves to get whatever is coming to them at that point.

Re:User key management

[MickyTheIdiot]

Not allowing a user an easy path to fix a machine based on a breached key = hardware manufacturers wet dream. Now you have to buy new hardware after a hack!

Re:User key management

[Soft Cosmic Rusk]

Incorporate an IQ-test in UEFI.Problem solved!

Re:User key management

[Junta]

Of course, I wonder if this simply inconveniences legitimate use without additional security.

For example, if RedHat has a multi-boot capable grub signed, could malware just bundle RedHat's signed grub to load rootikit before chaining windows execution. 'SecureBoot' is still set, but rootkit comfortably in place.

Re:User key management

[afidel]

Well a properly working Secure Boot implementation with end user control is a requirement for the Windows 8 Ready program so unless you are buying some really crappy stuff it shouldn't be an issue.

Re:User key management

[Jiro]

No, and that's one of the problems. From the link in the article to the technical blog:

Right now you can load arbitrary code into grub 2 at runtime, and that defeats the point of secure boot. So that'll be disabled. Next we'll be adding support for verifying that the kernel it's about to boot is signed with a trusted key. And finally we'll be sanitising the kernel command line to avoid certain bits of functionality that would permit an attacker to cause even a signed kernel to launch arbitrary code.

grub will no longer be able to load anything. grub has to be signed, and it will also only load a kernel that is signed, and require device drivers that are signed.

Of course this will be a disaster for anyone who wants to compile their own kernel.

Re:User key management

[WebCowboy]

How? Most reasonable mechanisms that could be envisioned would likely be considered an 'attack vector' in certain scenarios. I'm genuinely curious as to the mechanisms allowed for end-user key management in this sort of system.

Secure boot specification describes three "modes" of operation:

1) standard: Accept software signed only by keys included in the factory BIOS (ie. Microsoft-issued keys)
2) custom: Accept software as in 1) but also allow keys signed by another authority/the user. This allows the user to flash in their own key and spin their own Linux/BSD/alternative OS and sign it so it will work with secure boot. NOTE you would also need custom mode in Windows 8 if you are employing custom or in-house drivers or other software that talks too closely to hardware.
3) setup(?): Seems to be a special mode--I think it is a one time setting that changes back after reboot? The setup mode is so that your software installer--an alternative OS or a driver in Windows or otherwise, would be able to push its key into te system's firmware during the install process so you don't have to do that step in the UEFI setup manually. Once a key is installed from a software setup process the system would revert to custom modefor subsequent boots.

Besides that UEFI secure boot can be disabled entirely so you can run unsigned system software and none of the above would matter.

The deal with Red Hat and the Devil (um, the evil Microsoft one not the cute FreeBSD one) commits Microsoft to distributing keys signed by them to anyone who ponies up $99 and fills out the requisite forms. In return you get a key to sign your own OS or other privliged software (drivers/kernel modules...) issued through a Microsoft CA that will work in mode 1) above. That is, you can create a distro or driver setup disk that will work with a "factory default" UEFI setting.

I personally have no problems with this scheme except for two critical points:

1) Microsoft alone is the caretaker (cert. authority) for ALL standard keys. This constitutes a monopoly. Monopolies are not illegal but using them to supress potential competitors IS illegal, and this arrangement sets up Microsoft with the ability to get into amti-competitive shenanigans (again). The $99 fee is not a problem--there is no expiry on your key and you can sign all your stuff with it--I may get one for my own business should I run into issues with custom mode or disabled secure boot. A BIG problem is that nothing commits them to being honest with the CAs. There isn't going to be just one root cert form Microsoft, and nothing stops them from using a "special" certificate class for the $99 certs. That would let them revoke all of them "killswitch" style for whatever reason (the root gets compormised, or they just don't like what they keys are being used for), so anyone who does a bios update or gets a new machine would be SOL if MSFT doesn't re-issue you a new key and won't take another $99 from you.

2) Microsoft is not being platform agnostic. There is ARM and "everything else". MSFT has decreed that ONLY standard mode is permitted on ARM devices that have Windows installed--NO custom or setup modes and NO disabling of secure boot. Furthermore I am not sure if the $99 keys will work to build software for ARM devices (anyone know that one? MSFT could issue certs that only work on x86 architecture if they wanted to). You cannot get a shiny "built for Windows 8" sticker (who cares really) and it is against the license agreement to even install on "insecure" ARM hardware (THAT is something to care about). MSFT is (currently) an inconsequential player in mobile/ARM space so there isn't a big risk yet. However, they could leverage their desktop monopoly to push Windows 8 slates and smartphones in the enterprise and even elsewhere (smart glass in the home for example) and if they are successful it would entice vendors to lock out custom OSes.

Regulatory authorities are going to have to keep a close watch on how MSFT conducts itself as s

Re:User key management

[KahabutDieDrake]

In first generation UEFI systems, you can log into the bios, and add any "key" you want to the signing authority. So if you own the HARDWARE, they let you pretend like you still control the software. Practically what this means is that you can install any OS you want, no problem.

Oh wait, SECOND GENERATION: you can't change the keys at all anymore, and you can't even go into the bios anymore. Have fun.

Re:User key management

[someSnarkyBastard]

Ah but you forget, every time you make something more ingeniously idiot-proof, the universe comes up with ever more ingenious idiots.

Re:User key management

[robmv]

UEFI requires firmware updates to be signed too (I presume not using the same chain of trust of the SecureBoot key, some private manufacturer key). If MS key is breached, the obvious method to me is that the manufacturer release a firmware update with new embedded default keys

Re:User key management

[marcosdumay]

And you (or the DRM owner, peasant) verify that it is the correct update just how?

Re:User key management

[Anonymous Coward]

It's required to do so. From the Specs from Microsoft:

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 will put the system into setup mode.

        If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system will be operating in Setup Mode with SecureBoot turned off.

        The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults.On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enabled.

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. A Windows Server may also disable Secure Boot remotely using a strongly authenticated (preferably public-key based) out-of-band management connection, such as to a baseboard management controller or service processor. Programmatic disabling of Secure Boot either during Boot Services or after exiting EFI Boot Services MUST NOT be possible. Disabling Secure Boot must not be possible on ARM systems.

Re:User key management

[robmv]

Did you read? the firmware must be signed, and the hardware will only allow updates if it is trusted

Re:User key management

[marcosdumay]

A small correction, but you can't add a key. You can at most replace it. UEFI will only support one key, as obviously, if one could add keys to it, manufacturers would add every reasonable key out there, and MS wouldn't have a monopoly on it.

Re:User key management

[vux984]

Problem 2) should be addresses ASAP.

"Problem 2" is what you ALREADY have when you buy an iThing.

Why should Microsoft be scrutinized harder than Apple in the ARM space? Why does Apple get a free pass, but "ARM must not tolerate being treated like this" by microsoft?

Don't get me wrong, I agree with you... but I think all computing devices should be rootable by their owners, and I think that right should be protected by law, and the mechanisms to so should be included in systems... whether its a Win8 or iOS device.

Re:User key management

[chrb]

grub will no longer be able to load anything. grub has to be signed, and it will also only load a kernel that is signed, and require device drivers that are signed.

I was just wondering about that: does Red Hat have a plan for signing external drivers? Like those from NVidia, ATI, etc.? This might encourage companies to incorporate their drivers into the upstream Linux sources.

Re:User key management

[Junta]

Ok, let's take it further. You bundle a 'pirated' grub and kernel. You furnish an initrd that sets up a full screen KVM hypervisor to boot the windows environment.

Now what?

Re:User key management

[Timmmm]

It's possible that your CPU probably doesn't support hardware virtualisation. Many don't. Here is a list:

http://ark.intel.com/Products/VirtualizationTechnology

Re:User key management

[bws111]

A more likely scenario is that Windows will refuse to load if booted from something it does not trust. Remember, there are two components involved here: authentication and trust. UEFI is doing the authentication - yes, the boot loader is signed by someone I trust. The thing being loaded is what does the trusting. The Windows kernel can say 'TPM says I was booted by a bootloader signed by Red Hat. I don't trust Red Hat.'

Re:User key management

[bws111]

It depends on how many places Windows checks the chain of trust. The kernel can check that the bootloader is trusted. The drivers, services, applications, etc can all check that the kernel is trusted. When you are getting to the point where the whole system has to be modified and installed (in one shot, so nothing notices the changes happening) you are making it much more difficult to implement effective malware.

Re:User key management

[Darinbob]

Maybe an option to just ignore keys, why care about self signed keys and the like when I don't want ANY secure bootloader? Is there going to be a chip we can unsolder? Maybe a ROM we can replace with something that's not broken? Maybe I want to put Windows XP or 7 on that machine, maybe I want to put on a ten year old version of Solaris, maybe I just don't like the concept?

Re:User key management

[Darinbob]

Microsoft has been found guilty of having a monopoly by some courts. That changes the rules. It is not a level playing field, companies with monopolies have stricter requirements that they must follow.

Re:User key management

[Junta]

Whole system needn't be installed, you can fit a special-purpose KVM hypervisor in less than 16 megabytes or so. One kernel and a few megabytes of cpio.gz and you have what you want...

Re:User key management

[bws111]

The size of the KVM is not important. What is important is that any component can verify it's chain of trust, and as soon as that KVM layer is hit the chain is broken. To get around that, you would have to replace all of the components that verify their chain of trust. In addition, since those components now no longer have trusted signatures, anything that loads them would also have to be changed, and so on.

Re:User key management

[exomondo]

Microsoft has been found guilty of having a monopoly by some courts. That changes the rules.

No it doesn't.

It is not a level playing field, companies with monopolies have stricter requirements that they must follow.

Really? Then what are these requirements?

Re:User key management

[exomondo]

A small correction, but you can't add a key. You can at most replace it. UEFI will only support one key, as obviously, if one could add keys to it, manufacturers would add every reasonable key out there, and MS wouldn't have a monopoly on it.

Any reason you believe that? Pretty sure there's nothing stopping you adding more keys.

Re:User key management

[tibman]

I think he meant that the logic is circular. When the key is breached, everyone will have to update. The update will be signed with the breached key. Totally secure : )

Re:User key management

[robmv]

I don't think the update must be the same key, unless someone really messed up the UEFI requirements. If the Windows key is compromised each manufacturer could distribute a firmware update signed with their private keys, unless UEFI compliance requirements says that the firmware updates must be signed with the same SecureBoot key, there is no circular logic

Re:User key management

[DMUTPeregrine]

When Microsoft's key is breached, everyone will have to update. The updates will be signed with ASUS', MSI's, Gigabyte's, etc's keys. If their keys are breached, then yes it becomes circular, but the UEFI key is different from the bootloader key is different from the kernel key is different from any application keys.

SELinux

[dsmithhfx]

This can't be any worse...

Faith

[Wowsers]

Red Hat has faith in Microsoft. More fool them!

Re:Faith

[MickyTheIdiot]

Watch Ubuntu & Debian continue to rise as Red Hat turns into corporate asshats, becoming the thing we were all trying to avoid.

Re:Faith

[Anonymous Coward]

Micky your're an idiot.

Re:Faith

[dave87656]

Does this mean that if Debian gets a key that all derivatives of Debian (Ubuntu, Linux Mint, etc) will be bootable?

I hope a gang of lawyers

[FudRucker]

rips Microsoft a "new one" in a class action and/or anti-trust suit

and Fedora/Redhat are feeble minded idiots for paying Microsoft,

Re:I hope a gang of lawyers

[DarwinSurvivor]

Actually, some lawyers start class actions all on their own, then find people that they can "represent" in it just so they can get paid. Ever seen the "you may be entitled to compensation" advertisements on TV? Yeah, guess who pays for THOSE!

Re:I hope a gang of lawyers

[cryptizard]

It has been stated many times, the fee is not going to Microsoft but Verisign. Essentially Red Hat is gaining the ability to run their own root of trust by having a signed "stage 0" bootloader that will in turn load any image signed by Red Hat's private key. This micro-bootloader will most likely just chain load a special version of grub that will verify the kernel is signed by a correct key (at this point, any key that Red Hat wants). I really don't see the problem with any of this. As they said in the first report, any big name, trustable Linux organization could volunteer to get their root key signed using this same arrangement and then run a free, open root of trust that could verify other distributions. The problem is no one wants that kind of responsibility. The only downside to this whole mess is that not all motherboards will offer you the ability to install your own root certificates, which could impact the ability to homebrew a Linux distro, but in the end people that care about that kind of thing will only but motherboards that have that ability.

Re:I hope a gang of lawyers

[Anonymous Coward]

The problem is no one wants that kind of responsibility. The only downside to this whole mess is that not all motherboards will offer you the ability to install your own root certificates, which could impact the ability to homebrew a Linux distro, but in the end people that care about that kind of thing will only but motherboards that have that ability.

The point of open-source is to be able to run any code you want, not just those signed by large corporations. Users, previously not belonging to your elite category, who bought a motherboard without checking, and who now realise the benefits of a custom kernel, will find that they have no option but to buy a new machine.

Re:I hope a gang of lawyers

[Glarimore]

And since the proportion of people who "care about that kind of thing," even among the build-your-own computer folks, is so small, the ability to install your own root certificate will be an extra "feature" that you have to pay out the nose for. A lot of future fifteen year-olds just lost their exposure to Linux because they didn't want to pay an extra forty bucks for an equivalent motherboard with an additional feature they may or not use.

The fact of the matter is that if you lock down a product to take away a function, even if is still available via a new "feature" on select products, the use of that function is going to go decrease because people either a) don't want to pay for the feature or b) it adds another level of complexity to using the function, discouraging use.

I don't think this situation is good for Linux and I think it's worse for young people interested in computing.

Re:I hope a gang of lawyers

[Vanderhoth]

This micro-bootloader will most likely just chain load...

This is the problem I see. Using words like "most likely" and then saying "I really don't see the problem with any of this" is a problem. You've constructed an ideal situation that you think will work correctly. "Most likely" this will not be the case and as such will cause issues with attempting to install any OS that is not Windows 8. Another big problem is by the time we know ALL the facts about how the UEFI and its implementation It will be too late to do anything about it and we'll be forever stuck paying to install anything, that's not a commercial OS, on machines we've rightfully bought.

And I'm not accepting that "For users performing local customization, they will have the ability to self-register their own trusted keys on their own systems at no cost." crap. We all know it'll be free until it's fully embedded in every system, then it won't be free anymore.

Re:I hope a gang of lawyers

[cryptizard]

If you really want to play around with the kernel you will just disable secure boot, which is guaranteed to be available on all motherboards. I imagine anyone doing development on the kernel, even if it is eventually going to be signed, will have to do this just to save themselves the headache. If you want to work at a deeper level, then you turn it off. I also can't imagine how motherboard manufacturers would require you to pay more for this since it is just a simple software tweak that they likely have to have for debugging anyway (all the secure boot infrastructure and hardware are already in place, you just need a UI gadget to be able to change the certificates). The whole point of secure boot is that it is a consumer-targeted security feature that doesn't require any setup or interaction from the user, it just works. The difference between legitimate users and malicious adversaries is blurred to the point that you cannot implement strong security at the consumer level without preventing the user from doing something that they might legitimately want to do. You can be sound but not complete or complete but not sound, you cannot have both. If you have a problem with the restrictiveness of it, please by all means come up with something better.

Re:I hope a gang of lawyers

[cryptizard]

The "most likely" here is completely under the control of Red Hat, not Microsoft. You are quick to jump to conclusions without thinking this whole thing through. Somewhere you have to trust someone or else you should just disable secure boot entirely, which is guaranteed to be an available feature (otherwise how will kernel developers debug their code, even at Microsoft?).

Re:I hope a gang of lawyers

[Vanderhoth]

I'm not jumping to any conclusions, I'm just being cynical. It's better to plan for the worst and hope for the best, then not to be prepared. The original post postulated that in the ideal situation there won't be a problem and seemed to be saying, "Hay guys, these big companies know what their doing. Let's just roll with it."

I for one am not really willing to let big companies decided what I'm going to be allowed to do with my own hardware/software and how I'm going to be allowed to do it. I was burned by the Sony Other OS removal, I'm not falling for the same trick twice.

which is guaranteed to be an available feature (otherwise how will kernel developers debug their code, even at Microsoft?).

I'd rather not speculate on how developers at Microsoft are going to do their development, but I'm sure they've already worked out a "specialized Microsoft only solution" average users/developers won't have access to. As I said before:

Another big problem is by the time we know ALL the facts about how the UEFI and its implementation It will be too late to do anything about it and we'll be forever stuck paying to install anything, that's not a commercial OS, on machines we've rightfully bought."

Claiming something is free is a great way to get people to "buy in" to an idea. The Free-To-Play model being used by most Facebook games and MMOs is a great example of this. Sure it's free to get in and play around, but if you want to do anything significant you have to pay. It's not a stretch to believe initially it'll be free to allow kernel developers to do their thing, but later (possibly after some big security hack) take that functionality away.

Re:I hope a gang of lawyers

[cryptizard]

Maybe I just have faith in the whole hacker/maker scene. There is too much momentum going to let something like this stop people who are really determined to run their own stuff. Either Microsoft, Red Hat, etc are going to keep it open to the point where we can do what we want, or they will lock it up like you say and we will figure out something else. TBH I would love to see what would happen if they DID lock down machines like this. Imagine what kind of cool open source hardware people would come up with. Right now we don't need anything like that, but if we did? The kind of creative, imaginative, resourceful people that are making things these days would probably come up with something great. At the very least, someone like Geohot will find a way to hack motherboards to let you run what you want (pertaining to your "other os" comment). There are just too many smart people to be stopped by stupid crap like that.

Re:I hope a gang of lawyers

[Vanderhoth]

Although I agree with you that we'd probably see some really cool innovation. The issue would be locking down the hardware would make it next to impossible for beginners to do anything. Not to mention there's a world of difference between soldering components to a board and hacking up code. I personally don't have the skills or patients to modify hardware to force it to run the software that I can write, and I most likely wouldn't go out and spend $200 on a motherboard just to wreck it so I could try install my flavor of Linux. I spent $200 on the damn thing, it should run whatever I want it to.

Re:I hope a gang of lawyers

[someSnarkyBastard]

That tidbit is specific to ARM devices only and it is a load of bull. I've been waiting years to see what a Linux-powered (not Android) ARM laptop would look like

Re:I hope a gang of lawyers

[cayenne8]

his micro-bootloader will most likely just chain load a special version of grub that will verify the kernel is signed by a correct key (at this point, any key that Red Hat wants).

But, what happens when you want to re-roll your RHEL kernel to customize it for your specific needs....is it then invalidated?

Re:I hope a gang of lawyers

[cryptizard]

Most definitely, as this is indistinguishable from a kernel rootkit or hypervisor-based malware. Sucks but how else would you deal with it? You can turn off secure boot and do whatever you want, but then you aren't protected from things like this.

Re:I hope a gang of lawyers

[psm321]

The point of open-source is to be able to run any code you want

That's a good point. I wonder if this violates the GPL or at least RMS's interpretation of it along the same lines people were claiming that iPhone apps couldn't use GPL code because you can't actually modify and run them without paying an extra fee. RedHat will now be giving you an "open source" kernel that on some of the platforms you can run RedHat's binary on, you can't actually run your own modified version of it.

Re:I hope a gang of lawyers

[psm321]

If you really want to play around with the kernel you will just disable secure boot, which is guaranteed to be available on all motherboards.

Source?

I also can't imagine how motherboard manufacturers would require you to pay more for this since it is just a simple software tweak that they likely have to have for debugging anyway (all the secure boot infrastructure and hardware are already in place, you just need a UI gadget to be able to change the certificates.

They already do this all the time for price discrimination (like enabling VT). You seem to assume that just because a feature is easy, manufacturers (in any industry) will provide it for free? Especially when they can extract a premium from those who want they feature?

Re:I hope a gang of lawyers

[dew_the_fifth]

or turn off the feature that they are currently not using.

Re:I hope a gang of lawyers

[shutdown -p now]

Someone has explained in a previous Slashdot story on the subject that this doesn't violate GPLv3 provisions so long as UEFI provides the ability to turn Secure Boot off, and thereby run any code you wish on it.

Re:I hope a gang of lawyers

[exomondo]

rips Microsoft a "new one" in a class action and/or anti-trust suit

How could such a thing happen? The very nature of UEFI SecureBoot means you need a key and if you want a key you have to pay Verisign for it and if you don't want SecureBoot at all you just turn it off.

Re:I hope a gang of lawyers

[exomondo]

Someone has explained in a previous Slashdot story on the subject that this doesn't violate GPLv3 provisions so long as UEFI provides the ability to turn Secure Boot off, and thereby run any code you wish on it.

Which is something that is mandated in the windows certification, probably for exactly that reason.

Re:I hope a gang of lawyers

[shutdown -p now]

I don't think it's mandated for that reason - why would MS care about the ability to distribute certified hardware with GPLv3 software preinstalled?

The requirement to turn off secure boot likely has more to do with anti-trust issues. Even if MS doesn't ask for it, but enough OEMs won't bother to let you turn it on, you can bet there'll be a lawsuit over it.

MS's last dual-boot solution worked so well

[WillAdams]

for the other side of the house....

They advocated for a dual-boot system which would allow Windows for Pen Computing to co-exist along w/ Go Corporation's PenPoint OS --- then pulled the plug after the first systems were announced.

Jerry Kaplan's _StartUp_ should be required reading for anyone considering doing business w/ Microsoft.

It's ludicrous that one could purchase a system and then not be allowed to install arbitrary software on it --- why can't there be a mechanism for instantiating a particular key on a system which one has physical access to?

William

Re:MS's last dual-boot solution worked so well

[MickyTheIdiot]

They can get away with it because many normal users can't differentiate between an appliance and a general use machine. You can always bank on the ignorance of the masses.

Re:MS's last dual-boot solution worked so well

[idontgno]

It's ludicrous that one could purchase a system and then not be allowed to install arbitrary software on it

Indeed, and yet startlingly popular (iDevices, Tivo, consoles, etc.).

The idea of a general-purpose computer in the hands of the masses is dying. It's being killed by the mediocre middle (consumer use focusing on such simple-minded appliance-level functions as social media and entertainment consumption).

The computer and the Internet were once Freedom Machines. Looks like that'll be gone within my lifetime.

Re:MS's last dual-boot solution worked so well

[WillAdams]

Agreed.

I (should have) written:

``It's ludicrous that one could purchase a _general purpose computer_ system and then not be allowed to install arbitrary software on it.''

Re:MS's last dual-boot solution worked so well

[exomondo]

I (should have) written:

``It's ludicrous that one could purchase a _general purpose computer_ system and then not be allowed to install arbitrary software on it.''

You should have written:

``It would be ludicrous if one could purchase a _general purpose computer_ system and then not be allowed to install arbitrary software on it.''

Let me predict the future here.

[Anon-Admin]

It will be released but not all the hardware vendors will sign on. Loads of tech people, like the ones here, will not buy it. It will flounder for a few years then eventually die off and go the way of microchannel.

Ill toss this one up there with Divix-DVD's and there pay per view, Sony memory standards, Micro-channel, and many other crappy ideas.

Re:Let me predict the future here.

[DarwinSurvivor]

Except there's a new twist this time. Microsoft is REQUIRING secure-boot if OEM's want to put the "ceritified for windows" sticker on the machine. Believe it or not, that sticker is worth a LOT to OEM's.

Re:Let me predict the future here.

[gbjbaanb]

plenty of hardware vendors will sign on - Microsoft will only let them pre-install Windows if they have it, and so Dell, HP, Asus, etc will all have this crap setup and rocking from day 1.

Re:Let me predict the future here.

[clonehappy]

And will secure boot not have an "off" switch? I would assume it will. Just like how I never install the drivers for the "TPM" when I rebuild an image.

Sure, Windows will refuse to boot if secure boot is turned off, but isn't that a feature, anyway?

Re:Let me predict the future here.

[Anon-Admin]

and most tech people build there own systems buying off the shelf parts. We also recommend systems to family and friends, and unlike most of the places I have worked, family and friends listen to me.

So, Will Dell, HP, and other BIG BOX providers take it.... Sure, they also had micro-channel. That does not mean it will take off or last. It will probably last longer on the server side. However, that is where this scheme will face it's biggest challenges as the list of server OS providers is much larger than the list of Desktop OS providers.

Re:Let me predict the future here.

[DigiShaman]

And without OEMS, effectively you have no PC industry. Fact is, members of Slashdot including myself are the minority here. We are not going to change the way OEMs do business with Microsoft. Period. End of story.

Re:Let me predict the future here.

[vlm]

Believe it or not, that sticker is worth a LOT to OEM's

Count me as "not". The DVD and music cd standards groups thought round shiny optical media was worthless to consumers without their stamp of approval logo, the first thing all consumers do before buying shiny disks is look for the official CD/DVD logo. However, it turns out in the real world that no one cares about a stamp of approval, as long as it works.

Re:Let me predict the future here.

[betterunixthanunix]

It will be released but not all the hardware vendors will sign on

Why would a hardware vendor turn down an opportunity to:

1. Create the sort of DRM'ed "media center" computer that the MPAA drools over?
2. Rake in cash from an app store?
3. Slash their tech support department by controlling the software people are allowed to install?

That is where this is going. We are just seeing the first step of a major attack on user freedom here.

Re:Let me predict the future here.

[Anonymous Coward]

Believe it or not, that sticker is worth a LOT to OEM's

Count me as "not". The DVD and music cd standards groups thought round shiny optical media was worthless to consumers without their stamp of approval logo, the first thing all consumers do before buying shiny disks is look for the official CD/DVD logo. However, it turns out in the real world that no one cares about a stamp of approval, as long as it works.

Uh huh, and what OEM are you? Oh, what's that? You're NOT an OEM? Huh. Well, then, please, by all means, shut the fuck up, the GP was talking about OEMs.

Re:Let me predict the future here.

[Jumperalex]

I believe corporate / government buyers do.

Re:Let me predict the future here.

[MickyTheIdiot]

In itself, that is a great indication of how worthless it is... at least in terms of true meaning.

Re:Let me predict the future here.

[MickyTheIdiot]

Actually is sounds like an opportunity for the small builder once again. And Linux in a much more subtle way.

Re:Let me predict the future here.

[Anonymous Coward]

"Sorry this application can only work in secure boot mode."

Re:Let me predict the future here.

[squiggleslash]

If I want a Windows machine, and I'm looking for a machine that'll run Windows 143 which'll be released in a few weeks from now, I tend to find out what official certification means "This meets the spec required to run Windows 143 with all the bells and whistles turned on". That's pretty much the only time.

I think I've done this precisely once in my life.

Re:Let me predict the future here.

[game kid]

Second step, at least. Mobile phones were set to become capable, user-respecting, even somewhat trustworthy computing devices once; then between the iPhone and Nokia's move from phones like the N900 to...Windows Ph[To preserve their physical and mental health, as well as their monitor, gamekid has elected not to finish their comment.]

Re:Let me predict the future here.

[afidel]

You're seriously delusional, 99+% of computers sold are not built from parts (and it's been this way since at least 2000) and so 99+% of computers sold will be Windows 8 Ready and will have this feature.

Re:Let me predict the future here.

[marcosdumay]

Well, can, of course, think that that label implies that the machine meets the specification for that version of Windows, as everybody has the right to be wrong.

Re:Let me predict the future here.

[marcosdumay]

The problem is that this small builder will have to pay the retail price for Windows, while the certified OEMs are paying something near $15.

Re:Let me predict the future here.

[shutdown -p now]

You assume the off switch will be available. If you've ever had to deal with PC mobo manufacturers, you'll know they do what MS tell them to do.

And MS explicitly tells them to make the switch available:

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

a) 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 will put the system into setup mode.

b) If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system will be operating in Setup Mode with SecureBoot turned off.

c) The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults. "

Re:Let me predict the future here.

[DarwinSurvivor]

Banking? HAHAHAH You're talking about the same institutions that are REQUIRING rfid tags in credit cards (trust me, I've LOOKED for some without it), let you do banking on CELL PHONES and still recommend IE as the preferred browser. These guys couldn't give a flying FUCK if your computer is secure.

Re:Let me predict the future here.

[DarwinSurvivor]

Because "Windows" is a registered trademark and Microsoft would sue the PANTS off you for doing any such thing. The official sticker also nets you HUGE discounts on licensing, you know unless you WANT to pay full retail price on each machine!

Re:Let me predict the future here.

[dave87656]

So I wonder if Firefox and Chrome under Linux will require it?

Re:Let me predict the future here.

[dave87656]

over time increasing amounts of online activities and media consumption will require you to be booted under such an environment. Eventually, you won't be able to do online banking, for example, without being on a "trusted platform".

Funny how the "trusted platforms" will be the ones which are the least secure (Windows) and the really secure platform (Linux, FreeBSD, etc) will be not trusted.

GPL v3

[M. Baranczak]

Doesn't this violate the "anti-Tivo" clause of GPL v3? Sure, the kernel is still on v2, but the system can't run without all the v3 stuff.

This will not stand, man.

Re:GPL v3

[jonwil]

Under secure boot, user-space code that talks to hardware will be banned (otherwise it could open a hole in the secure boot logic) and all kernel-mode code is GPLv2 anyway. None of the normal user-space code needs to be signed (so the clauses in GPLv3 dont matter)

Re:GPL v3

[DragonWriter]

Doesn't this violate the "anti-Tivo" clause of GPL v3?

Not if you distribute the OS on separate signed media that the user has to install. And not (regardless whether or not the preceding condition applies) if the device is not a consumer device.

Re:GPL v3

[shutdown -p now]

Not so long as Secure Boot can be disabled (which it can on x86) and the application distributed can run without it.

Even then, of course, this only applies to PCs that ship with Fedora preinstalled. I doubt that those would come with Secure Boot enabled, in the first place - this whole little dance is to make it easier to install it on Windows PCs.

In A Bind

[EXTomar]

Red Hat needs to research and make sure they are compatible with new and changing tech and UEFI is clearly one they need to make sure RH software works with. There are valid application for signed systems like this (think stuff like ATM) so making sure Linux works and even signed and validated to boot isn't a bad idea. But as we already suspect the general desktop environment isn't a good place UEFI should be used which is what people are afraid is going to happen.

I haven't delved deep into the details of UEFI but as long as the restrictions are only to boot valid signatures then RH and any other Linux should be fine and might even be desirable in some deployments. In fact a strong argument could be made that getting Linux and BSD onto these platform helps "keep them honest". Red Hat should be allowed to do this and we should continue to inspect RH's source which is a good goal brought about by Open Source. If it turns out that Red Hat does this and is not allowed to be entirely open about it then that would be the red flag but not before then.

Re:In A Bind

[Megane]

The restrictions go farther than to just "boot valid signatures". The kernel and all modules that it uses need to be signed as well. Say goodbye to compiling your own kernel or custom drivers if you don't disable Secure Boot in the BIOS.

Tempest in a teacup?

[Monkey-Man2000]

For users performing local customization, they will have the ability to self-register their own trusted keys on their own systems at no cost.

If this is possible, can't any random distribution just ask the user to self-register their own keys for their hardware at installation time? I guess it depends on when the self-registration occurs and how it's done, which is not clear to me.

Re:Tempest in a teacup?

[Lehk228]

People are getting their knickers all twisted because 'The Man' might one day prevent self registered keys. I guess MS might do this in the future if they really wanted to have another round of antitrust proceedings. In the meantime UEFI will let you verify your boot image against rootkits and other such badness (would be nice if you could force deregister all other keys too, not sure if it can)

Re:Tempest in a teacup?

[Monkey-Man2000]

Thanks for the link, but I don't think it directly addressed my point. The exception may be this statement though:

The third is to just disable secure boot entirely, at which point the machine should return to granting the same set of freedoms as it currently does.

If we can disable secure boot in the BIOS then we're back to where we are now in terms of running Linux/BSD. You just can't dual-boot into Windows 8. That seems like something I can live with. :) On a side-note, this situation does make me wonder how Windows 8 will be able to run in virtual machines.

Re:Tempest in a teacup?

[vlm]

In the meantime UEFI will let you verify your boot image against rootkits and other such badness

False sense of security, unless you think keys and serial numbers have never, ever, been distributed over the internet or stolen by crooks, or for some odd reason that popular activity would suddenly stop.

UEFI will be easier to own because of the users false sense of security. "I bought me a UEFI secured system, therefore I'm unrootable so I've got nothing to worry about" "(Click on some website)" "(owned)"

Reminds me of the discussions about "windows serial number activation key" things around/over a decade ago. Well, that's the end of piracy, blah blah blah. Didn't really turn out that way, did it.

Re:Tempest in a teacup?

[Anonymous Coward]

People are getting their knickers all twisted because 'The Man' might one day prevent self registered keys. I guess MS might do this in the future if they really wanted to have another round of antitrust proceedings.

For ARM-based systems, 'The Man' has already prevented self-registered keys for any Windows 8 certified machine. See the last link in the summary from Matthew Garrett (a Red Hat engineer).

Re:Tempest in a teacup?

[squiggleslash]

You're right. And someone might break my windows and get into my house even though I've locked the door. OH NOES FALSE SECURITY!!!?!

You know, under the right conditions I see nothing whatsoever wrong with the concepts being described here. The critical features that every "secure bootloader" ought to have are:

1. Must not be controlled by an operating system vendor. (If this really is in the hands of HTTPS style CAs then that's awesome.)
2. Must be overridable by a knowledgeable user (so they can hack their own hardware - install custom kernels, that kind of thing.)
3. Must be open and used to enforce accountability, not functionality. If someone gives me a random CD of an OS, and I install it, I want to be able to determine who to blame if it goes wrong. I don't want The Computing Establishment forbidding me from getting the CD in the first place for any reason except a refusal to link the content to a responsible group or person by the creator of the CD.

If all the above is true, then I can live with UEFI (and TC in general), hell, I'd go further and say it's a good idea. Are they true? I have no idea, I've read too much Slashdot to know what the truth is in this case.

Re:Tempest in a teacup?

[omnichad]

1 isn't true in theory, but in practice everyone's going to want to use a key provided by Microsoft, because that key will be preinstalled in the UEFI. You have to manually add keys to the UEFI, and that's not guaranteed to be available from hardware vendors. It can be turned off completely, but then only Microsoft users can benefit from the added security.

Re:Tempest in a teacup?

[omnichad]

You can boot into Windows 8 with secure boot turned off. It's not optional for hardware certification, but it still runs on older hardware and it still runs with secure boot off.

Re:Tempest in a teacup?

[psm321]

If userspace software can know if it's running under "trusted" mode, you can be guaranteed that it will be used at least for media DRM (must be running Windows under secure mode to play this file so we know you didn't hack it to bypass the DRM), and likely eventually for things like banking websites so they can claim to be more secure (you can only bank online if we have a guarantee that your kernel isn't "hacked"/unapproved)

Re:Tempest in a teacup?

[shutdown -p now]

For ARM-based systems, 'The Man' has already prevented self-registered keys for any Windows 8 certified machine.

That would probably be because Microsoft does not have a monopoly on ARM devices, and the biggest player in that market today - Apple (which is still not a monopoly) - also uses similar approaches to lock down their hardwar. So there's no anti-trust angle there.

On x86 it's a different matter. Remember that the scope of the original MS anti-trust trial in 1998 was abuse of monopoly power on Intel-based personal computers.

Re:Tempest in a teacup?

[Xtifr]

You're partly right, but remember that they also didn't have a monopoly on browsers at the time. Yet it was browsers they got sued over. What got them into trouble was leveraging their existing monopoly in Intel-compatible PCs to limit the market in browsers. And they could easily get into similar trouble with ARM devices, if it can be shown that they are tied to the PC OS in any way.

As for Apple, the analogy is inapt because Apple hasn't (yet) been judged to have any relevant monopolies.

Note, I'm not saying Microsoft is going to get in trouble for any of this; I'm simply saying that your argument for why they can't is flawed.

Re:Tempest in a teacup?

[shutdown -p now]

You're partly right, but remember that they also didn't have a monopoly on browsers at the time. Yet it was browsers they got sued over. What got them into trouble was leveraging their existing monopoly in Intel-compatible PCs to limit the market in browsers.

Yes, because IE was bundled with Windows running on Intel devices.

And they could easily get into similar trouble with ARM devices, if it can be shown that they are tied to the PC OS in any way.

In which way are they tied, though? Win8 on ARM doesn't run existing Windows applications, and it doesn't run on any existing Windows PC. It's not even source-level compatible with existing apps, since you can only run Metro third-party apps on it, and those require being coded against WinRT (which itself is brand new). About the only connection I can think of here is that WinRT and Metro is also available on Win8 on Intel, but I doubt that's anywhere near strong enough.

Re:Tempest in a teacup?

[Lehk228]

when Eric Holder stops selling guns to drug dealers and starts doing his job this should be prosecuted, if MS is insisting on inability to self-register

Re:Tempest in a teacup?

[exomondo]

You're partly right, but remember that they also didn't have a monopoly on browsers at the time. Yet it was browsers they got sued over. What got them into trouble was leveraging their existing monopoly in Intel-compatible PCs to limit the market in browsers.

Which they aren't, Microsoft used it's monopoly product (x86 Windows) as a vehicle for getting IE to users, the end user was given IE whether they wanted it or not.

And they could easily get into similar trouble with ARM devices, if it can be shown that they are tied to the PC OS in any way.

Can you give an example of such a situation? I can't think of one.

I'm simply saying that your argument for why they can't is flawed.

The argument for why they can't is completely valid unless there is some way the existing sales of x86 Windows also provides Windows RT devices along with it in such a way that other vendors can't compete.

Re:Tempest in a teacup?

[Xtifr]

In which way are they tied, though?

Um, that's why I said "if it can be shown that they are tied."

Win8 on ARM doesn't run existing Windows applications, and it doesn't run on any existing Windows PC.

But does it have hooks that allow it to communicate better with Windows? Or with MS's office suite? Private protocols? Aren't they already trying to prevent other phones from talking to Exchange? It's that sort of thing that could get them into Antitrust trouble. If they start saying, "if you run Windows, this is the phone you need," that's certainly at least flirting with leveraging their monopoly, especially if they try to make it true.

Re:Tempest in a teacup?

[Xtifr]

Can you give an example of such a situation? I can't think of one.

The ability to talk to Exchange. Or import/export from Word properly.

Re:Tempest in a teacup?

[shutdown -p now]

But does it have hooks that allow it to communicate better with Windows? Or with MS's office suite? Private protocols?

Not that I know of. The EU anti-trust decision back in the day (to a large extent courtesy of Samba team) forced Microsoft to document all protocols it uses between products. To the best of my knowledge, that requirement is still in force today.

Aren't they already trying to prevent other phones from talking to Exchange?

Again, not that I know of. Most phones use ActiveSync (for the sake of push), which is publicly documented but patented, but it is licensed out for a reasonable (presumably; no-one complained so far, at least) fee to anyone who asks - at least I've yet to see a smartphone that didn't support it, regardless of the manufacturer and the OS. Certainly, both iOS and Android do.

Also, curiously enough, of late MS has been releasing a bunch of products on competing mobile platforms that interact with its enterprise intranet services. For example, a Lync client for iOS and Android.

Re:Tempest in a teacup?

[Xtifr]

That's fine, but "they aren't" is a whole different argument from "they can't", which is what the original post I replied to was trying to claim. (Also, "not that I know of" is not exactly the strongest argument when it comes to a company with a history like MS's.)

Re:Tempest in a teacup?

[shutdown -p now]

For sure, which is why government oversight is a good thing in cases like that. Apart from being forced to document its protocols, EU also fined Microsoft on the order of something close to $3B (this is the original fine + all the non-compliance fines that followed). And those EU fines tend to be progressive - i.e. for repeated offenses or prolonged non-compliance, they grow, and pretty fast at that.

My post to which you've replied stated that, with the current rules and policies around Win8, it is highly unlikely that there is an anti-trust angle there. Certainly, if those policies change later, or for the next product release, that assessment would no longer hold. But then I just don't see the point in discussing hypotheticals.

Re:Tempest in a teacup?

[Xtifr]

My post to which you've replied stated that, with the current rules and policies around Win8, it is highly unlikely that there is an anti-trust angle there.

Where? Your original post to which I replied said that they don't have a monopoly on ARM, so there can't be any anti-trust issues. I pointed out that that's not true. We've explored exactly what I meant, and you no longer seem to be supporting that position, and I don' t think we were ever in much disagreement about anything else.

(Or did you mean a later post to which I've replied? In which case, yeah, we've covered that now.) :)

Re:Tempest in a teacup?

[exomondo]

Can you give an example of such a situation? I can't think of one.

The ability to talk to Exchange. Or import/export from Word properly.

That's nothing to do with tying Windows RT to Windows x86.

Just say 'No'

[Anonymous Coward]

I won't buy any PC or motherboard with UEFI unless it can be disabled - and I will actively search for machines that refuse to implement UEFI at all. Frankly, this is a quisling move by RedHat. Microsoft bullied the PC manufacturers into this anti-freedom technology. Now RedHat is directly supporting Microsoft by paying into their protection racket. Before you know it, every computer will require a 'legitimate' - government/oligopoly authorized operating system. Just say 'No' to RedHat because they are giving money to a system that is sliding down that slippery slope toward removing your freedom to use your devices as you wish.

Re:Just say 'No'

[gregthebunny]

Agreed! This is an opportunity for us to protest with our wallets. Not only will I be actively pursuing non-UEFI motherboards, but I will also be actively campaigning my colleagues, coworkers, friends, and family to not buy non-UEFI machines as well. Microsoft is trying to fix a system that isn't broken. They shouldn't have to rely on securities at the hardware and BIOS level to lock down their new operating systems. They should just, you know, build a more secure operating system...

Re:Just say 'No'

[Anonymous Coward]

Most people don't even buy motherboards. They hardly by desktop PCs any more at all in fact, but for the few people who do, they head on down to Best Buy and buy the cheapest machine that looks like it'll meet their needs. There's nothing more to it than that. They have zero awareness of UEFI, let alone what it means, and even if they do, 99% of them want to run Windows, and they won't even notice anything unusual.

Re:Just say 'No'

[a90Tj2P7]

Replace "UEFI" with "BIOS" in your first sentence and see how it sounds. Because that's what it is. It's not some MS feature or add-on, not some kind of evil conspiracy, it's the new BIOS. And it's not that "new". And part of the Windows 8 certification requirements for x86_64 systems is that the secure boot feature, which also isn't an MS invention, can be disabled. So that address your concern about buying PCs and motherboards that won't let you disable the feature you actually have a problem about.

Re:Just say 'No'

[a90Tj2P7]

Secure boot, which is what you're concerned about, is just a feature in UEFI. Which has been the BIOS replacement for years. It's not new, it's not an MS creation, and it's not limited to secure boot. Saying you won't buy any PC or mobo that has UEFI because of secure boot is like saying you won't buy any with BIOS if it doesn't have overclocking settings.

Re:Just say 'No'

[AHuxley]

Welcome to the world of core boot, its going to be a very short list :)
Oh see my brother's Digital Certificate company is overworked Colonel, and when he gets overworked he forgets things. Like say, he don't feel the distro's paying fair by him, he may start sending uncertified certificates in your name.
Well suppose some of your encryption was to get broken and sites started getting replaced, er, hackers started breaking in during general uptime, like.
We can guarantee you that not a single cpu will get locked out for $99 a seat.

Re:Just say 'No'

[h4rr4r]

Too bad that they have already shown their true colors by mandating that it cannot be disabled for ARM platforms. Expect that to come to the PC space sooner than later.

Re:Just say 'No'

[TheNinjaroach]

I won't buy any PC or motherboard with UEFI unless it can be disabled

I have a motherboard with UEFI but it doesn't enforce any of this secure boot nonsense.

Re:Just say 'No'

[someSnarkyBastard]

It's more likely to expect computing in general to move further towards ARM. x86 is on the way out, the only thing keeping x86 around was market inertia and perceived lack of processing power on ARM chips. That's all changing though, people love their smartphone apps and current ARM offerings are 64 bit capable, multicore, and running at ~1.5 GHz. My Galaxy Nexus phone has more processing power than my old desktop tower from 2002 but fits in my pocket. Almost every major Linux distro has some sort of plan or roadmap regarding ARM. For better or worse, ARM is likely going to be the wave of the future.

Re:Just say 'No'

[jader3rd]

They should just, you know, build a more secure operating system...

I've read on Slashdot for years that once someone physically gets a hold of your machine, it's 'game over'. I'm under the impression that UEFI secure boot it will no longer be 'game over'. What secure changes could be made to an operating system which prevents the scenario of: somone getting a hold of my hardware, booting into a different OS, modifying the existing install with some sort of malware, and then when I get a hold of my hardware again, detecting that the computer is no longer in the state I thought it was?

Re:Just say 'No'

[h4rr4r]

My galaxy nexus has much worse floating point performance than my desktop form 2002. What kind of magic version of that device do you have?

Re:Just say 'No'

[psm321]

Yep, they're trying to make slow inroads by making it seem innocuous at first. "Oh look, Microsoft is protecting us by mandating we can switch the feature off". It's so blatantly obvious that they're only doing this to overcome initial resistance to the feature and gain acceptance, and will eventually flip-flop. I don't understand how so many presumably intelligent people fail to see that and are defending this horrible intrusion.

Re:Just say 'No'

[StikyPad]

Unless you're a CTO or someone making major purchasing decisions for a large corporation or government entity that buys PCs, quite literally, by the truckload, then good luck with that. And those people are the target demographic, because they have a vested interest in locking down their systems as much as possible. The ability to absolutely prevent the installation of unauthorized software (and especially to prevent booting into something like BackTrack linux) is the wet dream of almost any IT manager.

Re:Just say 'No'

[h4rr4r]

Just like they hope the desktop will end up being. For most people it already basically is.

"Good Faith"

[clonehappy]

I'm not going to invoke Godwin, but *lots* of things start out as being "good-faith initiatives". I know UEFI has tons of advantages over a standard BIOS, and I'm a flat-earther for wanting to stick with the old tried and true methods, but anything that takes away control over hardware I own, especially anything that takes control and gives it to a multinational corporation, I'm passing right over.

And I assume plenty of other tech-minded people will do the same, and the system will fade off into the sunset.

Re:"Good Faith"

[a90Tj2P7]

This secure boot initiative is *entirely* Microsoft's doing. They're trying to leverage their faltering monopoly into a market where their competitors have to pay them for the privilege of being able to sell their own products. (Sadly, I'm *not* expecting anti-trust consequences for this. Not because it isn't deserved, but because I'm too jaded to think it's actually going to happen.)

Or maybe because it makes very little sense. MS didn't create secure boot, and they don't control it or the licensing for it. They want it turned on for Windows 8 certified machines, with their key loaded in. Another OS source can run their own licensing server if they wanted the cost and responsibility, they can provide their own keys if they want the hassle of giving the users instructions on how to load it manually, or they can just ignore the feature altogether if they're ok with leaving that vulnerability open when people disable the feature (on x86 systems) to install their software. MS doesn't control secure boot licensing. They just added the option to piggyback through them as an inexpensive convenience, which they don't even profit from since the entire $99 goes to Verisign.

Re:"Good Faith"

[fluffythedestroyer]

I'm sorry but no one has control over the hardware we buy. A good example is the Sound Blaster card. I remember some time ago when a guy modified some code in the SB drivers and used it on his computer. He published those on a forum and eventually, creative learned about his doing. What happened next you think ? It's really obvious, they put a stop to his dealings of course. In the end, if its not open source, you own nothing, you control nothing, the corp or company that makes the hardware does.

"not a guaranteed right"

[mjg59]

As the author of the linked article, things have somewhat changed since then - the language in the hwcert docs makes it clear that the hardware can be configured into a state where keys can be added. Is it a guarantee? No, but it's as close as is possible to get in the technology world.

what about severs?

[Joe_Dragon]

A lot of web severs run Linux.

Re:what about severs?

[bleedingsamurai]

Yes.
But all the ones currently running on PC compatible platforms do not use UEFI secure boot.

When it comes time to buy new hardware, webhosts can chose to put their money into other platforms like SPARC. Maybe in a few years ARM will have some offerings in the server range. RISC is the way to go anyways.

Re:what about severs?

[NatasRevol]

Sounds like a lot of work to sign all the code you want to run...

Analogy to DVDs and CDs?

[vlm]

I wonder if there is an analogy to DVDs and CDs... If you want to use the Genuine DVD logo on your shiny disk you have to follow eighty bazillion rules, at least some of which suck, and at least some of which are great ideas but people who suck don't want to do the right thing.

The logo people thought no one would ever buy round shiny disks without their holy logo of obligation inscribed upon it. Why the nerve of those barbarians to even suggest such a gauche idea as selling a shiny disk without our word of power.

Solution, ship your shiny round disk the way you want, without the Genuine Official Copyrighted Trademarked DVD logo. The consumers don't care, they just pop a round shiny disk in the player and it works, at least most of the time.

I'm trying to figure out if something like this could happen with UEFI, somehow.

Another option is the death of the preinstalled microsoft OS. If the legal barrier is just too high, start shipping free systems. Preinstalls suck and are absolutely sickeningly riddled with bloatware anyway, so first step is always to wipe the preinstall. The proverbial grandma won't be able to handle installing windows, I guess she will stick with the Ubuntu preinstall and probably not even notice the difference.

The real problem is

[Mojo66]

..that almost every PC comes with Windows pre-installed in conjuction with Microsoft abusing this monopoly despite all the anti-trust affairs.

I know the M$ fanboys will point at Apple and their iOS devices, but the big difference is that Apple does not force other smartphone manufacturers to put iOS on their hardware, whereas PC manufacturers have to pay for not putting Windows on their PCs.

Given those circumstances, the fact that I'd have to pay $99 in order to install my own private Linux distro on my own private PC is just crazy.

Re:The real problem is

[cryptizard]

Please read the article, the $99 is something Red Hat is paying, not the end user. Nothing changes for the user except that your preferred distro has to somehow obtain a valid signature for their kernel (whether directly from Verisign/Microsoft or signed by Red Hat or some other organization that dealt with Microsoft). Barring this, you can disable secure boot or (if your motherboard supports it) install your own root key.

Re:The real problem is

[segedunum]

Please read the article, the $99 is something Red Hat is paying, not the end user.

Read what he wrote. He isn't talking about installing Red Hat but his own private Linux distro, and that's the real problem that this whole debacle causes.

Re:The real problem is

[cryptizard]

Oh gotcha, I took it as like he was just adding private to everything to emphasize that "the man" should keep their hands off his stuff, not that it was a custom Linux distro. In that case just disable secure boot? That option has to stay around because otherwise kernel developers can't debug their work (not even Microsoft).

Re:The real problem is

[Genom]

...has to somehow obtain a valid signature for their kernel (whether directly from Verisign/Microsoft or signed by Red Hat or some other organization that dealt with Microsoft).

Why should any linux distribution be beholden to MS (a direct competitor, and holder of a monopoly on the PC OS market) for the right to install on commodity hardware?

IMHO this sets a very, very dangerous precedent.

Barring this, you can disable secure boot or (if your motherboard supports it) install your own root key.

And if you do convince a user to do that, they lose the ability to dual-boot back into Windows. Without that "safety net", many users won't give linux a chance.

Geeks will of course be fine with installing their own keys, or enabling/disabling UEFI Secure Boot - but regular users *won't*.

MS's monopoly, combined with requiring UEFI Secure Boot for Windows to boot, and MS in control of who else gets to boot? That sounds like a *bad* recipe to me.

Re:The real problem is

[cryptizard]

As it says in the Red Hat report, this situation is mostly because nobody in the Linux community will step up to act as the root of trust. If there was someone willing to do that, they could pay the one time Microsoft fee and then verify and sign any other distro's kernel. Unfortunately that is too much work and responsibility for a volunteer organization, and nobody around here wants to pay for anything these days. You have to trust somebody with secure boot and the Linux landscape is too fractured for any one organization to act as the root. Also, there is no reason that you could not have two root keys (so dual booting windows is still possible) or even just have your Linux bootloader with your Linux root key run Windows regularly. Once you have control of the root you can do anything you want. I agree that most users will not be able to mess with UEFI, but that is precisely the reason Red Hat is doing this.

Re:The real problem is

[psm321]

That option has to stay around because otherwise kernel developers can't debug their work (not even Microsoft).

You keep saying this. Do you not realize that development platforms exist that are independent from consumer platforms? Do you think I can run anything I want on a gaming console because after all otherwise game studios couldn't debug their work?

Re:The real problem is

[shutdown -p now]

Given those circumstances, the fact that I'd have to pay $99 in order to install my own private Linux distro on my own private PC is just crazy.

You don't have to pay anything - you just go to UEFI settings and disable secure boot. RedHat doesn't want the users to have to do it for their distro, though, hence why they're signing their loader.

Re:The real problem is

[cryptizard]

Would it be cost-effective for Microsoft to buy specially made systems (read: expensive) for all its developers just to screw the .001% of people that like to hack their own kernel?

Re:The real problem is

[psm321]

It's not expensive for them if they get OEMs to make them that way for them.

"good faith" can change

[Anonymous Coward]

Even if this is indeed a "good faith" initiative, what difference does *that* make? The tools for locking down and controlling all computing are being put in place, one small step at a time. When that "good faith" goes away in the future, the tools will not know the difference; they can be used in good faith or bad faith alike.

It's much like giving a genuinely good leader draconian legal powers. (S)HE may used them wisely to do actual social good, but in a hundred years when you have a despot at the helm, he'll have the same draconian things available.

FUCKING stupid

[inode_buddha]

"Suffice it to say that Red Hat would not have endorsed this model if we were not comfortable that it is a good-faith initiative."

Fucking STUPID. Since when in their entire history has Microsoft ever done anything in "good faith"?? Morons! *ALL * you need to do is read a few court cases...

"your owns keys is certainly not a guaranteed"

[l3v1]

"your owns keys is certainly not a guaranteed"

If I can't use a custom kernel and I can't load custom drivers, than there's no way anyone could convince me this UEFI/SB and the related signing misery is the way to go. I couldn't care less that some distros can sign their kernels and drivers and you can use those, because that essentially would imply a lock-in to a specific company's version - thanks but no thanks. Of course I can imagine how some companies would like it that way.

JUST SAY NO!

[Gim Tom]

The only way for us to keep UEFI from being on every MOBO is to JUST SAY NO

Don't buy a PC with UEFI and don't even try to keep one running when it craps out.

Manipulation and FUD.

[LWATCDR]

"From what I can tell, the worst fears of the trusted computing initiative are coming true despite any justifications from Red Hat here. Note that the ability to install your owns keys is certainly not a guaranteed right."
Okay chicken little the sky is falling.
Really? You can turn off the security settings in UEFI. Will you in the future? No but that is a slippery slope argument. The simple fact is that UEFI offers a layer of security that many users may welcome. As long as the end user can turn it off I am fine with it.
Now on the Windows ARM platform it can not be turned off which is just evil and should be looked into as a violation of anti-trust. Of course if you really hate the idea that is fine also. What is stupid is complaining that Red Hat paid the $99 fee. That like saying that a kid should stand up to a gang of bullies instead of giving them his lunch money even if they will beat him to a pulp.

Re:Manipulation and FUD.

[bongey]

Does getting the Microsoft to sign your key allow booting to ARM arch? If so not an issue , if they cannot get it signed then there is a big issue
I can see as for mobile systems requiring secure boot as good thing. Being a mobile platform it would be really easy for someone to grab you mobile device and lay down another image.

Re:Manipulation and FUD.

[bongey]

I am linux/android fan. Ever since being burnt by bug in MC++ 6.0 I haven't ran windows on a home computer. But sometimes MS might not being doing something sinister .

Re:Manipulation and FUD.

[quarkscat]

The Apple laptop I bought 10 years had EFI, and it was possible for me to halt the boot sequence, then have it boot-strap into a Forth application which ran like a demon without the OS overhead. Apple shipped those with no EFI boot ROM password, but the user could set up a root password which avoided a lot of potential problems. UEFI is either enabled or disabled, but if it is enabled, the Gatekeeper for the Boot ROM AUTH Key is Microsoft, and Red Hat acknowledges that the User must pay (est. $99) for each machine OS "upgrade".

How many alternative OS Vendors will be locked out of that market by UEFI's steep per user machine fee? What happens to alternative SW Vendors -- will they be able to survive when their customers would be forced to pay to get a per machine fee? The UEFI is the spawn of Satan himself -- the Mark of The Beast -- Everyone gets a universal internet ID number with UEFI. You just have to love it when monopoly-minded crony corporate interests run the regulatory and enforcement arms of government No harm to the special interests, so there was no foul. "Keep moving, people. Nothing to see here." Like a Jedi mind-trick, "The kleptocratic monopolies of which you seek are not here". LOLZ

For a LIMITED TIME

[brad-x]

I'm assuming no one has yet noticed that the $99 fee is not going to last forever. From Microsoft's sysdev portal:

Microsoft is pleased to announce that, for a limited time, VeriSign is offering the ‘Microsoft Authenticode’ Digital Certificate at a substantially reduced price by following the link below.

Moreover as others have mentioned here, it's not guaranteed that any hardware manufacturers will include the capability to register one's own keys. I certainly haven't heard of any yet.

Re:For a LIMITED TIME

[cryptizard]

As it said in the original article, all Red Hat has to do is get a "micro-bootloader" signed one time, which in turn will verify anything further up the chain against their own public key which they have complete control over, and they can change their kernel as much as they want without having to pay or deal with Microsoft again. The only time they would need to get it resigned is when the certificate expires.

Re:For a LIMITED TIME

[squiggleslash]

For those without a Windows Live ID, apparently the usual price, from the same page, is $499.

That said, I see nothing on the page that implies that this is the right certificate to buy for the Secure Boot Initiative. I wouldn't mind seeing some clarification on this point, as Wikipedia (for one) seems hazy on this subject.

Just ask Flame developers

[luizd]

C'mon, it is very easy to solve the problem. Uses them same Microsoft CA that Flame worm is using.

SecureBoot is more a "reduce users power to change OS" than "protect from malwares", as Flame proved.

The Red Hat Wizard Falls Under Sauron's Spell

[quarkscat]

UEFI is an OEM Software Vendor's bald-faced grab at monopoly power. Microsoft would be the key generator. Redhat would pay Microsoft a one-time fee per user machine, which RH figures likely to be a one-time $99 fee. This charge would be per machine, not per user, as it is likely that no 2 computers on the same network can have the same key. How many linux users not running servers would be willing to pay their OEM Linux Software Vendor an extra $100 over the current cost of that software per machine? What impact would this have on the number of desktop linux users? How many would forego any switch from the Microsoft OS pre-installed for an extra additional $100, per machine?

IIRC, when Microsoft first began trying to compete with Server Software against the the Big Iron Server Vendors, flexibility in number of connected clients, and owning the HW and the SW license was considerably cheaper than an annual HW & SW service agreement. Digital Equipment, Silicon Graphics, and Sun Microsystems are gone, Microsoft has so much influence over HW manufacturers that an effort was made to rein in competition. Control of the UEFI Boot AUTH Key by a self-avowed SW monopoly would appear to, in one fell swoop, destroy a segment of the Desktop OS competition AND create a robust new revenue stream at the same time. The crony corporatists are greedy vampires, as one named John D. was quoted as saying "Competition is a sin."

So, which recently topping $1 Billion in revenues OEM SW Vendor just climb into bed, figuratively speaking, with Microsoft? Red Hat? Gee whiz, I wonder how many of Red Hat's plethora of desktop linux competition, or for that matter, any *nix-like OS Vendor would care for their product to be automatically boosted in price by $100 (minimum) to establish an UEFI Boot AUTH Key "Associate" account with Microsoft? When is More Evil just too much?

Free market capitalism, by definition, should be operating on a level playing field of regulation and enforcement. The greater and greater concentration of economic power and influence in the hands of fewer and fewer corporations is hardly an indication of a vibrant free market. But that is a symptom of corporatism, and when government is in alliance with those crony corporate interests instead of the general well-being of all taxpayers, it is called corporate socialism also sometimes known as national socialism or fascism.
   

Re:The Red Hat Wizard Falls Under Sauron's Spell

[a90Tj2P7]

UEFI is an OEM Software Vendor's bald-faced grab at monopoly power. Microsoft would be the key generator. Redhat would pay Microsoft a one-time fee per user machine, which RH figures likely to be a one-time $99 fee. This charge would be per machine, not per user, as it is likely that no 2 computers on the same network can have the same key.

I couldn't make it through the first paragraph without hitting ridiculous levels of FUD. MS isn't the key generator. They're not even the generator of their own key. The license isn't per-machine, it's per-source/vendor. There's no kind of per-machine restriction, in any way, shape or form.

Re:The Red Hat Wizard Falls Under Sauron's Spell

[RightSaidFred99]

Jesus tapdancing Christ, you sure are an idiot aren't you? You literally know _nothing_ and are just blathering a bunch of paranoiac gibberish.

You started out with lies and FUD, and got called on it. So then you proceeded to just make up a bunch of scary nonsense.

Enthusiast systems

[ZorinLynx]

Even if this comes to pass for companies like Dell and HP, I doubt the "enthusiast" system builders like Asus and Gigabyte will be locking down their motherboards. After all these are machines frequently built and tweaked from the ground up, and enthusiasts won't buy them if they're locked down and they have to install a specific OS version.

Re:Enthusiast systems

[quarkscat]

And you don't think that UEFI-based HW-level DRM enabled, for both the booted OS AND every application that accesses the internet will not become a requirement at some point in the not-too-distant future? Requirements for unique user ID for access to the internet are already being seriously discussed by the PTB. UEFI is the camel's nose under the tent flap scenario. Internet access is the chain, and DRM is the ball. We will all be prisoners in a full spectrum national security surveillance police state.

But by all means, be the early adopters of a technology that will soon be both obsolete and illegal. UEFI and DRM will soon enough be the law of the land, or at least another decision of the Unitary Executive. You must learn not only to obey, but also to love Big Brother. Anything else would be construed as a Thought Crime, and the next thing you know, you're in Room 101 in one of FEMA "re-education" camps. You will awaken, at some point.

Re:Enthusiast systems

[shutdown -p now]

Asus and Gigabyte will have to implement secure boot and turn it on by default if they want the "certified for Windows" sticker. On the other hand, since there's also the requirement that secure boot can be disabled, I don't see how this would affect the "enthusiast" market - if someone wants to install whatever the hell they want, they still can.

The road to hell is paved with good intentions

[Damnshock]

There's really nothing else to add here

Re:The road to hell is paved with good intentions

[RightSaidFred99]

And the road to nowhere is paved with FUD. This article and 90% of the replies are laughable FUD.

You can turn it off or you can get your own keys. "Problem" solved.

Microsoft has a history ...

[mbaGeek]

the big concern is that Microsoft has a history of not playing well with others, but that was with Bill Gates running the show

Steve Ballmer (who dropped out of Stanford's business school to join Microsoft - i.e. he is a "businessman" in the good sense) is probably a little less cut-throat (or inclined to "compliance with raised middle finger") than Bill Gates - which is obviously just my opinion - and I'd gladly work for either Microsoft or Red Hat (I've used both company's software for years, but I'm not religious about either)

anyway, I'm still not convinced that "UEFI" is the next big thing, I'm willing to listen/try it - but taking a "trust but verify" attitude toward the whole thing

Re:Microsoft has a history ...

[marcosdumay]

Steve Ballmer is probably a little less cut-throat than Bill Gates - which is obviously just my opinion...

Well, you should ask the oppinion of Nokia shareholders.

Re:Microsoft has a history ...

[mbaGeek]

Bill Gates was famously competitive about everything, and at times it looked as if he didn't just want Microsoft to win but also wanted to destroy other companies that might be a threat to Microsoft (or he might make them an offer they can't refuse)

so saying that he is "less cut-throat" than Bill Gates doesn't mean that Steve Ballmer won't do what he thinks is in Microsoft's best interest (which is kind of his job)

I'm sure Stephen Elop has done/is doing what he thinks is in Nokia's best interest (and if Elop isn't "looking out for Nokia" he should be fired)...

Re:This, again?

[Anonymous Coward]

Oh really? Read this and tell me again how I can turn off secure boot on my ARM device. Because I won't be able to.

Tim Burke is an eRape apologist

[Rogerborg]

Saying that if you just quit your damn bitching and hold still, it won't be as bad as you imagine. Hell, once you've been slammed hard a few times, you'll hardly even notice it's happening.

Re:Tim Burke is an eRape apologist

[RightSaidFred99]

Shut up. You can turn off secure boot, you can use an existing trusted key, or you can install your own keys. This is much hand-wringing and FUD by a bunch of angry dweebs.

Secure boot is a desirable feature and mandates a signature system like this. If you don't like it, turn it the fuck off.

Where the world going?

[NuclearCat]

Now using my electronics how i want is "certainly not a guaranteed right". WTF. Thats why we had DIY talents before, who was building companies in garage, and now we have army of "angry bird" players, because it is not easy to create something this days.
You can't reuse electronic parts. SMD. You need expensive tools to do that. Well, ok, let's say it is ok.
You can't reuse blocks and highly integrated IC's, because there is NDA for documentation and high fees to get this documentation.
And now, finally, soon you can't write your own low-level software, because your PC manufacturer will decide, what you can run, and what you can't.
I hope my car one day will not tell me, which road i can take, and which one i'm not allowed to go, because my car don't have license for offroad.

Re:Where the world going?

[quarkscat]

UEFI and HW-based DRM are elements of the national security surveillance police state control grid. If you want to access the internet, your HW & SW must conform to these new standards. There won't be any choice.

In the not-so-distant future your vehicle will be driving you, on a number of highways -- Smart Roads.

You'll just be a passenger in either case. As will we all.

 

Real Future: Key Revocation

[CanEHdian]

I wouldn't be surprised if Microsoft can pull this off.

The real problem starts when 'stolen' keys are going to be abused for malware / used for loaders, etc. Then phase 2 will come into play: "suddenly realizing" that you also need some kind of key revocation system for this to be secure. But in phase 1 you already locked yourself in.

You will be totally at the CA (Microsoft)'s mercy. Replacing Microsoft with some US-government agency will make things even worse.

I sure don't trust Microsoft here

[Megane]

Oh, sure, you can disable the UEFI Secure Boot crap. But when I read the initial article a few days ago, the point I got was that Fedora's goal was to not require users to have to go to the trouble of manually disabling it. Win8 is going to require SB enabled in order to get the W8 sticker (I was unclear if W8 itself required SB, but if it did, it wouldn't work as an upgrade). So in order to install Linux, everyone must manually disable SB first unless the distro gets signed. And they can't just stop with signing the first stage boot loader, they pretty much have to have the kernel signed and have it check for signed drivers, otherwise there would be a hole that some eeeeeeevil malware could get through, which would be grounds for revoking the key.

Then there is also some kind of problem with driver modules (like in the ROM on PCI cards) also having to be signed, but apparently it has to match the OS key, and there's no room for more than one signature. So of course they'll get signed for Microsoft's key. This is bad, but it really doesn't have much to do with the particular problem at hand.

The problem I see is that the master key is revokable if a particular OS boot loader is determined to be insufficiently secure. No, your BIOS isn't going to get on the internet and update itself every time you boot (but let's not give Microsoft any ideas) and one day refuse to work; the problem is that six months from now, the BIOS in all the new motherboards on the market would say "hey this Fedora key, someone told me it's no good!" And people installing Linux for the first time would again have to manually disable SB until a new key and bootloader are produced. Since Fedora's goal was a no-fuss install, this is a failure.

And then there's the looming issue of what happens if Microsoft decides to require that SB not be disabled, as they have done on ARM. Sure, there are already a lot of ARM tablets that will never run W8, but if you get a good deal on a used or clearance W8 tablet, it's useless for anything but W8. But what happens if Microsoft decides that a manufacturer can't get a W9 sticker if you can disable SB?

Re:I sure don't trust Microsoft here

[shutdown -p now]

But what happens if Microsoft decides that a manufacturer can't get a W9 sticker if you can disable SB?

An antitrust suit, in EU most likely?

I'm Seeing A Lot of Misinformation Swirling

[GeorgeRidout]

Unless I'm very much mistaken (please feel free to correct me) I'm seeing a lot of incorrect information around this. As I understand it: A) You can turn it off by going into the BIOS. Then you can boot anything you like. B) Each boot-loader for each individual OS requires signing by the manufacturer. As I understand it, Redhat were asked if they would be the custodians of 'one true' Linux key and they didn't want to be responsible for it on behalf of other distro makers. C) Redhat approached PC manufacters who were very receptive to their key being included with all hardware, however Redhat felt there would be an impression that they were levaraging their size as unfair competition. D) MS offered to sign distro's and OS's with their own key as long as the maker was registered with them for $99 which is surely below cost. Ideologically it is not ideal I agree but it could be worse no? Ideally some garanteed impartial third party would sign all OS's from one key. But who? Thanks for reading

Re:I'm Seeing A Lot of Misinformation Swirling

[AHuxley]

How long before its like the PAE needed distro?
You might get a few years out of the BIOS hack, but sooner or later you will need a real new motherboard...
Buy a select $400 pro motherboard from an OEM? What chips will that one option offer you for usb, networking or sound? Welcome to your "hobby' option: Marvell as you write real code to see your broad band light up via your now working usb...
Pay the $99 seat tax or get coding.

Buy a key and then post it?

[oldmacdonald]

So what's to prevent RedHat, or anyone else, from paying the $99 for a key, and then publishing it? This would let anyone sign their own distributions. If it can work, I'd happily post an oldmacdonald key.

What a load of bollocks

[kelemvor4]

I think people are blowing this secure boot problem a little out of proportion, and many like the author here are inferring that the problem is with UEFI its-self. I see UEFI as a good thing (as it has been for several years on the systems that already support UEFI). In the author's example, they complain that someone who rolled their own linux distro wouldn't be able to install it. This is a laughable idea to me, if someone has the skills to roll their own distro, why would they have a problem figuring out how to go into the UEFI config and disable secure boot? Second, we're really only talking about oem crapmachines like dell and HP/Compaq and the like which will have secure boot enabled by default to meet the Microsoft Windows8 logo certification. If an OEM like that sells machines with linux, I'm pretty sure the machine with ALSO ship with no secure boot and no logo sticker. If a user buys a machine, pays for a windows license, and still wants to wipe it out and run linux.. Somehow I fail to see how making one change in the UEFI config is a big deal.

If a user buys an asus (or whatever brand you like) motherboard, it's not going to be Windows 8 logo certified because it isn't a whole computer and I would hope would not have the secure boot enabled by default.

So, I think this is a case of mountains being made out of molehills. I only care because things like TFA seem to place the blame inappropriately on UEFI, and I've been waiting for UEFI on my machine for a very long time!

Re:What a load of bollocks

[ISoldat53]

Also, Intel has a long history of supporting Linux. I can't imagine they would build hardware that would not work with it.

Re:What a load of bollocks

[marcosdumay]

That argument would hold if MS didn't have a monopoly on operational systems. But it does, thus all those paragraphs are moot.

Wait - this only affects NEW hardware with...

[kfsone]

the UEFI secure-boot feature required to run Windows 8.

The only people affected by this are people who have supported MS by buying MS-spec hardware.

$99 for a keying license vs Sony's policy of simply not allowing other OSes ... I'd say, lesser of two evils.

Re:Wait - this only affects NEW hardware with...

[Microlith]

The only people affected by this are people who have supported MS by buying MS-spec hardware.

Given that virtually ALL hardware is "MS-spec" hardware, this is a moot point too argument.

Re:Wait - this only affects NEW hardware with...

[cheekyjohnson]

$99 for a keying license vs Sony's policy of simply not allowing other OSes ... I'd say, lesser of two evils.

What does Sony have to do with it? Are those the only two options, or am I missing something?

Re:Buy a key and then post it?

[guruevi]

In that case they'll simply revoke your key and you'll have to pay for another one (if you can even get one at that point). If Microsoft loses their key, it won't get revoked. See the SSL certificate issue they've had recently, a root CA would (and should) immediately revoke the whole Intermediate certificate if that happened with a small company but because it's Microsoft they won't.

The point of the system is that large vendors (like Microsoft) will have keys and you won't. Also malware creators (good ones that operate on a state-level) will have the keys (see DuQu, Stuxnet etc. for examples). But YOU won't.

Also, to insert/revoke keys there has to be an OS to EFI link (just like Mac OS X has one) so that will be the point where it will be exploited.

presumably they can revoke keys

[Chirs]

Given that they talk about updating the set of keys, I'd be surprised if they couldn't revoke keys that are found to have leaked. They could also likely track back the signed code to the key that signed it, and thus put you on the spot.

presumably not

[Chirs]

Redhat could conceivably make their grub only load redhat-signed code by default. Might make sense for RHEL, maybe not for Fedora.

Re:Microchannel Anyone?

[badfish99]

I remember a salesman from IBM coming to show us one of the early Microchannel machines.

He proudly told us about its wonderful security feature: if you changed any hardware, you could not boot it unless you had a magic floppy disk containing some magic security files.

Then he switched it on to demonstrate it. It was as dead as a dodo. He then remembered that he had removed a network card just before bringing it to us. And he had forgotten to bring the magic floppy with him.

Exit one very red-faced salesman. And we vowed never to buy any of that crap.

What is Garrett not saying?

[Sloppy]

There are a couple things about Garrett's blog that have mystified me. I'm not saying he's wrong or anything, just that he says some things which can only possibly make sense, if there's something else which isn't be said. Seriously, please help filling in the blanks.

An alternative was producing some sort of overall Linux key. It turns out that this is also difficult, since it would mean finding an entity who was willing to take responsibility for managing signing or key distribution. That means having the ability to keep the root key absolutely secure and perform adequate validation of people asking for signing. That's expensive. Like millions of dollars expensive.

What happens if someone did that, but didn't take the "responsibility" seriously and didn't spend the millions of dollars? If there were a "Linux" signing key, but it were released to the public so that anyone (including malware authors) could sign their bootloader to UEFI's satisfaction, that would obviously nullify the point of secureboot but other than that, what would be the consequences?

Does someone have to post a bond to get a signing key (i.e. if you leak your key, it contractually costs you n megadollars)? Or is there some key revocation process, where that fact that some signing key is no longer trusted by the UEFI central authority, is somehow magically signalled to millions of Flash ROMs?

Neither of those ideas bear scrutiny. Is there a third deterrent?

Instead we're writing a very simple bootloader. This will do nothing other than load a real bootloader (grub 2), validate that it's signed with a Fedora signing key and then execute it.

(Where if I understand this correctly, the "very simple bootloader" is the thing that Microsoft is signing.) Why check that grub2 is signed, instead of just loading any old grub2? Obviously, the answer of course, is that doing that would defeat the point of secureboot but nevertheless it solves the problem created by UEFI. Other than making secureboot irrelevant, what would be the consequences of that?

Secure boot is built on the idea that all code that can touch the hardware directly is trusted, and any untrusted code must go through the trusted code. This can be circumvented if users can execute arbitrary code in the kernel. So, we'll be moving to requiring signed kernel modules and locking down certain aspects of kernel functionality.

Again: why? So what if the kernel or a kernel module lets you touch the hardware? At that point you've already booted and taken control of your machine, so secureboot can't stop you. Garrett's project has succeeded at letting Red Hat customers run Red Hat on their UEFI machines with default settings at this point. The problem is over, isn't it?

One idea that leaps to mind is that if Red Hat didn't say their bootloader would only load signed grubs2 and their grub2 would only load kernels which prohibit loading untrusted kernelspace code (e.g. unsigned modules), then Microsoft would refuse to sign their initial bootloader. But saying things and doing things are two different things. It's inconceivable that for a $99 fee, Microsoft has guaranteed that the Red Hat kernel never under any circumstances run not-Red-Hat-blessed code. I'm convinced their strategy can't be based on code-auditing or statements from those who create the code, that the code will never run other untrusted code. That's not viable. If you could audit a who kernel for $99 then Theo deRaady woudl be out of a hobby.

A lot of our users want to build their own kernels. Some even want to build their own distributions. Signing our bootloader and kernel is an impediment to that. We'll be providing all the tools we use for signing our binaries, but for obvious reasons we can't hand out our keys.

"Obvio

Re:What is Garrett not saying?

[mjg59]

Keys can be revoked through OS updates. Check the UEFI spec for discussion of authenticated variables and dbx.

Re:What is Garrett not saying?

[mjg59]

Malware doesn't have a key in KEK, so it can't.

Re:What is Garrett not saying?

[marcosdumay]

Well, you can't just remove the signature check from the bootloader, since that would invalidate the bottloader's signature. You'll have to go all the way through the $99 validation system to write a bootloader that doesn't check the kernel's signature, then anybody could use it.

Now, the good news is that unless they got some NSA level of competency on crypto to create something completely unheard of, there is no way to revoke your key after you create that bootloader above. You see, for anticompetitive reasons they require the system to hold only one key. If you have a signed bootloader, it will be signed by The One True Key, and if they revoke something, that will be The One True Key, and if they do that, they'll also blacklist Windows and everybody else.

Re:What is Garrett not saying?

[Sloppy]

Thank you.

Keys can be revoked through OS updates.

If I understand correctly, that sounds like just a risk for people who dual-boot, purchase second-hand machines, and so on. And that's something so I don't want to totally discount it. And Red Hat obviously needs to robustly handle those situations.

But nevertheless, it sounds like for people whose machines never run Windows, one global known-to-everyone-signing key purchased for the world for a mere $99, really would make it so that out-of-the-box "Windows 8 Certified" machines with default SecureBoot settings, would initially trust it so that people could can install and boot whatever OSes they want to. (This is the Great Satan?!?)

If Microsoft code is never run on your computer, then they can't sabotage its trust database. I bet for most Linux users, that's .. not fine (you can't buy second-hand machines and know that they'll still work) but .. live-with-able.

Red Hat can afford it

[danbuter]

Paying this fee to Microsoft will help guarantee Red Hat's remaining on top of the Linux world. They can afford to pay it. Many of their competitors probably can't.

UI with over a hundred buttons, and more is better

[Sloppy]

If you could audit a who kernel for $99 then Theo deRaady woudl be out of a hobby.

Wow. I swear I used a real keyboard for that, not a tablet. Oh well.

UEFI supports user-loaded keys

[Chirs]

But you need to boot into the bios to do it, and RedHat doesn't want to make everyone do that just to boot Linux.

Then of course there's the conspiracy theory that says that just because UEFI supports it doesn't mean that all the vendors will actually give users the ability.

Re:UEFI supports user-loaded keys

[shutdown -p now]

Then of course there's the conspiracy theory that says that just because UEFI supports it doesn't mean that all the vendors will actually give users the ability.

Microsoft's requirements for hardware certification ("Designed for Windows 8") mandate that users have that ability on any certified x86 device.

Re:UEFI supports user-loaded keys

[Darinbob]

Trouble is some users are dumb enough to trust that certification. Remember the "Windows 7" logo being put on computers that couldn't run Windows 7 well? And users are naive enough to think that "Designed for Windows 8" implies quality, or naive enough to think that Windows 8 is worth having. The real people Microsoft are burning are the smart users, smart enough that Microsoft doesn't care if they lose those customers because their numbers are so low.

Re:UEFI supports user-loaded keys

[shutdown -p now]

Remember the "Windows 7" logo being put on computers that couldn't run Windows 7 well?

Are you, by chance, confusing it with Vista story where there were two certification levels for hardware - "Designed for Vista" (which was okay), and "Vista Capable" (which was the absolute bare minimum, and created solely because Intel begged for it so that they could sell their low-end hardware in 2005)? I don't recall anything similar with Win7, or, indeed, with any version of Windows - "designed for ..." always implied reasonable hardware specs.

you misunderstand

[Chirs]

Under secure boot, the hardware validates the bootloader, the bootloader validates the OS, and the OS validates the userspace code.

Redhat could easily write some userspace code to talk to certain parts of the hardware and sign it with their key and it would be allowed to run just fine.

yes they can, but it means going into the BIOS

[Chirs]

Currently you can stick in a USB stick and boot from it into a live RedHat image.

Under secure boot, if they go this route that will continue to work. If they go the self-registered route they need to get people to reboot into the BIOS, either add in a new key or disable secure boot, then reboot.

For most of us here this is no big deal, but for my grandma that would be a showstopper.

he doesn't have to pay

[Chirs]

For installing onto your own machines you can add in arbitrary new keys for free.

If I want to create my own distro and allow other people to install it _without disabling secure boot or manually adding new keys_ then I need to pay $99.

Incidentally, it costs $99 to publish apps to the Apple app store, so this doesn't seem like a crazy price.

The user WILL NOT pay $99 per upgrade

[Chirs]

Red Hat pays $99 once to get their key included in the BIOS. This lets them boot up their bootloader (signed with their key) which then boots whatever they decide to allow--could be OS kernels signed with their key, could be arbitrary stuff. I'd guess that RHEL might lock things down tight by default, with Fedora being more permissive.

There is no per-machine fee.

Re:The user WILL NOT pay $99 per upgrade

[Cito]

they have to pay the 99 fee every single time the kernel is updated, recompiled or drivers updated/recompiled.
it's not really a 1 time fee.

it's 1 time as long as they dont change the kernel or drivers.

as soon as any user recompiles kernel or drivers their key is useless now and system will not reboot until they turn off secure boot.

that redhat paid 99 dollar thing is for 1 specific kernel/drivers, if that kernel changes or those drivers change at all a new key has to be purchased, or turn secure boot off.

it's fucked up

I'm sure I speak for all of us when I say

[Peter Simpson]

"No thank you" to an offer to pay $99 to allow me to configure hardware and firmware that I have already paid for. I know which PCs I will not be purchasing.

Re:I'm sure I speak for all of us when I say

[exomondo]

"No thank you" to an offer to pay $99 to allow me to configure hardware and firmware that I have already paid for. I know which PCs I will not be purchasing.

Well you don't seem to understand the issue, if you want to run a signed bootloader you need a key, you have to pay $99 to Verisign for that. Alternatively you turn secureboot off and continue as normal.

Re:I'm sure I speak for all of us when I say

[Peter Simpson]

"No thank you" to an offer to pay $99 to allow me to configure hardware and firmware that I have already paid for. I know which PCs I will not be purchasing.

Well you don't seem to understand the issue, if you want to run a signed bootloader you need a key, you have to pay $99 to Verisign for that. Alternatively you turn secureboot off and continue as normal.

I think the real issue is that you may not have authorization to turn off secureboot. ...which, on machines supplied running a Microsoft OS, would be on by default (per Microsoft) .

Re:I'm sure I speak for all of us when I say

[AdamWill]

For the tenth time, the Microsoft certification requirements include a requirement that the user must be able to disable secureboot.

Re:I'm sure I speak for all of us when I say

[exomondo]

I think the real issue is that you may not have authorization to turn off secureboot. ...which, on machines supplied running a Microsoft OS, would be on by default (per Microsoft) .

That's not an issue, it's clearly defined in the certification requirements that the feature MUST be available.

How so?

[marcosdumay]

Microsoft requires that UEFI machines hold only one key. If they revoke one key, well, that is the only one...

Re:How so?

[RightSaidFred99]

Lie. Lie, lie lie. Why are you lying? Microsoft requires that their key be included, it does not require that no other key can be included.

Re:How so?

[oursland]

Sounds like you don't believe that they would enjoy the ability to remotely disable anyone's computer anywhere. This is also a feature that governments and media interests have been desiring for a long time. They're getting their shut down the internet switch and now they're getting their shut down people's PC's switch. The people? We're getting the shaft.

Re:How so?

[exomondo]

Microsoft requires that UEFI machines hold only one key. If they revoke one key, well, that is the only one...

Are you trolling or you just don't know anything about this? In no way have they required that UEFI machines hold only one key, that assertion is just false.

"Good faith"...

[GT66]

means: we're too lazy to hash this out now but we'll be sure to act surprised when they screw us later.

u-boot on x86, EFI is just a jobs program.

[bored]

Yet another reason to get better x86 support into u-boot. U-Boot is already everywhere, and seems to have won the race to be a BIOS replacement on every new platform. It works really well, POSTs and configures the machine generally in under a second, understands FAT/EXT2/etc well enough to directly load a linux kernel, yet is low level enough to just load a MBR like bootloader,etc.

Basically, it does what the BIOS should be doing (configure basic RAM/CPU/Disk/network, only enough to start something else).

Frankly, as I sit here waiting for my nice new IBM desktop machine to waste 5 minutes rebooting UEFI, I just want to smash the machine.

Re:u-boot on x86, EFI is just a jobs program.

[Microlith]

It's not UEFI that your system is spending 5 minutes rebooting.

Re:u-boot on x86, EFI is just a jobs program.

[bored]

Thats funny because its says "starting UEFI" for 30 seconds, then it sits in some kind of EFI configuring devices screen for 3 minutes, then it starts scanning PCI devices, for another minute or so. Finally, it gives me an option to run the PCI/BIOS option roms, (which I skip). At that point grub starts.

That is a IBM desk side (to lazy to look at the model number), the x server in the lab takes probably 2x that long, not including the two minutes or so while it boots linux on the service processors if its started cold.

I was irritated with the bios manufactures after having a MR BIOS machine a few years ago that basically POSTed and booted fast enough, that it would display "waiting for disks to spin up" (when cold powered on), and immediately start lilo as soon as the disks had finished spinning up. Total BIOS time was 5 seconds.

Re:I don't the EU will let MS get away with crap l

[marcosdumay]

Yes, I also think they'll act, too bad they didn't do anything yet. If they wait too much, whatever they do won't make any difference. What are they waiting for?

Intel Insider

[ak3ldama]

Can we disable Intel Insider? Who is asking for these Trusted Computing mechanisms? Surely it isn't the customers. I wouldn't want an UEFI motherboard with Secure Boot, and I won't be buying a Sandy Bridge chip either. I never found myself wishing my computer was more locked down.

Re:This, again?

[RightSaidFred99]

So don't fucking by an ARM device. How hard is this? There are already lots of ARM devices with forced secure boot.

Disassembling UEFI

[Taco Cowboy]

Some kind souls are trying to disassembling UEFI

http://board.flatassembler.net/topic.php?t=14306&postdays=0&postorder=asc&start=0

Brazil 2.0

[ThatsNotPudding]

Buttle, pulling out UEFI chip: "Ah, there's your problem."
Lowry: "Can you fix it?"
Buttle: "No, but I can replace it with this."

UEFI locks our PC, and we have to pay to unlock?!?

[lpq]

How is this not extortion?

That used to be illegal.

Re:Insane Complexity

[gottabeme]

I'm a huge Linux supporter--been using it full time for going on 9 years--but I'm also realistic. I don't think MS shooting themselves in the foot with Windows 8 will help desktop use of Linux as much as you think. Apple, sure, but Linux doesn't have enough mindshare among the public to get major OEMs to consider offering Linux preinstalled for consumers. Dell practically gave up on their Ubuntu offering, sadly.

I think it will take much longer for Linux to really benefit from MS's spiral. Maybe in a few segments of enterprise markets, but most won't want to use CrossOver Office. I think what is more likely is for MS to focus more attention on Office and other products and very slowly cede OS marketshare. Most consumers still care more about gaming and random Windows software, and that will hold back Linux adoption there.

Also, KDE and GNOME have, sadly, not reached the potential they had, say, five years ago. They could be killer by now, better and prettier and easier than OS X, but other than their FOSS values, they're no better than equal. They've become bloated and awkward, and they don't care enough about the product aspect to polish anything; they just keep adding stuff, letting half-baked stuff rot, and fantasizing, releasing components that are years away from being ready for general release (eg Akonadi, Nepomuk). The CADT model is the norm, and that doesn't make for a polished product that can compete with OS X in general markets.

But as long as Linux remains usable on desktop hardware. I'll be happy. I just hope this UEFI stuff isn't the beginning of. "First they came for the ..., and I said nothing..." In five years will it still be bypassable, or will that be a DMCA violation? Will we have to get a BIOS crack off TPB just to install Linux?

Holding back the tide gets tiring.

Re:Stop the misinformation

[gottabeme]

Yes. Thanks for all that.

My concern is, what is their next move? What about the specification for UEFI 2? Will the bypass still be required? Will that be a DMCA violation?

Also, sadly, requiring the BIOS bypass will probably hurt Linux adoption by the general public more than you think. If people perceive it as disabling safeguards, many people will perceive Linux as dangerous. Being ignorant of the tech and of Microsoft's maneuvering, it's practically inevitable.

Apple probably stands to gain the most in the next 5 years.