Share this story

The Linux kernel development process may welcome all those who love open source software and have the right coding chops, but one man remains the ultimate authority on what does and doesn't go into Linux—and he isn't afraid to let everyone know it.

The rants of Linux creator Linus Torvalds often become public through the Linux Kernel Mailing List archive. That's the open source way, and it gives us a glimpse into the thinking of the people behind one of the world's most widely used technologies.

The latest example comes from an argument between Torvalds and other Linux developers over whether the Linux kernel should include code that makes it easier to boot Linux on Windows PCs. This goes back to Microsoft requiring that PCs designed to run Windows 8 use UEFI firmware with the Secure Boot feature enabled. This has complicated the process of booting Linux on PCs that shipped with Windows 8, but it hasn't prevented people from doing so. There are workarounds, but some people are looking for a solution in the Linux kernel itself.

Last Thursday, Red Hat developer David Howells posed a request to Torvalds, which reads in part:

Hi Linus,

Can you pull this patchset please?

It provides a facility by which keys can be added dynamically to a kernel that is running in secure-boot mode. To permit a key to be loaded under such a condition, we require that the new key be signed by a key that we already have (and trust)—where keys that we "already have" could include those embedded in the kernel, those in the UEFI database and those in cryptographic hardware.

Now, "keyctl add" will already handle X.509 certificates that are so signed, but Microsoft's signing service will only sign runnable EFI PE binaries.

We could require that the user reboot into the BIOS, add the key, and then switch back, but under some circumstances we want to be able to do this whilst the kernel is running.

The way we have come up with to get around this is to embed an X.509 certificate containing the key in a section called ".keylist" in an EFI PE binary and then get the binary signed by Microsoft.

Warning: Graphic language ahead

Torvalds replied that the idea was "f*cking moronic." Ex-Red Hat and current Nebula developer Matthew Garrett noted in response that "There's only one signing authority, and they only sign PE binaries," referring to Microsoft signing Extensible Firmware Interface Portable Executable binaries.

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 chrissake, it's in that f*cking pull request.

Why should *I* care? Why should the kernel care about some idiotic "we only sign PE binaries" stupidity? We support X.509, which is the standard for signing.

Do this in user land on a trusted machine. There is zero excuse for doing it in the kernel.

Linus

You might think that would end the conversation for good, but not quite. Howells pointed out problems in Torvalds' suggested approach, saying:

There's a problem with your idea.

(1) Microsoft's revocation certificates would be based on the hash of the PE binary, not the key.

(2) Re-signing would make the keys then dependent on our master key rather than directly on Microsoft's. Microsoft's revocation certificates[*] would then be useless.

(3) The only way Microsoft could then revoke the extra keys would be to revoke our *master* key.

[*] Assuming of course we add support for these.

David

Garrett noted that modifying the Linux kernel would be due to practicality more than anything. "Vendors want to ship keys that have been signed by a trusted party. Right now the only one that fits the bill is Microsoft, because apparently the only thing vendors love more than shitty firmware is following Microsoft specs," he wrote.

Greg Kroah-Hartman, maintainer of the Linux kernel's stable branch and the Linux driver project, put in his two cents, noting that various Linux distributions already allow Linux/Windows dual-boot scenarios due to "a UEFI bootloader/shim that Microsoft has signed." (That shim was created by Garrett.)

"I'm not saying that they are not nice things to have, personally, I want some of these things for my own machines just to make things more secure, but again, these are 'I want to have', not 'Someone else is saying Linux MUST have,'" Kroah-Hartman said.

Howells hasn't given up. In an e-mail yesterday, he noted that "Unless we get the administrator to add a key prior to Linux installation, Linux cannot be booted on a secure UEFI machine—unless the boot loader is signed by Microsoft's key." In the thread's latest e-mail from today, he responds to one of Kroah-Hartman's arguments.

The discussions illustrate how proposing changes to the Linux kernel can be controversial. We imagine these types of discussions happen all the time at software companies, but without becoming public like they do with Linux. What do the CEOs of major software companies say behind closed doors when they hate a proposal made by one of their underlings? We don't know, but when it happens with Linux, we do.

Torvalds isn't a CEO, but the final decision will likely come down to what he wants. Torvalds is an employee of the Linux Foundation, which allows him to remain independent while working full-time on maintaining Linux.

As the Foundation notes, "Torvalds remains the ultimate authority on what new code is incorporated into the standard Linux kernel."

Promoted Comments

...and RedHat has their own forked version of the kernel already, so why doesn't RedHat just include the relevant changes in their own kernel?

The whole point of Open Source is that you can make your own changes, right?

Yes, but each change you produce that upstream won't merge back means an extra point of deviation for you. For the sake of keeping your fork maintainable it is in your best interest to try and influence upstream to merge back your changes as well. Too much deviation can cause your fork to be impossible to merge back, and therefore be impossible to obtain further enhancements from the upstream without considerable effort.

So here is the situation, if you care more about what is happening than you do about the language people are using to debate it. The point of the patch boils down to enabling the Linux kernel to trust third-party binary drivers which have been signed by Microsoft. Yes you read that right; Linux drivers signed by Microsoft.

The purpose of UEFI Secure Boot is to make sure that only code that is signed by a trusted authority can be booted. Nearly all devices that support UEFI Secure Boot will ship with Microsoft's key/cert preloaded, and most will allow you to load other keys/certs, but not all. So to get around this Redhat and others wrote a small shim bootloader signed by Microsoft that will then run anything. This is nice for people who don't care about Secure Boot, and just want to be able to install Linux and have it work without messing with BIOS settings.

However, the vast majority of people who actually want to use Secure Boot in Linux would like for that code signing to extend all the way through the OS. That is UEFI verifies that the bootloader is trusted, the bootloader verifies that the OS is trusted, and the OS verifies that any drivers it loads are trusted. Linux supports this using standard x509 certificates, and all the major distributions sign the binary modules they distribute, so if you add their key as one that is trusted, everything is great.

Except for binary drivers. Redhat doesn't want to sign third-party binary drivers, but they want those drivers to work in this secure boot scenario. And they don't want the users to have to manually add the keys for NVIDIA, AMD, etc (which would the secure thing to do). Instead they had the idea to let third party driver developers submit their drivers to Microsoft to be signed, since the kernel will trust any certificate in UEFI by default anyway and the Microsoft certificate is on nearly all computers. (Edit: Microsoft is cool with this, and does it all the time; as far as they are concerned, they are just verifying the code comes from the specified developer, not that the code isn't malicious)

The complicating factor is that Microsoft will only sign executables in it's own PE format, so they want to enable support in the Linux kernel to load kernel modules that are wrapped in PE binary format. Linus thinks it is stupid to make a Microsoft certificate the root of your trust to begin with, and thinks it is even more stupid to add a bunch of code to parse the PE format into the kernel, just to enable this work-around.

UEFI secure boot is a useful tool. Like any useful tool, it can be used for good or for evil. The good is that it is harder to install rootkits or other tampered-with kernels. Only signed-trusted kernels will load. The bad is that it is harder to install your own custom-built kernels. If you want the advantage of additional security against rootkits and if your kernel of choice is available as signed-trusted, UEFI secure boot is awesome. Otherwise, UEFI secure boot is bad.

The design for UEFI secure boot allows for multiple signing authorities. So far, the only organization that has been able to get itself recognized and accepted as a signing authority by firmware vendors is Microsoft. Microsoft did not create this situation, but no other vendor has gone through the effort necessary to get itself accepted as a signing authority.

Microsoft is willing to sign 3rd-party code as long as it meets certain minimum requirements. The minimum requirements basically boil down to: 1) the software cannot be used to create a rootkit, and 2) the software is provided in a format that Microsoft's signing infrastructure can accept. The first requirement is absolutely crucial. To omit that requirement would bypass the whole point of UEFI secure boot. The second requirement is a bit more uncertain. I don't know for certain how the PE file format works with UEFI, but there is probably a way to make UEFI secure boot work without a PE file format (though it might require a revision to the UEFI standard -- I'm not sure about what formats UEFI supports).

Linus seems to be arguing that Linux shouldn't be in the business of using PE files for certificates because Linux already has a way to get certificates, and that the requirement for using PE files for certificates is arbitrary and temporary. I find this reasoning to be flawed -- there are lots of things in the Linux kernel that are present only to work around arbitrary or temporary limitations on firmware or hardware, and this would not be the least of them. I agree that it is annoying to have to use PE files to encapsulate UEFI certificates, but that's how UEFI works right now.

So it comes down to whether the Linux kernel will play nice with the existing UEFI secure boot implementation. Linux says he doesn't want it. He's well within his rights to say that and to not support UEFI secure boot. But to say that it keeps the kernel pure is quite silly -- the whole point of a kernel is to abstract the user from the impurities of the real world by abstracting away hardware details.

292 Reader Comments

It's a little disturbing to me that more of the discussion in this thread is about "Linus said bad words!" vs "Microsoft owns your bootloader".

Well, isn't that kind of what this article is about? Linus' attitude and method of leadership?

FWIW: I mostly agree with Linus on the issue and share your grave concerns about bootloader security/lockdown. It brings computers down the path of iPhones/iPads, possibly the thing I like least about iDevices.

UEFI secure boot is a useful tool. Like any useful tool, it can be used for good or for evil. The good is that it is harder to install rootkits or other tampered-with kernels. Only signed-trusted kernels will load. The bad is that it is harder to install your own custom-built kernels. If you want the advantage of additional security against rootkits and if your kernel of choice is available as signed-trusted, UEFI secure boot is awesome. Otherwise, UEFI secure boot is bad.

The design for UEFI secure boot allows for multiple signing authorities. So far, the only organization that has been able to get itself recognized and accepted as a signing authority by firmware vendors is Microsoft. Microsoft did not create this situation, but no other vendor has gone through the effort necessary to get itself accepted as a signing authority.

Microsoft is willing to sign 3rd-party code as long as it meets certain minimum requirements. The minimum requirements basically boil down to: 1) the software cannot be used to create a rootkit, and 2) the software is provided in a format that Microsoft's signing infrastructure can accept. The first requirement is absolutely crucial. To omit that requirement would bypass the whole point of UEFI secure boot. The second requirement is a bit more uncertain. I don't know for certain how the PE file format works with UEFI, but there is probably a way to make UEFI secure boot work without a PE file format (though it might require a revision to the UEFI standard -- I'm not sure about what formats UEFI supports).

Linus seems to be arguing that Linux shouldn't be in the business of using PE files for certificates because Linux already has a way to get certificates, and that the requirement for using PE files for certificates is arbitrary and temporary. I find this reasoning to be flawed -- there are lots of things in the Linux kernel that are present only to work around arbitrary or temporary limitations on firmware or hardware, and this would not be the least of them. I agree that it is annoying to have to use PE files to encapsulate UEFI certificates, but that's how UEFI works right now.

So it comes down to whether the Linux kernel will play nice with the existing UEFI secure boot implementation. Linux says he doesn't want it. He's well within his rights to say that and to not support UEFI secure boot. But to say that it keeps the kernel pure is quite silly -- the whole point of a kernel is to abstract the user from the impurities of the real world by abstracting away hardware details.

Edit:

I looked up a bit of additional context after posting this. The UEFI standard has very little to do with this situation, so UEFI's support for PE files is not an issue. In this particular scenario, UEFI only comes into play as a way for a kernel to find out what keys it should trust. The problems are that 1) only Microsoft's key is likely to show up in the list of trusted keys, and 2) Microsoft is currently only signing PE files.

Microsoft has never insisted on being the only point of trust, but nobody else has stepped forward. This isn't Microsoft's fault. If the Linux community wants a non-Microsoft UEFI-trusted certificate, it's going to have to do something about the problem (like set up a trusted entity and get that entity's keys into firmware) or quit whining.

The second problem is something for which Microsoft could possible be held to account. It would be nice if Microsoft were to sign non-PE files, but they currently don't support that. Perhaps there is a real technical issue, or perhaps they will add support for it in the future. In any case, this is the situation Linux has to deal with.

The solution being discussed is to add support for the Linux kernel to load drivers encapsulated in PE files. Linux doesn't want to support that. I haven't looked at the details, but if the patch is to make Linux load and run PE drivers, I would probably agree with Linus that this is a technically flawed solution. On the other hand, there are other solutions such as having the PE file be a simple wrapper around an embedded ELF driver, in which case it shouldn't be terribly bad to tell the kernel "validate the signature of the whole file as follows { ... } and then pretend that the first 4k of the file doesn't exist". That isn't pretty, but not really too bad, and seems like a reasonable workaround for a problem like this.

In any case, the Linux kernel is now at an impasse. Some people want secure Linux kernels and can't get it because Microsoft only signs PE files and Linus doesn't want to support PE files. It's unfortunate, but it's not entirely Microsoft's fault and not entirely Linus's fault. Maybe there is room for another creative solution that doesn't upset Linus quite so much, or maybe Microsoft will add support for signing ELF files. Or maybe those that want secure Linux kernels will live with an unofficial patch set for a while.

Some efi vendors requires that the efi boot loader must be signed by Microsoft (Why?).

For secure boot to work, the boot loader must be signed by a key that can be verified by the UEFI platform. Since everyone is including Microsoft's key by default, the bootloaders must be signed by Microsoft. Thus, anything following that must be signed by Microsoft (kernel, drivers.)

Quote:

Why is Microsoft supposed to be the only reliable vendor?

No implication is made. Microsoft is simply, by their own design, the de-facto signing authority for Secure Boot.

Theoretically. Only in a recent update was the ability for binaries to be signed by multiple authorities added. Adding signatures, as implemented in many common UEFI variants (AMI, for instance,) allows you to install different keys but only after removing what is already present.

Quote:

So far, the only organization that has been able to get itself recognized and accepted as a signing authority by firmware vendors is Microsoft. Microsoft did not create this situation, but no other vendor has gone through the effort necessary to get itself accepted as a signing authority.

Microsoft absolutely created this situation. They did back when they secured a monopoly in the PC space and when they architected secure boot via the TCG. OEM vendors aren't going to go around and get keys from every Linux distro out there, and OEM hardware vendors aren't going to have all of them sign their option roms.

Quote:

I don't know for certain how the PE file format works with UEFI

All UEFI applications and drivers are PE binaries.

Quote:

there is probably a way to make UEFI secure boot work without a PE file format (though it might require a revision to the UEFI standard -- I'm not sure about what formats UEFI supports).

UEFI only supports PE, and adopts many Microsoft conventions. Additionally, Microsoft is the only OS vendor at the promoter level, which puts their arguments above those of any Linux vendor.

But this isn't about UEFI loading the drivers. This is about the kernel loading proprietary modules.

Quote:

Linus seems to be arguing that Linux shouldn't be in the business of using PE files for certificates because Linux already has a way to get certificates, and that the requirement for using PE files for certificates is arbitrary and temporary.

And he's totally right. It's most definitely arbitrary. Microsoft could use the certificates directly but their entire signing process is Windows centric.

Quote:

I find this reasoning to be flawed -- there are lots of things in the Linux kernel that are present only to work around arbitrary or temporary limitations on firmware or hardware, and this would not be the least of them.

But nothing so utterly ridiculous as packing kernel modules in PE binaries for the sole purpose of shuttling around an otherwise standard certificate.

Quote:

I agree that it is annoying to have to use PE files to encapsulate UEFI certificates, but that's how UEFI works right now.

And it works that way because of Microsoft.

Quote:

So it comes down to whether the Linux kernel will play nice with the existing UEFI secure boot implementation. Linux says he doesn't want it. He's well within his rights to say that and to not support UEFI secure boot. But to say that it keeps the kernel pure is quite silly -- the whole point of a kernel is to abstract the user from the impurities of the real world by abstracting away hardware details.

No, the point is to keep Linux from having a hard dependency on Microsoft, who are known to abuse their position.

Tone trolling is unnecessary and whether someone sounds like a dick is completely irrelevant to whether someone is correct or not.

Whether someone is correct or not is completely irrelevant to me if I have absolutely no desire to interact with them or listen to them. Being an abusive prick is the easiest way to make me not want to deal with you.

Linus is in the enviable position of getting to act like a completely dick and still get taken seriously. Why? Because he built something really useful and is in (near) complete control of it. From most accounts, this is exactly what allowed Jobs to do the same.

However, just because you can act this way, doesn't mean it is the most reasonable, most effective or most ethical thing to do. To me, he is abusing his power and fanning flames when it is completely unnecessary. He couldn't have made the exact same points with a modicum of respect? (if not towards the ideas then at the very least towards the hard working, intelligent people suggesting them?)

The response from folks here tells me that either, a) people are blind to bad behavior when they like the product (see: Steve Jobs), or b) programmers and techies really are as bad with people skills as stereotyped. This is a set of reasonable arguments wrapped in petulance and abuse of position, nothing more.

Whether offending some people (such as yourself) is a good idea or whether this speech would appeal to a mass audience is also irrelevant to my point. Using profanity and volatile speech (in this case, and certainly with exception) is venting, not an ad-hom when accompanied by other descriptors and explanation.

So the take away from this is that Torvalds is a petulant child who enjoys shouting and screaming and bullying anyone who doesn't immediately agree with him.

To Rauha, this is most definitely NOT good management technique; it is the actions of a bully writ large.

"“I'm a bastard. I have absolutely no clue why people can ever think otherwise. Yet they do. People think I'm a nice guy, and the fact is that I'm a scheming, conniving bastard who doesn't care for any hurt feelings or lost hours of work if it just results in what I consider to be a better system. And I'm not just saying that. I'm really not a very nice person. I can say "I don't care" with a straight face, and really mean it. “ - Linus Torvalds

Linus makes no bones about the way he is. Deal with it or get out. This PC bull*hit of having to make everyone 'feel nice' is idiotic and causes massive inefficiencies as you try to massage everyone's feelings. I'm not saying you have to be more of a d*ck than necessary, but sometimes you have to be a d*ck to get things done. Too bad if people don't like the fact you call them out as being idiots when they ARE acting IDIOTIC...

So, Basically Linux says that they won't change, and as a result won't try to increase their commerciality. Good, he's just leaving a space for other OS vendors to come in and take their place. fucking idiot.

So, Basically Linux says that they won't change, and as a result won't try to increase their commerciality. Good, he's just leaving a space for other OS vendors to come in and take their place. fucking idiot.

The only "fucking idiot" here is you. He's saying that "fixing" the problem of secure boot signatures is best solved by dealing with Microsoft's idiotic "we only sign PE binaries" and not "we should enable drivers to be packed in PE binaries that the kernel parses and loads."

It's a stupid external dependency to fix a stupid problem caused by one company with way too much power.

The design for UEFI secure boot allows for multiple signing authorities. So far, the only organization that has been able to get itself recognized and accepted as a signing authority by firmware vendors is Microsoft. Microsoft did not create this situation, but no other vendor has gone through the effort necessary to get itself accepted as a signing authority.

I was under the impression that Microsoft did create this situation.

Windows 8 certification for hardware requires SecureBoot. And it requires that Microsoft certificates are in the firmware (obviously, as it's for Windows).

And all of this is demonstrating that while SecureBoot is fundamentally not a bad idea the current implementation is borderline useless. If you start signing someone else's binary then you are very close to opening up the entire thing to nasty attacks.

The only thing worse than a boot virus (which it was a really long time since at least I had) is a signed boot virus.

Linus created Linux. Except, in the case where a CEO of a company actually created its product, he or she would not be participating in a decision on this kind of issue. Typically, the decision on this kind of issue would be driven by marketing requirements. The manager with profit and loss responsibility for the particular product would chose someone to drive the process of resolving it. That person would gather some kind of workgroup of people with technical knowledge related to the issue. Based on their input, the workgroup leader would report back with a reccommendation or possibly a set of choices and the issues with them. The product manager would make a decision. Other people's opinions would not be solicited and not be welcomed if offered.

Not specifically related to this discussion, but if anyone ever wondered how Microsoft could have spent all that money to build and launch the Kin phone when the project was obviously destined for utter failure, the sentence I bolded is exactly the way that Microsoft treated the opinions of the engineers from Danger assigned to work on it (I was one of them, until I quit in disgust/burnout halfway through). Actually, Microsoft pretended to solicit our opinions and then ignored them, which is somehow even worse.

So, Basically Linux says that they won't change, and as a result won't try to increase their commerciality. Good, he's just leaving a space for other OS vendors to come in and take their place. fucking idiot.

Would you be interested in Microsoft authorizing your samsung smartphone to upgrade or even boot android? seriously?

Android is not a desktop OS. It's a Phone/Tablet OS. Why are you guys intentionally not getting what mainstream actually means in this context?

That's a pretty arbitrary difference. The mainstream does not care what processor they use to get to Facebook or play Angry Birds.

How many PC's were sold last year?

How many smartphones/tablets?

Whatever the majority of people use to do their computing is, by definition, mainstream. Part of the reason Linux is eating Windows lunch is that it is based an open system where it's hard for people to raise barriers to what is best to further their own goals. Linus may be an asshole but he has done an exceptional job at creating an environment that works.

Finally FWIW Android runs on Linux. Linux is the kernel, not an OS even though it's used that way in a lot of causal conversation. You put other stuff on top but it's running the Linux kernel just like Red Hat or Ubuntu does. The common code is the part that is being argued over.

Requiring support for x509 to boot an OS is fine. Requiring it in a format controlled by a single vendor is not.

On the balance I will take Linus. Secure boot is a power play which takes control of our computers and gives it to Microsoft. It doesn't do it all at once but there is a lot more camel ready to follow its nose in to our tent. Living with it should be the absolute last ditch tactic to be considered when everything else has failed. Having Microsoft keys at the root of our security is madness. Look at smart phones, tablets and Windows 8, all locked down against their owners and users. This is the Apple, Microsoft and phone company plan for the future where all us good sheep spend our money buying machines which serve corporate masters over us.

Security is to tech what "think of the children" is to law where all sense of proportion vanishes. This is why secure boot is so dangerous and so brilliant as Microsoft's ploy to make Linux and other free operating systems impractical on commodity computers.

People are so afraid of malicious software they forget there is more to security than hacking. I have many times rescued valuable data from fouled up computers by booting removable media. I have never had a machine compromised in a way secure boot would have helped with. Having secure boot would have greatly complicated my data rescue efforts but never done a thing for me against hackers. If we had it from the beginning of personal computing it would have greatly reduced my security and I expect the same for the future.

Sure, in your culture, swearing might be disrespectful. I'm guessing middle class white american? That's not meant as a slant either, just understand, that not everyone feels the same way. I quite often swear at work, and I'm Canadian, and I work in software development.

Whether someone is correct or not is completely irrelevant to me if I have absolutely no desire to interact with them or listen to them. Being an abusive prick is the easiest way to make me not want to deal with you.

...

The response from folks here tells me that either, a) people are blind to bad behavior when they like the product (see: Steve Jobs), or b) programmers and techies really are as bad with people skills as stereotyped. This is a set of reasonable arguments wrapped in petulance and abuse of position, nothing more.

Everyone's a "prick" sometimes. If you refuse to work with anyone who acts like a jerk every once in a while you're never going to get anything done.

Your response comes off as mature, but it's not --not genuinely so.

Real maturity is getting over own judgmental attitude and getting things done. Ya, you're going to have to work with people you don't like. Well they probably don't like you either. It happens.

Get over your own ego and care about the product, or the cause, or the mission. Care about it more than your own ego.

After reading the article and a substantial number of the comments, one question and one comment occurred to me:

This issue only exists when one wants to dual-boot Linux and Windows, and Linux doesn't have enough presence on the desktop to warrant all this controversy. Does anybody really dual-boot servers in production environments?

And my comment is: Since people generally buy servers without the OS and install it themselves, it seems that if you were in the tiny minority who wanted to dual-boot your server, you would account for this in your initial setup, before installing the OSs.

There appears to be two arguments being made here, and both are validated:

1) Secure boot on desktop style systems (including servers here)

Yes, agreed that the single point of authority on certificates should NOT be made by Microsoft. This is one discussion for another thread because there appears to be confusion about whom should own authority on booting systems.

This conversation is leading the thread, when it should really be about the other conversation (and probably the confusion among most posters) :

2) allowing the linux kernel directly to permit a PE cert for one purpose (secure desktop booting) to also allow that same kernel to operate on devices in which such a purpose was never intended. This includes smartphones, tablets, basically anything that operates Linux.

A lot of vision in this thread on how far-reaching such a change to the Linux kernel would be is lost in a vaccum argument after another; such a change would affect every device running the Linux kernel, from Android phones and iPhones to tablets and desktops.

Crude as it may be, Linus is correct in that Microsoft should not have the authority to sign such certs built directly into the kernel as such a change is VERY far reaching. Especially when you consider the far and wide repercussions - Microsoft would then have final signing authority on all devices with kernel 3.x regardless of device or hardware.

That's the way I see it, And sorry for misspellings, typingthis from my phone.

Linux doesn't have enough presence on the desktop to warrant all this controversy.

And the presence of a barrier to easily trying out another desktop OS alongside Windows will help to perpetuate that situation.

I disagree that MS intends this as a barrier. Win7 and later (and maybe Vista) support boot from VHD, and Windows 8 Client Hyper-V supports installing Linux in a VM. Microsoft provides native Hyper-V support for SUSE, and free downloadable Integration Services for others including Ubuntu and Red Hat. I'm not sure how much more hospitable they could be to this situation.

I'm a Linux fan and user & I like Linus for the most part. My problem starts when an idea is shot over his way and instead of explaining his take on it, he cuts off the person's head and shlts down their neck. Makes me wonder how tall he is or whether he has insecurity about his penis size. He's overly aggressive and has let his ego get out of control.

I'm glad he's got his claws on the linux kernel but he could do with a crowbar to the face every now & again.

May I ask on what basis? This is pretty much exactly how he's been since day one, this isn't anything new. Feel free to peruse the LKML archives if you don't believe me.

Linus has been clear that he doesn't give a crap about what we want to do with this code. If we don't like it, fork it and do whatever you like. Nobody is stopping you or me or anyone from doing this. The code is all there. Nothing makes Linus' version "special" and thanks to git, it really just comes down to which git repo we all choose to pull from that matters.

Linus clearly never intends to use Secureboot himself and allowing server makers to force secureboot definitely is a bad idea. I agree with Linus - but what do I know?

Further, I never intend to use Secureless Boot. I will avoid machines that force it and take my money elsewhere.

This is another attempt at MS to force a proprietary standard. It cannot be allowed to stand.Many thanks to Linus for having the guts to say what many people think and having the position where his comments carry just a little weight.

The design for UEFI secure boot allows for multiple signing authorities. So far, the only organization that has been able to get itself recognized and accepted as a signing authority by firmware vendors is Microsoft. Microsoft did not create this situation, but no other vendor has gone through the effort necessary to get itself accepted as a signing authority.

I think this is the part that seems to be going over people's heads. Microsoft went to the trouble to get recognized as a signing authority. It doesn't sound like they kicked the ladder out behind them. What's to stop Torvald's or better yet someone more open minded like Mark Shuttleworth from setting up an alternative, Linux friendly version of the same standard, if they don't want to use MS's offering? Is there some legal or financial reason they can't? What did this process entail that only MS decided it was worth it?

I guess I just don't see the paranoia. This isn't the Microsoft of the 1990's anymore. Sure, they're not cuddly, but in case Torvald's didn't get the memo, Apple is the new 900lb gorilla now. Save your rage for where it's needed.

I disagree that MS intends this as a barrier. Win7 and later (and maybe Vista) support boot from VHD, and Windows 8 Client Hyper-V supports installing Linux in a VM. Microsoft provides native Hyper-V support for SUSE, and free downloadable Integration Services for others including Ubuntu and Red Hat. I'm not sure how much more hospitable they could be to this situation.

Intention or not, I do not want ANY Microsoft code or proprietary standards on my machines. I've done lots and lots of virtualization over the last 15 yrs, only tried the MS version once and quickly switched. No interest in using it again.

Anything that gets in the way of hardware booting any OS that I choose, is a problem. Period.

Why are people suggesting this is political move? Linus has said that he values function over freedom, he's not Richard Stallman. Linus sees this as it is, a malevolent move by MS for vendor lock in and he won't play by their rules and rightfully so, all this should be done on a standardized basis and not needing to use one particular binary format over the other, I'm sure Ballmer would object vehemently if UEFI said they would adopt ELF as their binary of choice for signing keys so I believe Linus should too. Yes he's an asshole, he'll freely admit that himself but he's a correct asshole.

I disagree that MS intends this as a barrier. Win7 and later (and maybe Vista) support boot from VHD, and Windows 8 Client Hyper-V supports installing Linux in a VM. Microsoft provides native Hyper-V support for SUSE, and free downloadable Integration Services for others including Ubuntu and Red Hat. I'm not sure how much more hospitable they could be to this situation.

Intention or not, I do not want ANY Microsoft code or proprietary standards on my machines. I've done lots and lots of virtualization over the last 15 yrs, only tried the MS version once and quickly switched. No interest in using it again.

Anything that gets in the way of hardware booting any OS that I choose, is a problem. Period.

You Linux guys have got sand in your shorts over nothing. Microsoft REQUIRES the ability to turn SecureBoot off in BIOS for any machine with Windows pre-installed, so those are the only machines where the topic even applies. So if you don't want Windows, and you paid for it pre-installed on a PC or server, you'll have to take the 15 seconds to boot into the BIOS and disable it. If you bought pre-installed Linux or no OS, you won't even encounter this at all. It's purely a Windows thing and applies only to OEM machines with Windows pre-installed.

My comment was in response to someone who implied that MS is trying to prevent dual booting to make it hard for people to evaluate Linux. You responded to a point that was irrelevant to the original thread.

Why are people suggesting this is political move? Linus has said that he values function over freedom, he's not Richard Stallman. Linus sees this as it is, a malevolent move by MS for vendor lock in and he won't play by their rules and rightfully so, all this should be done on a standardized basis and not needing to use one particular binary format over the other, I'm sure Ballmer would object vehemently if UEFI said they would adopt ELF as their binary of choice for signing keys so I believe Linus should too. Yes he's an asshole, he'll freely admit that himself but he's a correct asshole.

Well, he'd be correct if Microsoft had done something to prevent anyone else from coming up with alternative solutions. They invited the community to use theirs if they want best results for right now. That wasn't an edict, an obligation, or a threat. There's nothing stopping the community from rolling their own certification, getting it approved and just competing with MS's standard, just like they've done countless times on several other projects.

EFI is a fact, and one that the Linux community simply has to incorporate. That doesn't mean kowtowing to MS. It's just another bit of hardware the community has to work to support. I'm just not seeing the coercion here, just a bunch of (IMO) knee jerk vitrol against 1990's Microsoft, which is unfortunate when there are other companies far more worthy of your paranoia these days.

I disagree that MS intends this as a barrier. Win7 and later (and maybe Vista) support boot from VHD, and Windows 8 Client Hyper-V supports installing Linux in a VM. Microsoft provides native Hyper-V support for SUSE, and free downloadable Integration Services for others including Ubuntu and Red Hat. I'm not sure how much more hospitable they could be to this situation.

Intention or not, I do not want ANY Microsoft code or proprietary standards on my machines. I've done lots and lots of virtualization over the last 15 yrs, only tried the MS version once and quickly switched. No interest in using it again.

Anything that gets in the way of hardware booting any OS that I choose, is a problem. Period.

You Linux guys have got sand in your shorts over nothing. Microsoft REQUIRES the ability to turn SecureBoot off in BIOS for any machine with Windows pre-installed, so those are the only machines where the topic even applies. So if you don't want Windows, and you paid for it pre-installed on a PC or server, you'll have to take the 15 seconds to boot into the BIOS and disable it. If you bought pre-installed Linux or no OS, you won't even encounter this at all. It's purely a Windows thing and applies only to OEM machines with Windows pre-installed.

My comment was in response to someone who implied that MS is trying to prevent dual booting to make it hard for people to evaluate Linux. You responded to a point that was irrelevant to the original thread.

Yeah, I'm not even sure I'd consider Microsoft and Linux to be competitors anymore, honestly, which doubles my confusion. Most people I know (at least the ones who don't view software as religion), use a variety of different products: A Macbook Pro, dual booted to Windows, with a Linux VM, and a smattering of software for nearly any vendor imaginable.

Why are people suggesting this is political move? Linus has said that he values function over freedom, he's not Richard Stallman. Linus sees this as it is, a malevolent move by MS for vendor lock in and he won't play by their rules and rightfully so, all this should be done on a standardized basis and not needing to use one particular binary format over the other, I'm sure Ballmer would object vehemently if UEFI said they would adopt ELF as their binary of choice for signing keys so I believe Linus should too. Yes he's an asshole, he'll freely admit that himself but he's a correct asshole.

Well, he'd be correct if Microsoft had done something to prevent anyone else from coming up with alternative solutions. They invited the community to use theirs if they want best results for right now. That wasn't an edict, an obligation, or a threat. There's nothing stopping the community from rolling their own certification, getting it approved and just competing with MS's standard, just like they've done countless times on several other projects.

EFI is a fact, and one that the Linux community simply has to incorporate. That doesn't mean kowtowing to MS. It's just another bit of hardware the community has to work to support. I'm just not seeing the coercion here, just a bunch of (IMO) knee jerk vitrol against 1990's Microsoft, which is unfortunate when there are other companies far more worthy of your paranoia these days.

While what you said is fact you neglected one point, the fact that MS forced PE binaries on UEFI. Linux DOES not and SHOULD not load PE binaries, there should be some standard way to load a certificate which abstracts away from any OS specific binary type. MS may not have forced these vendors overtly but they knew what they were doing in trying to lock the UEFI to MS. I'm sure the Linux foundation can easily become a signing authority, but what's the point. MS holds all the cards in the world of consumer desktops and no manufacturer would use their certs and secondly they have to implement a way of reading PE binaries that shouldn't be their whatsoever. No company with a vested interest in. consumer desktops should hold such sway as to what binary format signed keys are in. Like Linus said, and a I paraphrase the way we do it now is better.

Yeah, I'm not even sure I'd consider Microsoft and Linux to be competitors anymore, honestly, which doubles my confusion. Most people I know (at least the ones who don't view software as religion), use a variety of different products: A Macbook Pro, dual booted to Windows, with a Linux VM, and a smattering of software for nearly any vendor imaginable.

But maybe I'm just an idealist.

ITYM pragmatist. Getting upset about this stuff feels very "mom's basement in the 90s" to me, as in that's what I was doing at that place and point in time. Before working full-time at MSFT I was a self-avowed hater of all things "Micro$loth" and detractor of the "evil empire."

Software as religion is a fine hobby I guess, but the hobbyists also need to understand it is not universal.

Why are people suggesting this is political move? Linus has said that he values function over freedom, he's not Richard Stallman. Linus sees this as it is, a malevolent move by MS for vendor lock in and he won't play by their rules and rightfully so, all this should be done on a standardized basis and not needing to use one particular binary format over the other, I'm sure Ballmer would object vehemently if UEFI said they would adopt ELF as their binary of choice for signing keys so I believe Linus should too. Yes he's an asshole, he'll freely admit that himself but he's a correct asshole.

Well, he'd be correct if Microsoft had done something to prevent anyone else from coming up with alternative solutions. They invited the community to use theirs if they want best results for right now. That wasn't an edict, an obligation, or a threat. There's nothing stopping the community from rolling their own certification, getting it approved and just competing with MS's standard, just like they've done countless times on several other projects.

EFI is a fact, and one that the Linux community simply has to incorporate. That doesn't mean kowtowing to MS. It's just another bit of hardware the community has to work to support. I'm just not seeing the coercion here, just a bunch of (IMO) knee jerk vitrol against 1990's Microsoft, which is unfortunate when there are other companies far more worthy of your paranoia these days.

First off, this article isn't about the hardware, its about the kernel. Decisions on the kernel should not be made to please one specific company, especially Microsoft. Second, the only reason that Microsoft is able to push this through at all is leverage of their OS business and the fact that any company who doesn't comply will be out of business. The PC market has such razor thin margins that they can't simply say no to MIcrosoft. On the other hand, no other company has that leverage so they can just go pound salt. In the end we have a situation where Microsoft now controls the signing of all bootloaders that you would want to run in Secure Boot. One company should not have that power.