Linus Bites RedHat

On LKML (Linux Kernel Mailing List), RedHat developer David Howells provoked Linus with a proposal to get the Linux kernel to support EFI signed 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. The key can then be passed to the kernel by passing the signed binary”
see LKML: David Howells: [GIT PULL] Load keys from signed PE binaries.

Linus, of course, objected to making Linux depend on M$…
“Not without a lot more discussion first.

Quite frankly, this is f*cking moronic. The whole thing seems to be designed around stupid interfaces, for completely moronic reasons. Why should we do this?

I already dislike our existing X.509 parser. And this makes the idiotic complicated interfaces, and now it goes up to 11.


For greater emphasis, he continued the exchange with,
“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.

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

His last word?
“On Thu, Feb 21, 2013 at 9:49 AM, Matthew Garrett wrote:

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.

Quite frankly, I doubt that anybody will ever care, plus getting me to care about some vendor that ships external binary-only modules is going to be hard as hell.

Plus quite frankly, signing random kernel vendor modules (indirectly) with a MS key is f*cking stupid to begin with.

In other words, I really don’t see why we should bend over backwards, when there really is no reason to. It’s adding stupid code to the kernel only to encourage stupidities in other people.

Seriously, if somebody wants to make a binary module for Fedora 18 or whatever, they should go to Red Hat and ask whether RH is willing to sign their key. And the whole “no, we only think it makes sense to trust MS keys” argument is so f*cking stupid that if somebody really brings that up, I can only throw my hands up and say “whatever”.

In other words, none of this makes me think that we should do stupid things just to perpetuate the stupidity. And I don’t believe in the argument to begin with.

Besides, let’s face it, Red Hat is going to sign the official nVidia and AMD binary modules anyway. Don’t even bother to pretend anything else.

Peter Jones replied with
“I just want to make sure this doesn’t go unresponded to – Red Hat will not sign kernel modules built by an outside source. We’re simply not going to sign these kernel modules. That’s one of the big reasons we want a setup where they can sign their own modules in the first place.”

It’s great that Linus does not support the idea of making M$ the keeper of the keys. We’ve had enough of that in IT for decades. Free Software needs to remain free of M$ and anyone else who wishes to lock out competition. Linus is not a great lover of FLOSS. His views are based on practicality. It’s stupid to lock Linux into M$. Does RedHat really believe it’s a great thing if millions of GNU/Linux boxes quit booting if M$ revokes a key via firmware upgrade etc.? Do they really think “secure boot” is about security of the world’s IT rather than perpetuation of M$’s monopoly on legacy x86 stuff? Using the damned keys to induce the world to take another step on the Wintel treadmill is just too tempting a fruit to trust M$ to leave it alone.

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology and tagged , . Bookmark the permalink.

11 Responses to Linus Bites RedHat

  1. ram says:

    I think the market will sort this one out. Microsoft UEFI boxes, laptops, and tablets ARE NOT selling. Open platforms designed for Linux such as Intel’s NUC boxes, Shuttle’s compact and power efficient boxes, Google’s Chrome laptops, and Android tablets ARE selling.

    Soon the Linux game consoles will appear as well as low cost consumer Linux based home entertainment centers. The Microsoft 8 items on some retailers shelves will be scrap and waste landfill space as they are difficult to even recycle.

  2. oiaohm says:

    Dr Loser Linux foundation 1 certificate required then from there build all the tools to remove the Microsoft keys from the system. The 1 loader also allows you to load a KEK into the MOK without needing the platform key. So we don’t need to pay Microsoft more than once.

    The Linux foundation is deterred to be able to strip MS certificate out of the UEFI boot system. Problem is once that is done the hardware is bricked from booting Microsoft. Unless of course there is some universal way of restoring the keys.

    Linux distributions will be just as negatively effected by this as Microsoft is.

    The one behind EFI if you watched HP presentication on UEFI at Australian Linux Conference.

    They are becoming very aware the Linux world want to OWN full control of the platform they are running on.

    Its now being talked about finding another signing authority other than Microsoft in the hope this will cool them off.

    Reality this is not going to work. nvram where all KEK has to be placed is limited size. This has become a very major problem.

    Each Linux distribution is likely to provide there own KEK option. There is not enough nvram to go round. We have already had samsung laptops brick due to exhausted nvram.

    Maybe the complete KEK idea has to be dropped. MOK that stores in the disc is self and uses hashes and sise to de term if it been tampered with is a more valid option.

    Also you have not watched this one. In the next few years we will get a second hardware chain. It might end up UEFI. But there is one thing you can be sure about a chromebook it will not contain Microsoft keys. So Microsoft need a plan like the Linux Foundation is making to be able to change a platforms key set.

    The reality you are a under informed idiot Dr Loser on this topic. Everyone is screwed by UEFI. Anyone who does not think they are. Are kidding themselves.

    Nice bit about UEFI is remove the wrong signing key it bricks.

    Want to cripple your favourite OS by denying it access to hundreds of millions of OEM desktops and laptops?
    This is why you are a idiot. Linux Foundation for the Linux world is designing the tools to be able to high jack the UEFI loading so Microsoft OS’s cannot be installed back on the hardware without using the Linux Foundation tools.

    Microsoft is trying to refuse signing these tools but anti-trust case will happen if they do block them. Yes check for signiture of the Linux foundation keytool does not help you. We can built new one and pad it so signature fails. Linux foundation bootloader will load what ever it can checksum.

    Dr Loser this is the problem with building a weapon of any form. The other side can get the same weapon and use it against you.

    Safest and sanest certificate solution is what is in chromebooks. The certificate is stored in memory with read only switch. Linux users can get the instructions to change that to read write and place there own key. Secure solid and a true pain in ass. If MS wants to boot on chromebook hardware they are looking at the same process.

    Remember this Microsoft might be dominate today. This may not remain so.

    Dr Loser basically UEFI is failing in many key places. Design may need some minor alterations like moving KEK out of nvram for OS’s. So only driver keys in nvram. The Linux Foundation loader that hooks in can do this. Yes KEK so far up the boot process then switch over to the MOK in the partition from there on. Fixes the out of nvram problem. Drivers for hardware parts you know how many KEK keys you need. Problem is how many KEK’s for OS’s do you need.

    Unknown number. Trying to force one just cases the Linux guys to want to cease control of the complete lot.

  3. Dr Loser says:

    It doesn’t matter whether Linus is completely right or not.

    You can go the Pogson way (and why not?) and jerry-rig up a thin client solution on ARM using, say, a Samsung tablet. In which case you won’t be bothered by “Secure Boot.”

    Or you can go the bog-standard way and use a laptop or a desktop (running Linux if you so desire). This end of the hardware chain will come with non-negotiable UEFI/Secure Boot in the next few years, and you’re gonna need a certificate whether you like it or not.

    For those of us not all wrapped up in the Four Freedoms, this is actually a highly amusing spat over nothing: it’s just the next level of firmware, is all. Want to cripple your favourite OS by denying it access to hundreds of millions of OEM desktops and laptops?

    Go ahead! Be our guest! It’s pretty much crippled already, so I don’t suppose a lack of Secure Boot support will make much difference to the average consumer.

  4. ram says:

    Linus is completely right about this one!

  5. oiaohm says:

    Der Balrog Of course you miss that Intel is going to provide the start up firmware to there chips to the open public. Yes closed source.

    You did not watch the google video from LCA covering chromebook future did you.
    This bit is particularly interesting.

    Notice it clearly states Open Source Firmware solutions. What is required to strip efi out of bios and replace with something else is coming.

    Also notice the Google guys are not happy with the blocks they cannot see the source code to particularly when they are in areas that could possibly breach the security of the platform.

    The Linux world is not bending. Resistance from the Linux world is quite hard.

    Besides in this case with the EFI what was done here is wrong. Remember when the start of the Linux kernel loads direct EFI you are still in Firmmode so you can do a query to running firmware modules. So there loader could provide a generic function in EFI that returns what keys to use. Yes its possible for the Linux kernel to import into itself all the keys in the KEK of EFI and the open source MOK without knowing anything about PE format.

    As Linus said if they want to process PE files that can be done in userspace. Everything extra you do in kernel space can be a security risk.

    Der Balrog the breaking down of the closed source secret mix firmware started before EFI started. EFI is like the last attempt for parties to keep areas secret in the boot process.

  6. lpbbear says:

    “This Nazi complex of yours needs serious therapy.”

    Der Ballscrog says: “Is it safe?”

  7. Der Balrog says:

    This Nazi complex of yours needs serious therapy.

  8. lpbbear says:

    “That’s a really bad imitation.”

    Yep, I have to admit I can’t even come close to imitating a Microsoftie. You have it down. You are the master(race).

  9. Der Balrog says:

    That’s a really bad imitation. Work on it. Here’s someone to teach you.

  10. lpbbear says:

    “Secure Boot will become a reality for Linux. And you will bend over.”

    You vill ALL bend over. The vorld vill bow at meine feet. Alles untermensch vill bend to meine vill! (rant rave drool slobber)

    GFY wackjob

  11. Der Balrog says:

    Secure Boot will become a reality for Linux. And you will bend over.

Leave a Reply