Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <1534439711.3166.13.camel@HansenPartnership.com>
Subject: Re: [PATCH] Fix kexec forbidding kernels signed with custom
 platform keys to boot
From:   James Bottomley <James.Bottomley@HansenPartnership.com>
To:     David Laight <David.Laight@ACULAB.COM>,
        David Howells <dhowells@redhat.com>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        Vivek Goyal <vgoyal@redhat.com>,
        "yannik@sembritzki.me" <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>
Date:   Thu, 16 Aug 2018 10:15:11 -0700
In-Reply-To: <b29ce8375b454440b7b019ac20cfe726@AcuMS.aculab.com>
References: <1534432615.3166.5.camel@HansenPartnership.com>
         <CA+55aFzRHVXP4Ag4aygao1dTGaaMJZSOisHT2ks3_WP97kLLhQ@mail.gmail.com>
         <20180815100053.13609-1-yannik@sembritzki.me>
         <CA+55aFx2goMXj7rQg-qx-puiiWYJmkDMU1xniWEu6ikDBNgfdQ@mail.gmail.com>
         <654fbafb-69da-cd9a-b176-7b03401e71c5@sembritzki.me>
         <20180815174247.GB29541@redhat.com> <20180815185812.GC29541@redhat.com>
         <b2649b70-37b6-3929-a9d0-3d82033b2686@sembritzki.me>
         <20180815194932.GD29541@redhat.com>
         <20628.1534427487@warthog.procyon.org.uk>
         <30607.1534434597@warthog.procyon.org.uk>
         <1534435000.3166.9.camel@HansenPartnership.com>
         <b29ce8375b454440b7b019ac20cfe726@AcuMS.aculab.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, 2018-08-16 at 16:56 +0000, David Laight wrote:
> From: James Bottomley
> > Sent: 16 August 2018 16:57
> > 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
> 
> What about 3rd parties that want to release drivers that can be
> loadedinto 'distribution' kernels?

You'd follow the distributions external kernel module process, I think.

> We can do that for windows (provided we've paid the 'driver signing
> tax') because windows has a stable kernel DDI/DKI.
> For Linux we have to release most of the driver as a binary 'blob'
> and compile wrapper code on the target system with the correct kernel
> headers.

Right, that's the usual distribution kernel module approach.  I'm most
familiar with the SUSE DKMS packaging project, which has a lot of
automation around this.  I believe it's actually pretty easy to use
from talking to people about it.  Of course, SUSE doesn't currently use
signed kernel modules, which makes the key issue a non problem for them
...

> There is no way we could generate signed copies for every
> 'distribution' kernel - even if there was a way to get them signed.
> Even if we agreed to make our source code available it wouldn't be
> accepted for inclusion in the kernel source tree.

Well, I think for signed kernel modules the DKMS process could be
adapted to generate a private key and then install the public component
in the kernel, resign with the private key, put the private key in the
MoK database and that means the DKMS process now has a key with which
it could sign any kernel module at the request of the user.  Of course
the main problem will be guarding the private key.

However, in the above process signing is under the control of the end
user.  I'm guessing you want signing to be under the control of an
external third party or the distro, like the Microsoft case?  In that
case you have to either persuade the distros to run a signing service
or persuade them to trust a third party to run it.

James