mcuboot: support multiple signing keys#1
Open
JPHutchins wants to merge 1 commit into
Open
Conversation
JPHutchins
requested review from
aldenhaase,
Copilot,
davedesro,
intercreate-gab,
kylermconnelly and
robhelvestine
There was a problem hiding this comment.
Pull request overview
Draft integration of MCUboot “multiple signing keys” support into Zephyr’s sysbuild flow, including new Kconfig/CMake plumbing, documentation, and a sample demonstrating the dual-key verification use case.
Changes:
- Switch MCUboot module source to a fork/branch carrying the multi-key feature.
- Add
*_KEY_FILE_2support across sysbuild Kconfig/CMake and expose it to app configuration. - Add a new sysbuild sample + docs/release-notes updates and a new test scenario.
Reviewed changes
Copilot reviewed 19 out of 19 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| west.yml | Points MCUboot module to a fork/feature branch for the multi-key work. |
| tests/boot/test_mcuboot/testcase.yaml | Adds a new test variant enabling the second key setting. |
| tests/boot/test_mcuboot/root-ed25519-2.pem | Adds an ED25519 key file used by the new test variant. |
| share/sysbuild/images/bootloader/Kconfig | Introduces BOOT_SIGNATURE_KEY_FILE_2 and clarifies key path semantics. |
| share/sysbuild/images/bootloader/CMakeLists.txt | Normalizes signing key paths (incl. second key) before passing to MCUboot image. |
| share/sysbuild/image_configurations/MAIN_image_default.cmake | Forwards second key path into main app Kconfig (CONFIG_MCUBOOT_SIGNATURE_KEY_FILE_2). |
| share/sysbuild/image_configurations/FIRMWARE_LOADER_image_default.cmake | Forwards second key path into firmware-loader app Kconfig. |
| scripts/ci/check_compliance.py | Allows the new Kconfig symbol in compliance checks. |
| samples/sysbuild/mcuboot_dual_key/sysbuild/mcuboot.conf | Sample-specific MCUboot config fragment. |
| samples/sysbuild/mcuboot_dual_key/sysbuild.conf | Sysbuild configuration demonstrating dual accepted verification keys. |
| samples/sysbuild/mcuboot_dual_key/src/main.c | Minimal app used by the new sysbuild sample. |
| samples/sysbuild/mcuboot_dual_key/sample.yaml | Adds test definition for the new sample. |
| samples/sysbuild/mcuboot_dual_key/prj.conf | Placeholder application config for the sample. |
| samples/sysbuild/mcuboot_dual_key/keys/prod_pubkey.pem | Public-only PEM embedded as the “production” verification key in the sample. |
| samples/sysbuild/mcuboot_dual_key/README.rst | End-to-end documentation for the dual-key sysbuild sample. |
| samples/sysbuild/mcuboot_dual_key/CMakeLists.txt | Sysbuild-enabled sample CMake wiring. |
| modules/Kconfig.mcuboot | Adds MCUBOOT_SIGNATURE_KEY_FILE_2 to expose the second key path to app builds. |
| doc/releases/release-notes-4.5.rst | Release note entry for the new sysbuild option and sample. |
| doc/build/signing/index.rst | Documents SB_CONFIG_BOOT_SIGNATURE_KEY_FILE_2 in the signing guide. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
JPHutchins
force-pushed
the
mcuboot/multiple-signing-keys
branch
2 times, most recently
from
7c86709 to
6ea44fe
Compare
Collaborator
Author
|
Good results by following the readme! |
davedesro
approved these changes
May 29, 2026
JPHutchins
force-pushed
the
mcuboot/multiple-signing-keys
branch
from
6ea44fe to
5c070ce
Compare
JPHutchins
force-pushed
the
mcuboot/multiple-signing-keys
branch
from
5c070ce to
5b45aad
Compare
JPHutchins
commented
Jun 10, 2026
JPHutchins
commented
Jun 10, 2026
JPHutchins
commented
Jun 10, 2026
JPHutchins
commented
Jun 10, 2026
JPHutchins
commented
Jun 10, 2026
JPHutchins
commented
Jun 10, 2026
JPHutchins
commented
Jun 10, 2026
JPHutchins
commented
Jun 12, 2026
JPHutchins
commented
Jun 12, 2026
JPHutchins
commented
Jun 12, 2026
JPHutchins
commented
Jun 12, 2026
JPHutchins
left a comment
JPHutchins
left a comment
Collaborator
Author
There was a problem hiding this comment.
Pretty good. Hoping to reduce LOC, espcially around verbose LLM-style comments!
JPHutchins
force-pushed
the
mcuboot/multiple-signing-keys
branch
from
838eb5d to
78d2dfe
Compare
Collaborator
Author
|
Addressed all 25 review comments from this round in Net LOC: −178 (PR total +1263/−9 → +1085/−9, a 14% cut) — all prose, comments, and duplication; no coverage lost. Highlights beyond comment trims:
Verified: both QEMU scenarios pass ( Left open for your call: the |
JPHutchins
force-pushed
the
mcuboot/multiple-signing-keys
branch
from
1b5f693 to
6af2720
Compare
github-actions
Bot
added
manifest-hal_bouffalolab
manifest-lvgl
manifest-percepio
manifest-hal_adi
manifest-hal_nordic
manifest-trusted-firmware-a
manifest-hal_xtensa
manifest-hal_espressif
manifest-hal_atmel
manifest-trusted-firmware-m
manifest-hal_infineon
manifest-hal_stm32
manifest-hal_silabs
manifest-nrf_wifi
manifest-hal_nxp
manifest-hostap
DNM (manifest)
Binary Blobs Modified
Binary Blobs Added
labels
JPHutchins
pushed a commit
that referenced
this pull request
Jul 7, 2026
struct bt_uuid was used for storage instead of struct bt_uuid_any
resulting in overflow when converting BTP UUID to bt_uuid.
==3608402==ERROR: AddressSanitizer: stack-buffer-overflow on address
0xe02f5da2 at pc 0x0805a750 bp 0xe14e2048 sp 0xe14e2038
WRITE of size 2 at 0xe02f5da2 thread T7
#0 0x805a74f in btp2bt_uuid zephyr/tests/bluetooth/tester/src/btp_gatt.c:212
#1 0x805d31c in get_handle_from_uuid zephyr/tests/bluetooth/tester/src/btp_gatt.c:2149
#2 0x804f12c in cmd_handler zephyr/tests/bluetooth/tester/src/btp.c:122
#3 0x807c582 in z_thread_entry zephyr/kernel/sys/thread_entry.c:60
zephyrproject-rtos#4 0x807cdd2 in posix_arch_thread_entry zephyr/arch/posix/core/thread.c:124
zephyrproject-rtos#5 0x80ff2bd in nct_thread_starter zephyr/scripts/native_simulator//common/src/nct.c:291
zephyrproject-rtos#6 0xeb1949a3 in asan_thread_start ../../../../../src/libsanitizer/asan/asan_interceptors.cpp:234
zephyrproject-rtos#7 0xeaea5136 (/lib32/libc.so.6+0x8b136) (BuildId: 798ae816ef14b98dc77560340190445fb200634a)
zephyrproject-rtos#8 0xeaf39de7 (/lib32/libc.so.6+0x11fde7) (BuildId: 798ae816ef14b98dc77560340190445fb200634a)
Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
JPHutchins
force-pushed
the
mcuboot/multiple-signing-keys
branch
from
6af2720 to
0324e75
Compare
SB_CONFIG_BOOT_SIGNATURE_KEY_FILE now accepts a comma-separated list of PEM paths in addition to a single path. When a list is given, the MCUboot bootloader embeds the public half of every key and accepts an image signed with any of them. The first entry is also the key the application is signed with; every entry past the first must be a public-only PEM of the same signature type (MCUboot enforces this at build time with 'imgtool keyinfo --require public'). A common use is a development bootloader that boots both development- and production-signed images while never holding the production private key. The keys the bootloader embeds and the single key the application is signed with are both derived from this one list through the sysbuild helpers sysbuild_mcuboot_resolve_signature_key_files() and sysbuild_mcuboot_application_signature_key_file(). Entries are forwarded verbatim for each image to resolve, so a single-key value behaves exactly as before and no previously working configuration breaks. The feature is exercised at runtime by tests/boot/mcuboot_multiple_keys, which builds a two-key bootloader on the mps2/an385 QEMU machine and boots an application signed with either embedded key, asserting MCUboot validates it against the matching key (key_id 0 and key_id 1). The two keys are MCUboot's own ed25519 test keys: a development key (key_id 0) and a production key embedded by its public half only (key_id 1). The application is signed at build time with the development key; the second scenario re-signs the built image with the production key afterwards, the way a production custodian signs a release binary out-of-band, so the production private key never enters the build configuration. Signed-off-by: JP Hutchins <jp@intercreate.io> Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
JPHutchins
force-pushed
the
mcuboot/multiple-signing-keys
branch
from
0324e75 to
3299247
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
SB_CONFIG_BOOT_SIGNATURE_KEY_FILEnow accepts a comma-separated list of PEM pathsin addition to a single path. The MCUboot bootloader embeds the public half of every
listed key and accepts an image signed by any of them; the application is signed with
the first entry, and every entry past the first must be a public-only PEM (enforced at
build time with
imgtool keyinfo --require public). The canonical use is a developmentbootloader that boots both development- and production-signed images while never holding
the production private key.
Both the keys the bootloader embeds and the single key the application is signed with
derive from this one list, resolved through a single sysbuild helper
(
sysbuild_mcuboot_resolve_signature_key_files()) against the application sourcedirectory, so the application is always signed with exactly the key whose public half is
embedded — including for relative paths.
Dependency
Requires the multiple-key support in MCUboot (mcu-tools/mcuboot#2701, merged). The
manifest is pinned to
zephyrproject-rtos/mcuboot@5497c95f.Testing
tests/cmake/sysbuild_mcuboot_keys— HW-free unit test of the key-path resolver(absolute / relative /
${VAR}/ multi-key / whitespace forms) at CMake configure time.tests/boot/mcuboot_multiple_keys— runtime acceptance test on the mps2/an385 QEMUmachine (pytest harness): a two-key bootloader boots an application signed with either
embedded key (
key_id 0andkey_id 1), with no DFU, swap or SMP.tests/boot/test_mcuboot— gains a two-key bootloader swap scenario (hardware).samples/sysbuild/mcuboot_signing_keysdemonstrates the development/productioncustody split.