Slashdot videos: Now with more Slashdot!

View

Discuss

Share

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

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.

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

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.

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!

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.

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

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?

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.

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.

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

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

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.

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.

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?

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 O

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.

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.

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

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.

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.

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 regu

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.

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.

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

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 de

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 th

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.

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.

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 pay

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!

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.

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.

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.

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.

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.

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 t

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)

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.

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.

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)

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 dec

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

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.

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.

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

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.

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.

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 l

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.

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 vulnerabil

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.

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

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

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.

"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

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.

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, so

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

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.

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.

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.