signed-boot verify_signature hole?

[Samuel Mendoza-Jonas]

On Tue, 2018-03-13 at 15:30 -0500, Timothy Pearson wrote:
> Sorry about the radio silence on this; been preoccupied with other parts
> of the firmware stack.
> 
> Yes, we still use this feature.  In particular it supports boot of an
> encrypted kernel, which is useful when remote loading over a hostile
> network connection (think initrd with Kerberos machine keys, which is
> one of our real-world use cases).
> 
> I'd like to see the bugs fixed up and the feature retained as an
> alternate to the signed load mechanism.  Let met get past the current
> DD2.2 bringup issues and then I'll dive back into the petitboot code.

Good to hear this is still a desired feature for TALOS - and no worries,
I'm all too familiar with DDX.X bringup issues :)

> 
> Thanks!
> 
> On 03/12/2018 09:32 PM, Samuel Mendoza-Jonas wrote:
> > 
> > On Mon, 2018-03-12 at 10:01 +1000, Brett Grandbois wrote:
> > > 
> > > Hi,
> > > 
> > > We're looking at adopting the signed-boot system in our platform and
> > > going through the implementation I've noticed something I need to ask
> > > the wider community about.  In lib/security/gpg.c in
> > > gpg_validate_boot_files() the initial commit had this code block:
> > > 
> > > > +    if (verify_file_signature(kernel_filename,
> > > > +        local_image_signature,
> > > > +        authorized_signatures_handle, "/etc/gpg"))
> > > > +        result = KEXEC_LOAD_SIGNATURE_FAILURE;
> > > > +    if (verify_file_signature(cmdline_template,
> > > > +        local_cmdline_signature,
> > > > +        authorized_signatures_handle, "/etc/gpg"))
> > > > +        result = KEXEC_LOAD_SIGNATURE_FAILURE;
> > > 
> > > where the following commit that adds in the decryption support removes
> > > the:
> > > 
> > > > result = KEXEC_LOAD_SIGNATURE_FAILURE;
> > > 
> > > lines to the kernel and command line checks, effectively making them
> > > irrelevant in the boot_task->verify_signature path?
> > > 
> > > Is there some other check somewhere else that I've missed?
> > > 
> > > 
> > 
> > Hi Brett,
> > 
> > No, looks like you've found a legitimate bug. Those if statements will
> > fall through to the initrd signature check,
> > making it possible to boot with an invalid kernel and command line.
> > In the short term we should obviously fix that. Longer term I reckon
> > it's worth thinking about how/if we use and
> > consume the signed boot code.
> > 
> > The signed/encrypted boot code was added in 2016 by Timothy (CC'd)
> > mainly for their TALOS OpenPOWER P8
> > machine. That didn't fully ship AFAIK and focus moved to TALOS II (P9).
> > So while the signed/encrypted boot code
> > has been tested and checked by myself and Timothy, I don't know anyone
> > that's actually used this in any
> > seriousness, and I'm not sure whether the Raptor Engineering people
> > intend to use it for TALOS II - Timothy can you
> > weigh in on that?
> > 
> > At the same time I'm aware of a lot of work going on by other IBMers to
> > implement full-stack secure and trusted boot.
> > How that fits in next to what we have now or whether we should see if
> > one should replace the other are questions that
> > have been the back of my mind.
> > George and Claudio - would you mind giving us a brief rundown for the
> > benefit of the Petitboot list of how IBM's
> > secure/trusted boot process will work, and the main ways that could
> > impact Petitboot specifically?
> > Additionally how will IBM's implementation affect users such as Brett
> > who are using Petitboot but are not running on a
> > POWER machine, ie. not OPAL?
> > 
> > Regards,
> > Sam
> > 
> > > 
> > > -- 
> > > Brett Grandbois
> > > Software Engineering
> > > Opengear Inc.
> > > www.opengear.com <http://www.opengear.com>
> > > _______________________________________________
> > > Petitboot mailing list
> > > Petitboot at lists.ozlabs.org <mailto:Petitboot at lists.ozlabs.org>
> > > https://lists.ozlabs.org/listinfo/petitboot
> 
> 
> _______________________________________________
> Petitboot mailing list
> Petitboot at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/petitboot