linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: David Howells <dhowells@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Vivek Goyal <vgoyal@redhat.com>,
	yannik@sembritzki.me, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Peter Anvin <hpa@zytor.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Dave Young <dyoung@redhat.com>, Baoquan He <bhe@redhat.com>,
	Justin Forbes <jforbes@redhat.com>,
	Peter Jones <pjones@redhat.com>,
	Matthew Garrett <mjg59@google.com>
Subject: Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot
Date: Thu, 16 Aug 2018 08:56:40 -0700	[thread overview]
Message-ID: <1534435000.3166.9.camel@HansenPartnership.com> (raw)
In-Reply-To: <30607.1534434597@warthog.procyon.org.uk>

On Thu, 2018-08-16 at 16:49 +0100, David Howells wrote:
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> > > The problem with that is that it means you can't load third party
> > > modules - such as the NVidia driver.  That's fine if you
> > > absolutely reject the right of people to produce third party
> > > drivers for the Linux kernel and absolutely require that they
> > > open and upstream their code if they want in.
> > 
> > So if you build your own kernel and want to load the nVidia module,
> > you have the key to sign it.
> 
> I think you have to assume that doing this is beyond most people.

As a step by step process, I agree.  However, I think we can automate
it to the point where you install a package and it says "insert your
yubikey" every time you upgrade the kernel

>   Further, as a distribution we would prefer people didn't raise bugs
> against kernels that we didn't build.

Mehmet's patches don't require building a new kernel.  They merely
require the added key be linked into the Red Hat built bzImage and then
the resulting blob be signed.  You can still identify that the original
bzImage is the Red Hat one.

> > If you're a distribution and want third party modules to be loaded
> > you can set up a third party signing process using a distro key ...
> > I don't see what the big problem is.
> 
> That's the problem is right there.  AIUI, we *don't* want to set up a
> third party signing process.  As I said, it potentially comes with
> lawyers attached.

Right so generate a business pressure to overcome the legal one.  To be
honest that's what I believe happened at Microsoft: I'm sure their
lawyers initially said "no way" to being a third party signing
authority until their executives laid out the business cost of being
blamed for the first boot virus after having refused to implement
ecosystem protection for legal reasons.

> > So your lawyers tell you if you sign a third party module for your
> > kernel then you could get blamed for the damage it causes?
> 
> There's more to it than that, but I feel I should discuss it with our
> legal dept. before airing it here.

Sure; if you want me to be involved in the conversation I can do it
under NDA or whatever they require.

James


  reply	other threads:[~2018-08-16 15:56 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-15 10:00 [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot Yannik Sembritzki
2018-08-15 16:54 ` Linus Torvalds
2018-08-15 17:27   ` Yannik Sembritzki
2018-08-15 17:37     ` Yannik Sembritzki
2018-08-15 17:42     ` Vivek Goyal
2018-08-15 18:44       ` Yannik Sembritzki
2018-08-15 18:58       ` Vivek Goyal
2018-08-15 19:06         ` Yannik Sembritzki
2018-08-15 19:49           ` Vivek Goyal
2018-08-15 20:47             ` Linus Torvalds
2018-08-15 20:53               ` James Bottomley
2018-08-15 21:08               ` Yannik Sembritzki
2018-08-15 21:13                 ` James Bottomley
2018-08-15 21:31                   ` Yannik Sembritzki
2018-08-15 21:40                     ` James Bottomley
2018-08-15 21:50                       ` Yannik Sembritzki
2018-08-15 21:57                     ` Vivek Goyal
2018-08-15 22:14                       ` Yannik Sembritzki
2018-08-15 21:52                   ` Vivek Goyal
2018-08-15 21:57                     ` James Bottomley
2018-08-15 21:14                 ` Linus Torvalds
2018-08-16 13:51             ` David Howells
2018-08-16 15:16               ` James Bottomley
2018-08-16 15:42                 ` James Bottomley
2018-08-16 15:49               ` David Howells
2018-08-16 15:56                 ` James Bottomley [this message]
2018-08-16 16:56                   ` David Laight
2018-08-16 17:15                     ` James Bottomley
2018-08-16 20:31                 ` David Howells
2018-08-17  0:07                   ` James Bottomley
2018-08-17  8:24                   ` David Howells
2018-08-17 14:58                     ` James Bottomley
2018-08-17 15:42                       ` Justin Forbes
2018-08-17 16:02                         ` James Bottomley
2018-08-16  0:52       ` Dave Young
2018-08-16  0:55         ` Dave Young
2018-08-16 12:13       ` David Howells
2018-08-16 14:22         ` James Bottomley
2018-08-16 14:43         ` David Howells
2018-08-16 14:59           ` James Bottomley
2018-08-17 17:00             ` Alan Cox
2018-08-15 17:45     ` Linus Torvalds
2018-08-15 18:19       ` Yannik Sembritzki
2018-08-15 18:22         ` Linus Torvalds
2018-08-15 19:42           ` [PATCH 0/2] Fix kexec forbidding kernels signed with keys in the secondary keyring " Yannik Sembritzki
2018-08-16 18:02             ` Linus Torvalds
2018-08-15 19:42           ` [PATCH 1/2] " Yannik Sembritzki
2018-08-15 19:42           ` [PATCH 2/2] Replace magic for trusting the secondary keyring with #define Yannik Sembritzki
2018-08-15 21:14             ` kbuild test robot
2018-08-15 21:19               ` [PATCH 2/2] [FIXED] " Yannik Sembritzki
2018-08-15 22:01                 ` Linus Torvalds
2018-08-15 22:07                   ` [PATCH 2/2] [FIXED v2] " Yannik Sembritzki
2018-08-16  1:11                     ` Dave Young
2018-08-16  7:43                       ` Yannik Sembritzki
2018-08-16  8:02                         ` Dave Young
2018-08-16  8:20                           ` Greg Kroah-Hartman
2018-08-16 12:46                       ` Vivek Goyal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1534435000.3166.9.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=bhe@redhat.com \
    --cc=dhowells@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=hpa@zytor.com \
    --cc=jforbes@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=mjg59@google.com \
    --cc=pjones@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=vgoyal@redhat.com \
    --cc=x86@kernel.org \
    --cc=yannik@sembritzki.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).