topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Sunday December 15, 2024, 5:37 am
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: Is RedHat willing to concede too much to Micorosoft? Linus Torvalds thinks so.  (Read 5346 times)

40hz

  • Supporting Member
  • Joined in 2007
  • **
  • Posts: 11,859
    • View Profile
    • Donate to Member
Those of us who follow the Linux kernal dev mailing list have had a 'fun' week following a heated and occasionally expletive laced 'discussion' that erupted when software engineer Dave Howell (who is also an employee of RedHat) proposed allowing Microsoft-signed binary keys to be inserted dynamically in the Linux kernal when running in secure boot mode. That would have been bad enough. But when Matt Garrett (creator of the UEFI shim we've all been reading about) chimed in in support of that request, that was the last straw. And something big enough to provoke a full scale explosion from none other than Linus Torvalds himself:

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.

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.

And it went on from there.

Some of the dust has settled a bit and Torvalds has clarified and expanded since then on what he sees as the core problem - and how Linux - as an OS - should go about dealing with it.

Rather than provide a pile of quotes and snippets, I was fortunately able to find a good write-up and summary courtesy of ZDNet's Steve Vaughan-Nichols. It gives a neat précis of where Linus Torvalds is coming from, and (by default since it's his baby) where the Linux kernal is going with this. Read it here.

Here's part of what Linus had to say:

On Mon, Feb 25, 2013 at 7:48 PM, Matthew Garrett <[email protected]> wrote:
>
> Our users want to be able to boot Linux. If Microsoft blacklist a
> distribution's bootloader, that user isn't going to be able to boot
> Linux any more. How does that benefit our users?

-----------------------------------------------------------------------------
Linus Torvalds responds to Matt Garrett's question above:

How does bringing up an unlikely and bogus scenario - and when people
call you on it, just double down on it - help users?

Stop the fear mongering already.

So here's what I would suggest, and it is based on REAL SECURITY and
on PUTTING THE USER FIRST instead of your continual "let's please
microsoft by doing idiotic crap" approach.

So instead of pleasing microsoft, try to see how we can add real security:
.
.
.
It really shouldn't be about Microsoft blessings, it should be about the *user* blessing kernel modules. Quite frankly, *you* are what the key-hating crazies were afraid of. You peddle the "control, not security" crap-ware. The whole "Microsoft owns your machine" is *exactly* the wrong way to use keys.


If you're the 'technical' sort of Linux user, be sure to check it out. 8) :Thmbsup:



Deozaan

  • Charter Member
  • Joined in 2006
  • ***
  • Points: 1
  • Posts: 9,778
    • View Profile
    • Read more about this member.
    • Donate to Member
I didn't really understand all of it, but it was an interested read. Thanks! :Thmbsup:

40hz

  • Supporting Member
  • Joined in 2007
  • **
  • Posts: 11,859
    • View Profile
    • Donate to Member
arrgh.jpg

@Deo- The Linux Action Show podcast had a recent segment on this which may help explain more of what it's all about - and why Linus reacted the way he did. Podcast page is here. The discussion starts around the 20 minute mark.

There's also a link to a Reddit that summarizes a little better what the issue is:

What he is arguing is that it's pointless and stupid for the Linux kernel developers to put a huge amount of rather nasty code into the kernel in order to accept the way Microsoft signs kernel driver binaries.

UEFI with secure boot allows both users and hardware makers to lock down the machine in different ways via the bootloader. The firmware (code embedded into the mainboard) can be made to only accept cryptographically signed bootloaders. (this signing allows them to know were the bootloader comes from).

The bootloaders can be made then to only accept signed kernels.

The signed kernels can be made to only accept signed kernel modules, which can include drivers for hardware.

So this patch is designed to make is so that the kernel can be made to accept Microsoft signed modules.

The way Microsoft has set things up is that they will only sign modules that conform to the format used by embedded Windows.

So the kernel, with these patches, will be able to take the windows-format, check it, convert it to a format the kernel can use and load it.

Linus contends this is stupid and pointless because the kernel already has proper support for signed kernel modules. If people want to use signed kernel modules they can use that and skip the whole Microsoft bullshit.

The counter argument is that there exists nobody but Microsoft that is willing to maintain a certificate authority (used to do the official signing) AND that Microsoft keys are already used by hardware. If you want to use the X.509 certification system (think: SSL certs) that the Linux kernel supports then you will first need to setup a organization to manage the certificates, get their public key (the portion that tests the signatures for correctness) embedded in the kernel so that people can use it. And even then if you want to be able to sign binaries in a way that is acceptable by UEFI right now you'd still have to go through Microsoft and then develop a way to convert the Microsoft signatures to x.509 signatures that the kernel knows and understands. This is going to be difficult to pull off.

Linus fundamentally believes that kernel signing already exists and if that can't be used by people because they want to ship proprietary kernel modules then that is their problem. They will have to maintain the code and the kernel versions to do that crap and that is not something he is will to do or force others in the kernel community to deal with the burden of maintaining all that stuff.

This is mostly a issue with embedded development. If you are smart and buy hardware that is open and allows you to manage the keys yourself then you can have the benefit of having cryptographically signed kernels and drivers for security, but without all the business of dealing with Microsoft. That is when that stuff gets made and used... this stuff isn't widespread yet.

Hope this clarifies things a bit. 8)



« Last Edit: March 03, 2013, 09:22 PM by 40hz »

Deozaan

  • Charter Member
  • Joined in 2006
  • ***
  • Points: 1
  • Posts: 9,778
    • View Profile
    • Read more about this member.
    • Donate to Member
It does. Thanks.  :Thmbsup:

zridling

  • Friend of the Site
  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 3,299
    • View Profile
    • Donate to Member
Thanks for the Reddit clarification, 40hz, that did help. I did see the part where "anyone with a credit card can bypass UEFI."

f0dder

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 9,153
  • [Well, THAT escalated quickly!]
    • View Profile
    • f0dder's place
    • Read more about this member.
    • Donate to Member
I did see the part where "anyone with a credit card can bypass UEFI."
Eh... what?
- carpe noctem