Messages in this thread | | | Date | Thu, 16 Aug 2018 08:55:49 +0800 | From | Dave Young <> | Subject | Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot |
| |
On 08/16/18 at 08:52am, Dave Young wrote: > On 08/15/18 at 01:42pm, Vivek Goyal wrote: > > On Wed, Aug 15, 2018 at 07:27:33PM +0200, Yannik Sembritzki wrote: > > > Would this be okay? > > > > [ CC dave young, Baoquan, Justin Forbes] > > > > Hi Yannik, > > > > I am reading that bug and wondering that what broke it. It used to work, > > so some change broke it. > > > > Justin said that we have been signing fedora kernels with fedora keys so > > looks like no change there. > > > > Previously, I think all the keys used to go in system keyring and it > > used to work. Is it somehow because of split in builtin keyring and > > secondary system keyring. Could it be that fedora key used to show > > up in system keyring previously and it worked but now it shows up > > in secondary system keyring and by default we don't use keys from > > that keyring for signature verification?
The commit introduced this issue is:
commit d3bfe84129f65e0af2450743ebdab33d161d01c9 Author: David Howells <dhowells@redhat.com> Date: Wed Apr 6 16:14:27 2016 +0100
certs: Add a secondary system keyring that can be added to dynamically
> > There was a Fedora bug below: > https://bugzilla.redhat.com/show_bug.cgi?id=1470995 > > I posted a fix here but bobody responsed, I think I obviously did not > consider the "trust build system only" point from Linus: > http://lists.infradead.org/pipermail/kexec/2017-November/019632.html > > But either above patch or defining a macro for the "1UL" in cert header > file works. > > Since nobody reviewed my patch so later I submitted a Fedora only patch > which is similar with Yannik's and merged in Fedora tree: > https://bugzilla.redhat.com/attachment.cgi?id=1450772&action=edit > > > > > Thanks > > Vivek > > > > > > > > diff --git a/arch/x86/kernel/kexec-bzimage64.c > > > b/arch/x86/kernel/kexec-bzimage64.c > > > index 7326078e..2ba47e24 100644 > > > --- a/arch/x86/kernel/kexec-bzimage64.c > > > +++ b/arch/x86/kernel/kexec-bzimage64.c > > > @@ -41,6 +41,9 @@ > > > #define MIN_KERNEL_LOAD_ADDR 0x100000 > > > #define MIN_INITRD_LOAD_ADDR 0x1000000 > > > > > > +// Allow both builtin trusted keys and secondary trusted keys > > > +#define TRUST_FULL_KEYRING (void *)1UL > > > + > > > /* > > > * This is a place holder for all boot loader specific data structure which > > > * gets allocated in one call but gets freed much later during cleanup > > > @@ -532,7 +535,7 @@ static int bzImage64_cleanup(void *loader_data) > > > static int bzImage64_verify_sig(const char *kernel, unsigned long > > > kernel_len) > > > { > > > return verify_pefile_signature(kernel, kernel_len, > > > - NULL, > > > + TRUST_FULL_KEYRING, > > > VERIFYING_KEXEC_PE_SIGNATURE); > > > } > > > #endif > > > -- > > > > > > On 15.08.2018 18:54, Linus Torvalds wrote: > > > > This needs more people involved, and at least a sign-off. > > > > > > > > It looks ok, but I think we need a #define for the magical (void *)1UL > > > > thing. I see the use in verify_pkcs7_signature(), but still. > > > > > > > > Linus > > > > > > > > > > > > > > > > On Wed, Aug 15, 2018 at 3:11 AM Yannik Sembritzki <yannik@sembritzki.me> wrote: > > > >> --- > > > >> arch/x86/kernel/kexec-bzimage64.c | 2 +- > > > >> 1 file changed, 1 insertion(+), 1 deletion(-) > > > >> > > > >> diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c > > > >> index 7326078e..eaaa125d 100644 > > > >> --- a/arch/x86/kernel/kexec-bzimage64.c > > > >> +++ b/arch/x86/kernel/kexec-bzimage64.c > > > >> @@ -532,7 +532,7 @@ static int bzImage64_cleanup(void *loader_data) > > > >> static int bzImage64_verify_sig(const char *kernel, unsigned long kernel_len) > > > >> { > > > >> return verify_pefile_signature(kernel, kernel_len, > > > >> - NULL, > > > >> + (void *)1UL, > > > >> VERIFYING_KEXEC_PE_SIGNATURE); > > > >> } > > > >> #endif > > > >> -- > > > >> 2.17.1 > > > >> > > > >> The exact scenario under which this issue occurs is described here: > > > >> https://bugzilla.redhat.com/show_bug.cgi?id=1554113 > > > >> > > > > > Thanks > Dave
| |