[PATCH v1] configs: qualcomm: Add secure boot config fragment

[Casey Connolly]

Hi Aswin,

On 7/3/26 15:01, Aswin Murugan wrote:
> Hi Casey/Ilias,
> 
> Thanks for the feedback and apologies for not providing enough context 
> in the commit message.
> The intention of this patch is not to introduce a complete Secure Boot 
> solution by itself, but to provide a common configuration fragment that 
> enables the EFI Secure Boot framework and the required hash algorithm 
> support across.

Since this is just additional functionality, and we are hardly space 
constrained on Qualcomm platforms, I think it would be acceptable to add 
this to qcom_defconfig (with the exception of PRESEED I guess).

> When these secure boot configurations are enabled, a persistent EFI 
> variable store (ubootefi.var) is expected to be present in workspace 
> before building. Platform keys and signature databases (PK/KEK/db) are 
> provisioned into that variable store using the efivar.py tooling.

Then you should really propose some docs or at least roughly outline how 
this works (maybe pointing to the existing docs?). In the end if we're 
enabling functionality it should be clear how one might use it...

> At boot time, U-Boot loads the EFI variables from ubootefi.var, and EFI 
> image authentication is performed using the enrolled keys. The 
> expectation is that kernel EFI images are signed with the same keys 
> enrolled in ubootefi.var, and are authenticated by U-Boot against those 
> enrolled keys during boot.
> I agree that this fragment alone does not establish a complete platform 
> secure boot chain. My goal here was to avoid duplicating the common EFI 
> Secure Boot configuration across Qualcomm boards that use this workflow.
> Suggestions are welcome on whether this should be handled differently. 
> In particular, I'd also be interested in exploring Ilias' suggestion of 
> integrating efivar.py into the EFI loader build flow so that a default 
> ubootefi.var can be generated automatically from the EFI loader 
> Makefile, rather than requiring it to be created as a separate manual step.

That sounds good, but we're missing the forest for the trees a bit here. 
I'd love to see some docs explaining how I might go and test EFI 
secureboot on my Rubik Pi 3 (for example).

Ilias: do you think it would be possible and/or sensible to have a 
generic efi-secureboot.config fragment in the toplevel configs/ dir so 
that it could be used easily on Rockchip/Amlogic etc SoCs?

Thanks,
// Casey
> 
> Thanks,
> Aswin
> 
> On 7/1/2026 5:52 PM, Aswin Murugan wrote:
>> Add a common configuration fragment for EFI Secure Boot and the
>> required hash algorithm configs to reuse across Qualcomm boards.
>>
>> Signed-off-by: Aswin Murugan <aswin.murugan at oss.qualcomm.com>
>> ---
>>   board/qualcomm/secure-boot.config | 6 ++++++
>>   1 file changed, 6 insertions(+)
>>   create mode 100644 board/qualcomm/secure-boot.config
>>
>> diff --git a/board/qualcomm/secure-boot.config b/board/qualcomm/ 
>> secure-boot.config
>> new file mode 100644
>> index 00000000000..21f567e1a45
>> --- /dev/null
>> +++ b/board/qualcomm/secure-boot.config
>> @@ -0,0 +1,6 @@
>> +# Enables EFI Secure Boot support
>> +CONFIG_EFI_VARIABLES_PRESEED=y
>> +CONFIG_EFI_SECURE_BOOT=y
>> +CONFIG_FIT_SIGNATURE=y
>> +CONFIG_SHA512=y
>> +CONFIG_SHA384=y