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;
Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley
        Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United
        Kingdom.
        Registered in England and Wales under Company Registration No. 3798903
From:   David Howells <dhowells@redhat.com>
In-Reply-To: <1534429345.3166.1.camel@HansenPartnership.com>
References: <1534429345.3166.1.camel@HansenPartnership.com> <20180815185812.GC29541@redhat.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> <4911.1534421610@warthog.procyon.org.uk>
To:     James Bottomley <James.Bottomley@HansenPartnership.com>
Cc:     dhowells@redhat.com, Vivek Goyal <vgoyal@redhat.com>,
        Yannik Sembritzki <yannik@sembritzki.me>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        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 M. 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
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <25235.1534430630.1@warthog.procyon.org.uk>
Date:   Thu, 16 Aug 2018 15:43:50 +0100
Message-ID: <25236.1534430630@warthog.procyon.org.uk>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> I've told you several times you can't use the secure boot keys for any form
> of trust beyond boot,

Yes - and you've been told several times that you're wrong.

As far as I can tell, you seem to think that whilst keys from the UEFI storage
could be used to verify a hacked module, they couldn't be used to verify a
hacked boot-time component (shim, grub, kernel, etc.).

However, if you can load a hacked module, you can very likely replace the
shim, say, with a hacked one.  In fact, replacing the shim may be easier
because modules are tied to their parent kernel in other ways besides the
signing key, whereas a shim must be standalone.

I will grant, however, that it I can understand a desire to reduce the attack
surface by not trusting the UEFI keys beyond booting - but then you shouldn't
use them for kexec *either*.

> Personally, I don't see any use for the UEFI keys in the kernel beyond
> kexec

Allowing you to load the NVidia module, say, into the kernel without the
distribution having to build it in with the kernel.

David