[meta-intel] [PATCH] uefi-comboapp.bbclass: support multiple UEFI combo apps + fixes

[Cal Sullivan]

On 07/18/2017 02:04 PM, Patrick Ohly wrote:
> On Tue, 2017-07-18 at 13:44 -0700, Cal Sullivan wrote:
>>> -do_uefiapp_sign[depends] += "${PN}:do_uefiapp_deploy \
>>> -                             sbsigntool-native:do_populate_sysroot"
>>> +# This is intentionally split into different parts. This way,
>> derived
>>> +# classes or images can extend the individual parts. We can also
>> use
>>> +# whatever language (shell script or Python) is more suitable.
>>> +python do_uefiapp() {
>>> +    bb.build.exec_func('create_uefiapps', d)
>>> +    bb.build.exec_func('sign_uefiapps', d)
>>> +}
>> I'd like to move the signing portion to its own flexible bbclass so it
>> can be used elsewhere (systemd-boot, kernel, eventually shim). Would
>> something like what I sent in my last RFC be flexible enough to suite
>> refkit's needs?
> You mean the "Super simple secure boot implementation not requiring
> combo app" approach? I'm still concerned about choosing the initramfs,
> see my reply in that email.
In this instance I'm only talking about the first of the four patches in 
that series which adds the signing bbclass.

>>   Adding the signing portion like this would make my goal a bit harder.
> The code can always be refactored, as long as the end-result is the same
> (do_uefiapp_deploy puts signed bootx64.efi into the rootfs).
Shouldn't be an issue. The bbclass should be able to handle signing any 
valid binary at any point.

>
> uefi-comboapp.bbclass is now in meta-intel master. I think it should be
> fixed or reverted before releasing M2. I don't have a preference either
> way.
With your patch it should be okay functionally and usable in refkit, 
which will get us through M2. I'll work on generalizing the signing 
portion better before moving on to other secure boot implementations, 
but these will need to wait until after M2.

---
Cal