linux-kernel - Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 16 Aug 2018 08:55:49 +0800
From:   Dave Young <dyoung@...hat.com>
To:     Vivek Goyal <vgoyal@...hat.com>
Cc:     Yannik Sembritzki <yannik@...britzki.me>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        David Howells <dhowells@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Peter Anvin <hpa@...or.com>,
        the arch/x86 maintainers <x86@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Baoquan He <bhe@...hat.com>,
        "Justin M. Forbes" <jforbes@...hat.com>
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@...hat.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@...britzki.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