apps: demonstrate MCUboot sysbuild signing-key custody problem#1
Open
JPHutchins wants to merge 1 commit into
Open
apps: demonstrate MCUboot sysbuild signing-key custody problem#1JPHutchins wants to merge 1 commit into
JPHutchins wants to merge 1 commit into
Conversation
A single SB_CONFIG_BOOT_SIGNATURE_KEY_FILE feeds two images that resolve
relative key paths against different bases: the application image against
APPLICATION_CONFIG_DIR/WEST_TOPDIR, and the MCUboot image against
APPLICATION_CONFIG_DIR/MCUBOOT_DIR. A key referenced relative to the
application is therefore not resolvable by the bootloader image, which
pushes signing keys into unowned module trees (the custody problem).
Add apps/ with runnable sysbuild sub-apps (shared common/src/main.c),
README.md (empirically verified resolution matrix) and FINDINGS.md
(upstream position + citations). Verified on nrf52840dk/nrf52840, ECDSA-P256:
- app_relative_key bare relative -> FAILS, resolves into mcuboot
- key_via_cmake_list_dir ${CMAKE_CURRENT_LIST_DIR} -> FAILS, resolves into zephyr
- key_in_mcuboot_module key copied into mcuboot -> builds, dirties the module
- key_in_app_dir ${APP_DIR} -> builds, key stays in the app (+ twister test)
${APP_DIR} is the only relative form that keeps the key in the user-owned
repo and resolves for both images (expanded once in sysbuild scope at
share/sysbuild/cmake/modules/sysbuild_extensions.cmake), and it is
undocumented -- likely a docs PR upstream.
Add mcuboot to the west.yml import allowlist (needed for these examples).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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 & why
Under sysbuild, a single
SB_CONFIG_BOOT_SIGNATURE_KEY_FILEis propagated to two images that resolve relative key paths against different bases:CONFIG_MCUBOOT_SIGNATURE_KEY_FILEAPPLICATION_CONFIG_DIR(app) →WEST_TOPDIRCONFIG_BOOT_SIGNATURE_KEY_FILEAPPLICATION_CONFIG_DIR(mcuboot src) →MCUBOOT_DIRSo a key referenced relative to the application is not resolvable by the bootloader image — it anchors to the mcuboot module. The naive consequence is that signing keys (gitignored or not) get pushed into repos you don't own. This adds runnable example apps that demonstrate the failure and the workarounds.
The apps (
apps/)All verified on
nrf52840dk/nrf52840, ECDSA-P256 (RSA is currently broken onmain—BOOT_RSA_MBEDTLS_LEGACYvs the mbedtls→TF-PSA-Crypto transition).SB_CONFIG_BOOT_SIGNATURE_KEY_FILEapp_relative_keykeys/…(bare relative)key_via_cmake_list_dir${CMAKE_CURRENT_LIST_DIR}/…key_in_mcuboot_modulekey_in_app_dir${APP_DIR}/keys/…sample.yaml)The two failing forms implicate the two unowned modules: bare-relative → mcuboot,
${CMAKE_CURRENT_LIST_DIR}→ zephyr. Putting the key at the workspace/repo root does not help (the bootloader never falls back toWEST_TOPDIR).Finding
${APP_DIR}is the only relative form that keeps the key in the user-owned repo and resolves for both images — it is expanded once bystring(CONFIGURE)in sysbuild scope (share/sysbuild/cmake/modules/sysbuild_extensions.cmake), so both images get the identical absolute path (no key mismatch). It is undocumented. The cross-image asymmetry is intentional (maintainers declined aWEST_TOPDIRbootloader fallback in mcuboot PR #2591), so the smallest correct upstream action is likely a docs PR. Full upstream position + citations inapps/FINDINGS.md; verified resolution matrix inapps/README.md.Notes
mcubootto thewest.ymlimport allowlist (needed for the sysbuild MCUboot examples).insecure-ec-p256.pem) so the apps clone-and-build.🤖 Generated with Claude Code