signed-boot verify_signature hole?

[Brett Grandbois]

We're more interested in the signature verification aspect rather than 
encryption so we'd take on that path.  One of the things I'm planning to 
do is add in a crypto back-end switch for openssl support.  Not that I 
have anything against gpgme, but our implementation is in a fairly 
space-constrained environment where openssl is already present due to 
existing support lib dependencies.

This is of course assuming IBM doesn't present some awesome new secure 
boot process shortly... ;-)


On 14/03/18 06:30, Timothy Pearson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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.
>
> 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
>
> - -- 
> Timothy Pearson
> Raptor Engineering
> +1 (415) 727-8645 (direct line)
> +1 (512) 690-0200 (switchboard)
> https://www.raptorengineering.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJaqDTfAAoJEK+E3vEXDOFbHU8H/0sWnYPSWbUGRxzqpAfhw631
> JyRS1BnK/Us9ya9dE4rOcYdKWsn8WT4f1aoj9w3SxoVdz1UK7/EuLj4RPXl+/Gtk
> KoDy7vHUitTDdCCODuPk5OF2neiKKIDsbAfBvRrNtWyneZL3oOikUZ2inOI+gKWZ
> oV7B4zQHC4ru1IqSlwVjeMo9xNrmmi5b9jpnA19ui7DH+UgYoDAUJrYyG6+alPcQ
> iX44RZJToW5+KRic0EPPM8iaMg68K1MHX8fPuAfVFG6e4OFjRdJOGveTL7XXNzgw
> cRfaQHQUeRfQD6TyrJWqaC/2NYADyUGB4qulnpnSZAbEuDbRN37pP5Y9qZvyxrc=
> =ChHt
> -----END PGP SIGNATURE-----