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 <[email protected]>
---
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
