Hacker News new | comments | show | ask | jobs | submit login
Torvalds clarifies Linux's Windows 8 Secure Boot position (zdnet.com)
204 points by mtgx on Feb 28, 2013 | hide | past | web | favorite | 144 comments

I always thought that the secure boot is a very, very, very bad idea.

In fact the whole UEFI in general I think it is a clusterfuck of mishmashed random ideas, some good, many bad.

What I intend to do personally, is attempt to don't use secure boot.

And this all might explain the e-mail I got from Lenovo 10 minutes ago...

I asked them for a non-Windows machine. They replied saying that they from now on only manufacture machines with Windows. At first I was: "wtf? why?" now this article remembered me that now we have firmware tied to Microsoft, and this explains then why ThinkPads must come with Windows.

Here in Brazil this is illegal, and Lenovo for example got sued (and lost) once. I hope a rain of lawsuits make this shit stop.

I think the Germans were pretty concerned about this, too. I could definitely see a lawsuit against them there, considering how "weird" (but usually right) Germany is when it comes to things like these.

I'd love the European Commission to chime in, too.

This is definitely a competition issue

What exactly is illegal? Selling a machine with OS or not selling it without one?

And as for the "this explains then why ThinkPads must come with Windows" - no. It doesn't explain it. Secure boot has to be present on Windows certified machine, not the other way around. Lenovo can sell whatever they want (but apparently it's beneficial for them economically to only sell Windows machines).

Also, certified machine has to have secure boot disable-able. So it's not about you not being able to use the machine with Linux, it's about not being able to use Secure Boot with Linux.

What is illegal is not selling a computer without an operating system. From what I understand, brazilian law considers the PC and OS two different products and it is illegal for a company to only sell you one product if you also buy another one tied together. In my company, we buy all our servers and workstations from Dell and it never comes with a Windows license unless you explicitly request to the sales person. Although, I remember at least one case where we bought a laptop and the seller said it would come with the most basic windows 7 version because it was free for that particular laptop model. I don't know what would have happened if we insisted in having it shipped without it.

>What is illegal is not selling a computer without an operating system

Does that apply to Macs, Chromebooks, iPads too?

IANAL, but I think the key difference is that these operating systems are not sold as a standalone component you can buy and install on any pc you like. That's why it applies to a Windows license and not to a Mac OS license for example.

If it's like France; it's technically illegal too, apple just never has been in front of a judge about it (and when they do, I guess they will argue that they sell the disk and not the license to use the OS).

I didn't think of that, I agree this is more likely the explanation.

Responding from a French point of view, so that might not match Brazil (but does match Germany): you can not tie a material product with an immaterial one, if you do not also sell the material product as a stand alone.

You cannot sell a car with an insurance if you don't sell the car alone.

You cannot sell a phone with a plan if you don't sell the phone alone (see: iPhone 1 release in Europe).

You cannot sell a computer with an OS license if you don't sell the computer alone (you're not buying the disk, but the license to use the software on it).

Interesting, I know that in Brazil the same law applies even if both products are immaterial. For example, it was common for nightclubs here to give you an option of charging less (or nothing at all) for the entrance into the nightclub if you spent a certain amount of money in drinks or whatever else they sold inside. This was also prohibited by the same law since it was tying two separate "products". Wikipedia article (in portuguese) on this law cites that even ( http://pt.wikipedia.org/wiki/Venda_casada ).

Drinks seem like a material product to me, they're a consumable physical liquid.

The right to enter the nightclub is an immaterial good, along with software or cellphone service.

Actually this is a really well-thought-out law.

You cannot sell a computer with an OS license if you don't sell the computer alone (you're not buying the disk, but the license to use the software on it).

Sure you can. I bought a very nice MacBook Air in Paris a couple of months back - and you most definitely can't buy a MacBook Air without OS X.

The fact that something is illegal doesn't mean people are never doing it; it only means they lose when they go to court.

You cannot drive over the speed limit in France, but "sure you can, I just did this morning".

There are plenty of court cases, all won by the buyers, where the complaint was that the computer was sold with a windows license, and couldn't be bought without.

In France you can ask the store to erase the default OS install and be refunded of the price of a standalone OS X. So there you have it.

I think the issue is: to buy a Lenovo machine is to buy Windows. There is no other option but to have to pay for Windows with your machine. One can't just buy a laptop with nothing on it. This can be seen as unfair to the customer in many countries and therefore, illegal.

Don't buy Lenovo, then. Places like e.g. http://www.pcspecialist.co.uk/laptop-computers/ sell custom laptops without the Windows tax.

Can I buy a Toyota car without the Michelin tires they bundle and get a discount? I want to install my custom tires and have no need for the tires they bundle.

If they put a mechanism to specifically total the car if you try to use any other brand, I'd say they would be getting sued before you can say "anti-trust".

Trying to boot Linux does not "total" the computer.

Turn it off , and you can boot whatever you want.

The analogy is sorely broken.

Trying to install it can total the computer, esp. if you are unaware of the relatively new locking measures.

I did something similar to this with my Volkswagen. I wanted different tires, wheels, and a different stereo from what was on the car they in the lot. I ended up paying about $500 more, but received exactly what I wanted.

Of course you can. You just haggle with the dealer.

Having firmware locked to only work under a given OS. It's pretty much a textbook definition of anticompetitive practice.

First of all, the firmware does not prevent you to use other OS. Only one function is locked to Windows and it seems Microsoft is open to allowing others to boot with it [sidenote].

Secondly, every single iPhone/iPad is locked to boot iOS; most of the phones with Android are locked as well. (And obviously Windows phones are locked too). And by locked I mean locked, not few clicks away from using the device as you wish (as is the case with notebooks and desktop computers). How come it's not rendered illegal?

Sidenote: I agree with the fact that Microsoft shouldn't be the one deciding who gets the key and who doesn't. My opinion on this is that if everyone can't agree on one impartial organization then hardware manufacturers should be the one deciding it. Obviously it would be best if users could add their own keys.

It would be suicidal to accept that, it would settle a tremendously dangerous precedent.

This should never be accepted, full stop.

Google ships Chromebooks with secure boot enabled too. Does it get a free pass because it's not a monopoly?

Not sure why you seem to assume I give Google a free pass.

Hope they get sued to high hell, but in the meanwhile I'm just not buying them as a computer that's useless outside of Google's cloud is also outside of my interests.

To be fair, they also clearly publish how to enable "Developer mode" which lets you do more or less whatever you want for each new model of Chromebook.

Admittedly, it's harder for some than others: http://www.chromium.org/chromium-os/developer-information-fo...

>Does it get a free pass because it's not a monopoly?

That would not be unprecedented. Part of the US anti-trust code says you cannot tie one product to a monopoly product. It's one of the reasons MS lost their anti-trust case vs the US DOJ back in the 90s, illegally tying secondary products to their Windows monopoly.

That might not directly apply in this case, not sure, but to answer your question, yes being a monopoly or not does effect how anti-trust laws are applied to you.

How about multi-boot? From my understanding that isn't going to be possible anymore.

It is possible with disabled secure boot. Windows 8 doesn't need Secure Boot or even UEFI to work. It's only about the "Certified" sticker.

And theoretically, Grub (or something) can have the key signed.

(Asking out of ignorance...) Signed by whom? Who are the trusted CAs for secure boot? Can you import an arbitrary certificate as trusted?

Microsoft is the trusted CA.

I think I'm largely out of touch with the average computer buyer of today but is it literally only about a sticker? What if instead of "Windows 8 Certified" the manufacturers put a "With Windows 8" and completely disregard the entire secureboot fiasco? Is there an option to NOT play Microsoft's game at all? I assume that MS would allow manufacturers to bypass the SecureBoot requirement if they don't want to avail of the "Windows 8 Certified" sticker.

More importantly, how much would this sway a decision of a consumer (one place where I find 'consumer' better than 'customer') who sees two similar laptops with very similar prices except one say "With Windows 8" and the other says "Windows 8 Certified".

Could the manufacturers not come up with their own marketing campaign or something like "OpenSource Initiative Certified" or something like that[obviously they can't use OSI's name but you get the idea].

I'm not sure Microsoft would let you sell Windows on non-certified hardware. That is you would have to use non-oem license and it will be more expensive for you. So the prices probably wouldn't be similar.

> It is possible with disabled secure boot. Windows 8 doesn't need Secure Boot or even UEFI to work. It's only about the "Certified" sticker.

And you dont think that is a political choice?

"I hope a rain of lawsuits make this shit stop."

Is that really the appropriate response to a company that basically made a choice to not offer the type of product you are seeking? Buy what you want from someone else ... problem solved. When you can't buy from someone else...then there's a problem.

I just bought a UEFI laptop in Vietnam that was Lenovo brand, it came unlicensed with windows, but fully supports secure boot in to it.

Are you sure this isn't just a regional sales thing, not selling a Windows Free version in that teritory?

As rplnt as said: > but apparently it's beneficial for them economically to only sell Windows machines

Maybe in Vietnam it happens just the opposite. It's easy to sell a computer _without_ Windows that with it.

I don't get why the companies cannot sell "empty" laptops without OS installed, thought.

even that one had Free DOS installed.

Handy for a quick memory test

>Maybe in Vietnam it happens just the opposite. It's easy to sell a computer _without_ Windows that with it

That is because most of the PCs end up being installed with pirated Windows by the local tech guru.

>That is because most of the PCs end up being installed with pirated Windows by the local tech guru.

My Vietnamese friend had to explain that the staff in the shop expected to earn $5 installing the pirated windows on it... They where not best pleased that I intended to do it myself (with a licensed copy obviously!)

>In fact the whole UEFI in general I think it is a clusterfuck of mishmashed random ideas, some good, many bad.

Care to explain why or how, instead of just throwing a general statement around?

Here is a talk from the Linux EFI implementer: https://www.youtube.com/watch?v=V2aq5M3Q76U

Because UEFI is overly complicated and more akin to a mini-OS. All most people really want is for the firmware to set up the hardware and then hand over to the bootloader.

Isn't the BIOS supposed to be a mini-OS. It provides a common interface for different hardware platforms so software works on all of them. Of course then our address space increased, so you can only use many of those BIOS features in real mode. Then modern OS's reimplented those BIOS features. What we have now is an old mini-OS that has been hacked around to run modern OSes. UEFI is a welcome solution to that problem.

Isn't that what is already does? In fact it is so fast handing control to the OS that in Windows 8 Microsoft had to add an option to restart into UEFI settings mode. Which features are unneeded in your opinion?

Secure Boot.

Well, duh. You aren't responsible for users getting rootkits installed on their computer. Obviously you would find it useless.

Sounds more like a user education problem to me. We don't let people drive without a license I don't see why we should worry about the people who use computers and don't bother to read up and understand what they're using.

In before "everyone should be able to use computers and they should just work" - I agree, it should be like this; however, the hardware, software, and usability has just never been at that level - and won't be for some time. Thus I dislike that argument.

I do understand this means we should be making things better as we go, I just don't see how this is one of those things, nor do I see how proper education should be lacking for the time being. To put that in the car analogy: Should we let people drive around because they need to get to work today but don't have time to sit the license right now?

Disclaimer: Opinion, and I'm a huge usability fan and hope one day things do "just work", I'm just also a realist and don't see the logic behind letting people use something before they or the thing is ready for them.

Edit: Just realised I went on a bit of a mad rant and kind of went a bit off topic. Apologies.

If you need an explanation as to why a encrypted only closed platform shouldn't exist, you're already off the mark.

You know what, this comment is really rude. UEFI is a pretty complex topic, and it's reasonable for people to ask questions about it.

In Brazil or anywhere, can you buy a car with the default sound system ripped out and get a refund for it? What about without the default tires, seats or even the engine?

Actually, yes.

You can ask here for cars without sound system, air conditioner, airbag, electric windows....

Never saw a lawsuit on that though, maybe because I never saw a manufacturer be stubborn regarding that.

The default tires and default sound system have residual value when ripped out. I am sure that the dealer would be happy to give you some fraction of their worth and then provide you the car without them. Or you could sell them yourself.

Windows, OTOH, is something that you pay for, but generally comes in an OEM license. This license is non-transferable in most cases.

I'm not sure the dealer would be willing to refund you for the factory sound system because the residual value of the factory sound system is almost certainly miniscule compared to the cost of labor involved in removing it.

Why is the residual value so small? Lack of standardization. A lot of automakers use their own mounting system for the head unit, which means if I bought a Lexus and asked the dealer to take out the head unit, the dealer wouldn't be able to turn around and sell it to somebody who wanted a better unit in their Ford. It goes beyond the mounting system though.

A lot of automakers have their own plug and wiring standards too. If you buy an aftermarket head unit, you usually get a pigtail that plugs into it with unterminated wires on the other side. Then you buy a wiring harness kit specific to your car which has unterminated wires running into a plug that connects to the vehicle harness. Soldering ensues (or wire nuts or electrical tape for the lazy...). Since the aftermarket does have a strong incentive to standardize, the wires on the pigtail that come with the head unit match the colors of the wires in the harness kit, which actually make the process pretty straightforward if you're even halfway handy.

What all of that means is that the unit out of your hypothetical Lexus (which doesn't come with a pigtail with unterminated wires) is going to be hell to get working in somebody else's Ford. Between the physical and electrical incompatibility, the residual value of a head unit has to be pretty close to zero for anybody who doesn't own basically the same car.

I'm as much in favor of car analogies as the next person, but I don't think yours really fits the situation.

It might fit if speeder was trying to buy a laptop without RAM or a hard drive so he could put in his own, but my reading of your comment is that you're talking about having a physical part of the product removed and wanting a refund. What speeder is asking for seems more like asking Lenovo to offer an option to order a car with an upgraded the sound system, tires, seats, or engine. This is something many auto makers offer.

It seems that Lenovo, in this case, has decided that the market for cars with steel wheels is too small, and is selling cars without that option. You can only get alloy wheels on your Lenovo car.

You can buy any car part you want, from the whole car to every single piece individually, in the US. Just ask your car mechanic.

How many makers of car stereos control 90% of the car stereo market, and use that market share to force makers of cars to put their stereos in every car they manufacture? Oh, none? Well then your analogy fucking sucks and you should stop using it.

The thing about secure boot is that it is a GOOD idea done very badly indeed.

What was needed was for a trusted neutral party(or two) to be the owner of the root key, and for that organisation to hand out child keys (e.g. Microsoft, Open Source Initiative, Apple, etc) who could in turn generate child keys (all of which could be revoked). Essentially we need the "internet model" of key exchanges for this too.

I cannot understand who thought it was a good idea for Microsoft to be the only authorised party to generate keys. Even from Microsoft's perspective it is just asking to get anti-trust-ed again.

The internet model of key exchanges sucks, and there is currently much wailing and gnashing of teeth over what to do about it. That's what linus is talking about here:

"They are almost certainly going to be more secure than depending on some crazy root of trust based on a big company, with key signing authorities that trust anybody with a credit card."

Not to mention this kind of thing: https://bugzilla.mozilla.org/show_bug.cgi?id=476766

Also, when it comes to stuff this important, there is no such thing as a trusted neutral party.

The internet model of key exchanges /does/ suck, but yet somehow the Secure Boot model is yet worse still.

The main issue with the internet model is how uncompetitive the whole thing is. You have just a few companies handing out keys and they charge upwards of $50 a year just for the "pleasure" of having secured communications.

Secure boot would likely suffer from the same problem. But yet I'd still take that over this...

The nice thing about SecureBoot is that there is no root key—you can have whatever keys you like installed on your system, you don't have to get permission from a central authority. If you want code signed with your key to run out of the box on random PCs, you just have to convince each PC manufacturer to include your key in the hardware key-store of the systems they ship, a purely independent transaction.

It's just that, well, there's only really one software manufacturer with enough clout to get all the hardware vendors to include its key, and it's a heck of a lot easier to just get a sub-key signed by their master key than pretty much anything else.

Yes, this is the issue I see in all this.

None of the linux vendors banded together to create a NPO which would simply manage keys, ensure it was avialable to all manafacturers. Maybe even provide a logo/stamp/certification/brand so people can instantly see it's supported.

The fact that ONLY Microsoft have done this isn't really the fault of Microsoft. The fact that devs can't agree on the most elegant way of providing the chain of trust, in a manner which plays nicely is again, not Microsofts fault.

Yet Microsoft is being flamed for this.... Why exactly is this their fault?

What about Haiku, or any other OS which doesn't have a big enough community to get their key in? Why should OS installation be a privilege of popularity, with others forced to jump through hoops?

MS is at fault for pushing this whole system. Whether Linux distros could or not join the system is a red herring.

>MS is at fault for pushing this whole system. Whether Linux distros could or not join the system is a red herring.


Pushing UEFI, which isn't their design, which has been used by Apple and other for years, or pushing secure boot?

Secure Boot is a damned good idea, and whilst IANAL it appears that for a windows sticker you MUST allow it to be switched off.

So its Microsoft are in fact pressuring OEMs to ensure that people can run other OS's on their kit (except ARM).

What this is about is how the other OS's can get the benefit of SecureBoot, well, if they can't get their act together as I mentioend above, why should they fuss that someone else gets SecureBoot. Lets be hoenst too, most people who need such simple "mum proof protection" are on Windows anyway.

The real use for secure boot is within a single company/organization where you want to control exactly what runs on the computers you own. That's an argument for secure boot to be switched off by default, and for the companies that want it to manage their own keys.

Although Microsoft will now point at me and say "but, but we need to prevent boot sector viruses!" it's telling that no other operating system except Windows commonly suffers from this problem.

> it's telling that no other operating system except Windows commonly suffers from this problem.

This is an honest question, as this area isn't my specialty, but could this be for the same reason that people used to perpetuate the myth that Macs don't get viruses? Attackers simply target the platform with the largest market share.

Linux servers are far more common than Windows servers, and servers usually have loads of bandwidth making them especially valuable targets for spammers and fraudsters.

You don't gain much from having root or kernel level access if you're just sending spam from a machine running an OS that isn't typically checking for malware. Windows is a much more attractive target because you can also get user's bank and credit card details, but doing that entirely in userspace will get you picked up by the (now fairly ubiquitous) malware scanners. There's a strong incentive to move yourself into the kernel there.

But Linux servers require root access (or physical access, which frequently amounts to the same thing) to modify the bootloader. If you've already got root, then you don't really need to install a bootkit - you may as well just install a modified kernel or kernel module rootkit.

Unlike desktops, servers are mostly run by people who have at least some idea of what they're doing.

the key word in your sentence being some.

>it's telling that no other operating system except Windows commonly suffers from this problem.

There is nothing whatsoever stopping Linux bootkits technically. Please stop spreading FUD.

No it's a shit idea from end to end.

Any PKI based system is a shit idea unless you are personally in control of the trusted root CA, which in this case you're not. I think that is what Linus is saying.

Google for "certificate authority compromised" and you'll see what utter wads of shit for brains this could be entrusted to.

You can be "personally in control of the trusted root CA" using SecureBoot. Just replace the Platform Key with your own key.[1] Or am I misunderstanding your objection?

1. http://blog.hansenpartnership.com/owning-your-windows-8-uefi...

Yes I know this but its more the fact that there is no CRL that a new device can import so you are not in control of the pre-seeded keys. So if you have kit on the shelf for months and MS's private key is leaked or cracked then you have a large stock of compromised machines waiting to roll. I doubt any average PC retailer will be able to deal with manual key revocation. The same goes for your average government agency or health service.

It should ship with no PKI/certificate scheme at all. We don't need it and it doesn't work and its blatantly obvious.

Secure boot is entirely worthless from end to end.

>Any PKI based system is a shit idea unless you are personally in control of the trusted root CA, which in this case you're not

With UEFI secure boot, you can delete Microsoft's key and add you own.

What advantages would any system controlled by a central authority give you that a system which was entirely local and required specific manual intervention (e.g. typing in a pre-set password or private key) in order to authorize any change to the boot loader would not?

"trusted neutral party"

Such as?

Should Microsoft trust WC3?

Or Foxconn trust the United Nations?

Every organization requires funding. How would this party receive it?

Because the world is unfortunately short of philosopher kings, we are probably better served by the marketplace when it comes to hardware manufacture.

I don't know if there's really a good way to implement it.

No matter how you do it, it seems to have the same problems as SSL CAs and certificates (that is, some CAs are corrupt/negligent/compromised).

And in your proposal, what do you do if the root key ever gets compromised?

From my read of the article, Linus simply states his preference to actually support secure boot (and verify signatures), or not support it at all. He thinks attempts to "Secure Boot" a loader which then allows arbitrary code execution are a waste of time, and they are. If you don't want boot time signature verification, you should turn it off, not break the chain of trust.

In fact, done right, perhaps hardware vendors that currently only provide binary blobs could be coerced into providing source. "Oh, you want to boot on our distribution? We don't sign blobs, but if you commit source we'll build and sign the module."

If ever hardware does come out that doesn't allow you to opt out of signature verification or provide your own keys, just don't buy it.

I'm glad Linus Torvalds is smarter than your average developer. Truly a solid chap.

If he were lacking these kinds of personality traits, and shrank like a mouse every time there happened to be an opportunity to compromise the integrity of his project, Linux would have died long, long ago.

Having read through the entire thread instead of just the expletives, in my opinion it's a rare case of Linux and Greg being totally wrongheaded on the issue.

The problem crops up because redhat submitted a pull request to enhance the existing in kernel live inclusion of additional trusted x.509 certificates. Note that this is 100% upstream and live. The pull was to add the ability to extract these x.509 certificates from UEFI PE binaries, as this is the only format they are available in from the only CA UEFI secure boot computers are guaranteed to trust - Microsoft's CA.

Linus decided he didn't like it because he didn't like the idea of extracting a certificate instead of having it alone. Understandable, probably, except that leaves you in a situation where a secure kernel that was executed due to a microsoft CA chain of trust now can't make use of that CA's code signing services to decide if it wants to run a module solely because linus doesn't approve of parsing the file format that contains the key.

The biggest place this comes up is binary only graphics drivers from ati and nvidia - without changes os's like fedora are going to refuse to run them because they're unsigned, which is unfortunate considering how uneven some of the open source 3d drivers are and the heavy reliance on 3d in all modern desktops environments.

Meanwhile microsoft is perfectly willing to sign these drivers and has an existing substantial CA operation. Both ati and nvidia submit their windows drivers for signing to this CA all the time, so it'd be almost no extra effort for them to get their linux shims signed as well.

But because linus thinks parsing a PE for a signed module key is asinine, he goes on to provide a series of rather off the cuff alternatives:

a) Every distro should parse the PEs and add every key of every 3rd part module they wish to allow to run and embed these in their signed kernels, issuing a new kernel every time a driver revs.

b) ok, maybe that's not ideal. how about every distro that wants to allow binary drivers to run builds their own CA infrastructure, verification and qualification team and revocation infrastructure. So that's a team at cannonical, redhat, novell, mint, oracle, ibm, etc. etc.

c) ok, maybe full ca teams are a bit burdensome. How about all you distro guys just blind sign the binary drivers with your own signing key - worrying that MS might revoke your key because you blind signed an exploit is pointless fearmongering.

d) ok, you're right this is harder than i thought. let's just collectively decide that users with secure boot enabled will be prevented from running any module not shipped by the os vendor. Aka fuck off unless you're using intel video.

e) alright, maybe that's a little severe. Instead let's just punt entirely - even though we're going through the trouble of a chain of trust from firmware to boot loader to kernel to most modules, let's allow any unsigned binary module to be loaded by default.

f) ok, i guess that kind of defeats the purpose. None of this is good security anyway - what we should be requiring is any user that wants to use secure boot should generate their own signing keys, add them to the firmware and then parse and sign everything they trust, repeating the process every time they update while of course protecting the signing key from attackers.

I think that about covers it. Linus is really smart, but sometimes he makes a snap decision and then will perform whatever mental gymnastics are necessary to defend it to the death. And most of his inner circle will publicly go along with it because of the real chance he'll pay you back by randomly torpedoing something of yours sometime in the future.

Linux's signed code infrastructure is currently the worst in the industry and Matthew and Redhat have provided the bulk of the improvements that everyone is using. It's going to provide real user benefit, even if the users are paralyzed by FUD. Getting in the way of the process or trying to punt it out of mainline and onto everyone who ships a distro isn't going to help anyone.

> Linus is really smart, but sometimes he makes a snap decision and then will perform whatever mental gymnastics are necessary to defend it to the death.

Hmm, could it be argued that this is less a snap judgement and more one of strengthening the long-term political and technical health of the OS? Rather than take the easier short-term path, which may eventually put Linux's metaphorical balls into a Microsoft vice, he would rather expose some pain now to defend as much as possible long-term autonomy. I would imagine this to be true given Torvald's historic ability to keep Linux healthy and viable in spite of one of the world's most powerful corporations.

Thus, in the short term, the user must perform some gymnastics to boot new kernels, but if this inconvenience is really that painful, it will create market disequilibrium that will motivate creative solutions. Some naive, off-the-cuff ideas:

- vendors pre-installing trusted root certs for Linux distros or a consortium of them,

- vendors making it easy to disable SecureBoot (physical switch?),

- vendors forcing SecureBoot configuration/opt-in on very first boot,

- UI, tools, or documentation enhancements to make local key management and signing easier, or

- simply a slightly more aware userbase (the same way phone locking/unlocking became a mainstream concept).

I don't think there is much evidence for this being part of a long term plan on his part to resist microsoft's influence.

If that was the primary concern where was the criticism when his employer, The Linux Foundation, announced with great fanfare that they had released a microsoft ca signed boot loader to support linux uefi secure boot with the default oem trust setups.

If there is anyone that has a chance at providing a FOSS UEFI signing alternative to Microsoft it's the Linux Foundation. But they're unwilling or unable to do it. Redhat is unwilling to and has proven they have trouble securing their signing keys. Canonical tried and failed to sell vendors on including a ubuntu key, and they weren't even looking to sign for other companies.

There will soon be plenty of people running linux on their computers with secure boot enabled and relying on Microsoft's CA for a chain of trust. It's a done deal and no one is out there stepping up to provide a viable FOSS PKI alternative.

The only thing being debated here is if many of them will be running rather slow and buggy video drivers.

"Naive" is an overly polite way of describing ideas which lead in with an idea that flies in the face of pretty much the whole history of Linux.

:) DH2, or DH3, at best. http://www.paulgraham.com/disagree.html

Market-driven vendor support of Linux is not unprecedented. Ever heard of Dell, Lenovo, Acer, Nvidia, or the Android ecosystem?

Your option E is perfectly reasonable if you don't care about secure boot. And most people don't. After all, computers have worked without secure boot since they were invented.

If you, as a vendor, want to support secure boot (as a new, optional, extra feature), I think option B (be the CA) is the only right way to do it. If vendors don't like having to do duplicate work then they can cooperate and form a shared organization to be the central Linux CA. Relying on Microsoft to do the signing is not a good idea long term.

Alternatively, Microsoft could sign x.509 certs. Why are they placing certificate data into Windows binaries in the first place?

The Linux kernel is simply not the place to parse Windows binaries. It's not Linus's fault the de facto standard is a Windows binary, it's just another harmful side-effect of the Windows monopoly.

Really SecureBoot should just die on the vine. But the monopolist wants to force it on their customers, so here it is.

Maybe Microsoft has patents on the PE format. And they're crossing their fingers and hoping Linus loses this argument, so they can become the next SCO and sue the entire Linux world.

Microsoft already has that "in". They've been claiming for years that Linux violates "235" of their patents, though they have always been pretty mute about which. They also sued TomTom for using Linux's FAT32 implementation. They settled that one, and iirc there have been some patches to Linux's FAT32 support since then, so the issue is a bit ambiguous, but the FUD has been flowing for years.

EFI uses the PE executable format.

For the average linux user, key signing isn't really a big deal, imho. Running as a user and protecting root without running unnecessary services is your first step, after that it's all kind of iffy.

Signing something from an untrusted source (Having dealt with having to revoke a bunch of Microsoft signed stuff not too long ago, I assure you Microsoft is not infallible) doesn't buy you a whole lot. If you build a driver yourself and sign it, ok. Actually that's probably the best way, download the nvidia driver, sign it with your own one-time key, and voila, even if someone pulls a Folgers Commercial on your driver, they really can't sign it, they don't even know where the one-time key came from.

For a normal user, the effort to try and hack your own signing mechanism seems like it would be non-trivial. Figuring out how to hack a giant 'trusted' signer is a pot of gold at the end of the rainbow. I would not be suprised if there are more compromised signing authorities right now. Flame was signed with a msft key that was actually not meant to sign code, but for several years, since this key was from msft, people happily loaded and ran flame.

I don't really think it's FUD to say trusting your security to the entity that attracts the most attention is not a great plan.

Your points are good, except I disagree that Linux's only beef is parsing PE files, I think that's really the least of his concerns. Msft could deliver up its keys in any form, it won't solve the insecurity of not knowing if your signer has been breached.

Good security is hard, I think that's the main problem with all of Linus's ideas.

For the average linux user, key signing isn't really a big deal, imho.

It isn't a big deal to the average user because os internals aren't a big deal to the average user. Never the less, linux hasplenty of industry standard security measures like IOMMU support, DEP, ASLR, containers, RBAC, seccomp and so on.

You can't expect the average user to know what technical countermeasures they need anymore than you can expect them to know what garbage collection or interrupt coalescence strategy suits them best. It's important for folks with domain knowledge and pull requests to look out for them. The only problem in this case is the politicization rooted in hatred of a version of microsoft that differs considerably from the one that exists today.

Running as a user and protecting root without running unnecessary services is your first step, after that it's all kind of iffy.

That's advice from a different era. On the desktop (any flavor) the attack vectors are almost entirely malicious attachements, plugin exploits, browser and supporting library exploits, other random outbound clients and social engineering.

While linux isn't a popular target, it is at least as vulnerable to these attacks as the others. And due to design issues in X windows, once you can run client native code it is trivial to sniff credentials from the next elevation event.

While it's not infallibile, requiring the rootkit or bootkit to be signed by a CA raises the bar dramatically.

I disagree that it's very political, I don't think it would be any better to designate the CA as Oracle, IBM or 37signals. If Red Hat wants to rely on msft as their CA, fine, but don't try and bring it to the kernel.

I don't think running as an unprivileged user as often as possible is out of date. Yes, there are plenty of attack vectors, but there's no reason to make it easy. You could run your browser as a different user, so it can't ever see your sudo commands or whatever, just common sense. I'm not familiar with X window exploits to sniff credentials, but I would assume the application being run as a different user than the x session would add difficulty?

FYI my day job is dealing with Windows, driver signing/loading issues, and what have you. I have very low expectations for the security-mindedness of average users. Many people will click on a link after an AV "warning", because "Hey, the AV will stop it if it's really an issue!"

The average Linux user is technical by definition. They will care a big deal about this issue.

> Every distro should parse the PEs and add every key of every 3rd part module they wish to allow to run and embed these in their signed kernels, issuing a new kernel every time a driver revs.

Why do they have to embed the ID of whitelisted modules in the signed kernel? Why not have a kernel that will load any module the root user tells it to load, then have userland insmod utility verify the signatures using a configuration file like /etc/accepted_module_signers.conf?

Because then your trust path includes the userspace insmod utility and every library and system service it depends on, all of which would themselves need signature verification and hardening against things like LD_LIBRARY_PATH (even from root).

Otherwise, you can easily construct a harmful payload consisting of the distro-signed Shim, that kernel, and a modified userspace that loads an arbitrary module which takes over the kernel and runs arbitrary code in ring 0. And then that distro's Secure Boot signing key gets revoked.

Wow, I think I learned more about Linux + UEFI from this comment than anything else so far. Thanks!

But Linus opposes third party modules, especially proprietary. He use only Intel hardware and has personal hate against NVidia. He want to force everybody to contribute to kernel. "Stable API Nonsense".

Err, why is this being downvoted? If anything, this should be pinned as the top comment.

Anyway, thanks for an excellent and detailed technical take on the situation as opposed to the knee jerk bashing in many of the other posts.

There's also some excellent detail in the below article without the histrionics.


> What they've told us privately is that as long as no-one comes along with a plausible exploit for Windows based on using a secure boot enabled Linux system, they don't care what we do.

I guess we need to hide all those forensic distributions that can modify and access data on a windows machine. To name a few: backtrack, CAINE, and DEFT. If technology can modify and access data, it can also be used in an exploit. Some might even argue that running a forensic on a computer without the owners permissions is an exploit in itself.

Edit: How could such technology be used you say. Package a usb drive that once plugged in, will reboot the machine and load a Linux distribution. Once loaded, it automatically modify the windows system and transfer any interesting data it find. Afterward, it erase itself and reboots, thus looking like any empty usb drive once windows boots up. If that is not an plausible exploit which an ordinary Windows users could trigger and become compromised, then I would like to hear the definition of an "plausible exploit".

Sure, it modifies Windows. But if it modifies the Windows bootloader, Windows refuses to boot. If it modifies the Windows kernel, the bootloader refuses to load the kernel. If it modifies any Windows drivers, the drivers won't load. So you modify userspace, but under Windows 8 the (signed) malware checker is started before any other userspace.

So you exploit the kernel (or some driver), do whatever evil shit you want, then lie to the signed malware checker. You now have an APT that ignores this whole notion of secure boot.

Come to think of it, this is every modern rootkit. You try to remove it and it reinstalls itself.

There's not intrinsic reason why you have to modify the kernel that sits on disc. Now there are lots of other checks and features you can add (that already exist) to make it harder to get access to the kernel, to make sure that unknown objects are purged or flagged on reboot, etc.

The thing is, this secure boot doesn't seem to significantly make your machine more secure than current TPM-based methods involving sealing a hard disk decryption key that is only unlocked based on checksums of firmware, nvram, bootloader, kernel, etc.

No, there's no intrinsic reason why you have to modify the on-disk kernel. It just makes detection more difficult, because there's never a point where the OS is running without having been compromised. That makes detection much harder.

You're right that this is no more secure than using a TPM. But most consumer-grade hardware has no TPM, and hardware vendors aren't going to add one just for Microsoft.


"This 'plausible exploit' has to be some way of getting ordinary Windows users to run the code and become compromised, it's not an experienced Linux user becoming root and subverting Windows on their local box."

I do not think that you understand the suggested attack scenario.

Pen testers are already familiar with the idea of leaving compromised USBs in a parking lot. A lot of normal users will pick one up, carry it in, and plug it into their computer to see what's on it.

If the USB key will send your data to a third party, without user understanding or intervention, then that's a security problem.

Thinking about it, here is a bit more insidious (and complex) method:

The usb drive install a linux system over the previous windows installation. Then it install a VM, and set it to run the old windows installation. Have boot set to quiet and on startup, load up the VM.

While a bit slower, you now have hypervisor control over the machine, and the user can install how much anti-virus and anti-rootkits they want. You effectively eradicated the secure boot scheme with the help of the Red Hat key.

Do I read this right? Is somebody suggesting teaching kernel to read some stupid shit MS "PE binaries"!?

Go, Linus. Let kernel NOT even boot on these secure boot machines, see who runs back crying first.

Dells and HPs of the world are already hurting from Windows 8 disaster. Let them lose some of the server market and all the commercial customers that buy PCs and give them to devs who install Linux right away.

How are PC vendors hoping to sell laptops to corporate buyers whose IT departments want to reimage all those machines (a lot of them with Linux images) without wasting time going into UEFI setup menus to turn off Secure Boot one machine at a time?

these cases are more easily covered by the corporation's key being included in those machines. big numbers of machines warrant that kind of effort from the manufacturer. the problem is when I want to generate my own key and use that as the only authority. the system doesn't support that model.

>the problem is when I want to generate my own key and use that as the only authority. the system doesn't support that model.

It does. You can add your own key and even remove Microsoft's if so wish. The facts are getting lost in this FUDstorm.

Well it wouldn't have been a fud storm if Microsoft hadn't insistet on it being turned on by default.

But if I were to remove a MS key, am I right in assuming that that would prevent anybody from running windows on that machine (at least without installing the key or turning it of)?

Security features that are off by default don't provide much security.

Yes, as I understand it, if you remove the Microsoft key but leave secure boot on, it will refuse to boot Windows. So long as it's on, it will only boot an OS signed with a key it trusts. If you turn it off, it will try to boot whatever's on the disk.

If it's turned off by default, it might as well be useless to protect the hundreds of millions of non-technical users who are more prone to get malware.

>But if I were to remove a MS key, am I right in assuming that that would prevent anybody from running windows on that machine (at least without installing the key or turning it of)?

Windows 8 boots fine without Secure Boot enabled or even supported.

However, if you remove Microsoft's key but leave Secure Boot enabled, you're indicating that you don't trust Microsoft's code, in which case Windows will be prevented from booting on that machine.

What is the value or the use case in removing Microsoft's key, leaving secure boot on and then trying to boot Windows on that machine?

The only real reason that I (as a Linux user) can see is for the amusement value, as well as the opportunity to watch others fail to boot Windows on this machine and the opportunity to engage in an extended philosophical discussion regarding this event.

Mind you, I might be a niche case.

What extended philosophical discussion do you intend to have? You told the computer not to trust MS code, then the computer refused to boot MS Windows.

What a clusterfuck this situation is.

I'm just going to put my fingers in my ears and not listen to anything anyone might say (write) that gets close to excusing the current situation or defending Secure Boot!

As such: Secure Boot is just another lame attempt by Microsoft to slow down/control the competition; they are abusing their position on the market once again, like they did in the past, like they will do in the future. This is their way, "the wolf changes its coat, but not the disposition".

This shows that now more than ever Microsoft is shitting their pants because of Linux/Android/Google/Ubuntu/RHEL/LibreOffice/FOSS SQL/etc; they are slowly but surely losing the war, they are losing market share on every front. The way things are now in 10-15 years I bet they will no longer have the 90% of PCs share they have today, but Secure Boot might give them some help.

I can already imagine mr. Ballmer rubbing his hands in satisfaction: "oh, nice, we'll have the keys to all PC hardware".

My advice: do not buy Microsoft, do not buy hardware on which Secure Boot cannot be disabled. We _must not_ have all PC hardware controlled by a single company - it is just stupid.

And of all systems they chose CA? Really? After the epic way it failed time and again in the SSL cert industry - think Komodo or DigiNotar.

Not to mention keys given to USA and other governments that will be able to easily install malware and other crap to control the "sheep" (the germans already have some "official" trojans lol).

This is madness people.

Is it possible to "sign" windows 8 and other windows drivers with your own root key so you can have your own key in UEFI and have windows still work?

I'm guessing that microsoft has no options for this at all, but I don't know for sure.

Yes. You can sign the binary the same way Microsoft, or anyone else, would sign the binary. At that point, you need only to add your public key to your key database and are good to go.

Microsoft has no way to prevent this (short of requiring vendors not to allow people to add keys).

MS becomes so hateful with the secure boot trying to control everything. I will never buy any machine with secure boot enabled and will boycott any MS product.

What if Microsoft refuses to sign your kernel because it violates their patents?

Linus posted a NSFW rant about it a few days ago. The story mysteriously went off the HN front page and subsequent submissions of the story went [dead].


Rankings graph showing a deep dive.


Part of Linus' email:

>Guys, this is not a dick-sucking contest. If you want to parse PE binaries, go right ahead.

>If Red Hat wants to deep-throat Microsoft, that's your issue. That has nothing what-so-ever to do with the kernel I maintain. It's trivial for you guys to have a signing machine that parses the PE binary, verifies the signatures, and signs the resulting keys with your own key. You already wrote the code, for chissake, it's in that f*cking pull request.

HN dislikes anything that shows that real people have real emotions. Humour, anger and whatnot have no place here.

I think it is just a vocal minority of people who take offense to words like fuck. Most people don't care.

According to Paul Fussell's Class: A Guide Through the American Status System, aversion to profanity is a middle class thing. The upper class[1] do not use euphemisms for profanity or obscenity. Fussell wrote that Jilly Cooper reported "I once overheard my son regaling his friends: 'Mummy says pardon is a much worse word than fuck.'"

I doubt that many members of the upper class (see Fussell's book for a definition of upper class, it is roughly the tastes of "old money" but not dependent upon actual wealth) read Hacker News. It is likely that those who do not object to obscenities such as the word "fuck" are more socially liberal freethinkers who dislike formality. Those who do object are likely to be members of the middle class who believe (foolishly) that in censoring profanities and vulgarities, they are emulating the upper class.

[1] http://www.amazon.com/Class-Through-American-Status-System/d...

Profanity is hardly the only thing. HN, or a subset of it's users, basically expect everyone to act like humourless, passionless robots.

It's b/c 99% of that stuff is noise not signal, and degrades the information quality here. There are plenty of places on the net to get your fix of humour and endelessly repeated memes, we don't need it here too.

HN dislikes everything, just like the rest of the internet.

Every day someone comments saying that HN is biased against their team (see your sibiling “MS astroturfers” comment), and it’s always a different team, often opposites.

Yes, it’s annoying.

>Humour, anger and whatnot have no place here.

For certain, information-sparse, emotionally invested and biased definitions of 'humour, anger, and whatnot'.

I think that its just the common problem that people who are angered by something are more likely to respond than people who like it.

Is that a problem? There are plenty of other sites filled with cat memes and incoherent ranting for those that seek that.

MS astroturfers? (they've pretty much ruined /. by now, wouldn't be surprised if they took control of HN too)

I don't think flagging is enough to take a post from #2 to ~#200 in less than five minutes.

My guess is the voting ring detector got triggered or it was mod action. The subsequent submissions of the same story from other outlets going dead suggests that it was mod action.

Physical access is god access. Admin/root is god access.

Guard them both with your life.

I fail to see how handing over control of your boot to some 3rd party who clearly doesn't have the same interests that you do is anything but a horrible idea.

Just physically secure your boxes(or VDI them) and use permissions and ACLs to do what they were designed to do[control and delegate authority].

A good first step for Microsoft, if it cares so much about security, is to stop making its users automagically admin for fogging a mirror, during new PC setup.

> handing over control of your boot to some 3rd party...a horrible idea

It's actually a good idea if you're the party who's getting authority over the world's computers handed over to it.

> use permissions and ACL

I still have no idea how these work in the Windows world [1]. There's nowhere obvious in the UI or the "dir" command that shows you what the ownership and permission is [2], unlike Linux's ls -al.

My one experience with Windows permissions is, in the early '00s, I put an NTFS partition on an external drive because I wanted to put >4GB files on it. I copied them and got a bunch of permissions errors opening them on another computer. My impression of Windows access controls from this: They're invisible things the OS attaches to your files which will potentially make them unreadable later.

[1] I understand there's something called ACL's in Linux too, but I never use them.

[2] I don't have much experience with multi-user Windows systems, and Linux has been my main OS for 3-4 years so I don't have as much experience with post-XP OS's.

Solution: UEFI should not exist. Period.

We don't need to argue over UEFI or anything about it. We need to get rid of it, simple as that.

If Intel goes through with this, we need an antitrust case against them and we need Intel broken like Ma Bell.

UEFI must not exist, period.

ZaReason spoke out on this issue at FOSDEM (direct link to webm file):


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact