signed-boot verify_signature hole?

[Timothy Pearson]

-----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-----