lemans: OEM secure-boot signing (edl-secure-package / edl-secure-bootloader) - #1
Open
zelvam95 wants to merge 3 commits into
Open
lemans: OEM secure-boot signing (edl-secure-package / edl-secure-bootloader)#1zelvam95 wants to merge 3 commits into
zelvam95 wants to merge 3 commits into
Conversation
Adds `make edl-secure-package` and its prerequisite `make spl-oem-sign`, alongside the existing `make edl-package`, for boot-chain testing on OEM-secure-boot-fused EVKs. This build root's default signing path (qtestsign, used by `make spl`) does not perform real cryptographic signing -- qtestsign.py's own docstring states no signature is generated and the tool only works with firmware secure boot disabled. It cannot be used as-is on a fused board. spl-oem-sign OEM-signs the SWIV-annotated U-Boot SPL ELF via sectools (--image-id TZ, --signing-mode TEST, no CASS/QTI-REMOTE required), writing lemans/output/tz-secure.mbn separately from tz.mbn (the qtestsign output), so neither target can clobber the other's result. edl-secure-package builds on edl-package's output and OEM-signs the three PBL/XBL-SEC-authenticated payloads: xbl.elf --image-id XBL xbl_config.elf --image-id XBL-CONFIG tz.mbn --image-id TZ (= tz-secure.mbn from spl-oem-sign) Only these three are OEM-signed. uefi.elf (the FIT: TF-A BL31 + OP-TEE OS + U-Boot proper, assembled by the `uefi` target) does not need OEM signing on this bootflow -- U-Boot SPL (SPL_LOAD_FIT) reads the uefi partition itself, directly off UFS, rather than trusting a DRAM copy XBL-SEC loaded during SBL1. Confirmed on hardware: a successful boot showed XBL-SEC truncating the unsigned uefi.elf to a 148-byte stub (the same rejection signature an unsigned TZ always gets) and the board still booted fine, since SPL never reads that DRAM copy. Contrast sandbox.lemans's TF-A BL2 bootflow, which does require uefi.elf to be OEM-signed, because BL2 trusts exactly that DRAM handoff. Adds build/lemans/security/lemans_tz_security_profile.xml, not previously needed by this build root's qtestsign-only flow; reuses the existing swiv_build_utility.py. Signing is OEM-only, unlike sandbox.lemans's equivalent target, which needs double (OEM+QTI) signing for its TF-A-BL2-based tz.mbn -- U-Boot SPL is a different image occupying the same tz-partition role, and this build root has no QTI/CASS signing path at all. TESTED AND CONFIRMED WORKING end-to-end on the fused SA8775P lemans EVK: VIP-flashed and booted to a running Linux kernel with all 8 CPUs up. PBL and SBL1 hash-segment authentication both passed cleanly; the tz partition (OEM-signed SPL) loaded as a real 306,436-byte image with "Segments hash check" present (contrast with the 148-byte/no-hash-check failure consistently seen on the TF-A BL2 path in sandbox.lemans before its own uefi.elf was OEM-signed). OEM-only signing of XBL, XBL-CONFIG, and SPL is sufficient here -- no QTI/CASS signing required.
Adds edl-secure-bootloader, mirroring edl-secure-package's relationship to edl-package but for the LUN1-4-only edl-bootloader path -- the fast re-flash target for OEM secure-boot testing when only TF-A/OP-TEE/U-Boot changed (e.g. after cherry-picking new PAS auth commits into optee_os), without needing a full LUN0-5 efi.bin/rootfs re-flash each time. Same OEM-signing scope as edl-secure-package: XBL, XBL-CONFIG, and TZ (the SPL, via spl-oem-sign) are OEM-signed; uefi.elf is left as edl-bootloader produced it (qtestsign, not OEM-signed) -- U-Boot SPL reads the uefi partition itself from storage, so it does not need OEM signing here, unlike sandbox.lemans's TF-A BL2 bootflow. See the docs update for the full mechanism. Verified: xbl.elf, xbl_config.elf, tz.mbn all OEM-signed (sectools --inspect, root hash 0x9cda6268...); uefi.elf confirmed byte-identical to edl-bootloader's unsigned copy (untouched, as intended).
Adds a new "OEM Secure-Boot Signing" section to the comprehensive Lemans doc (build/docs/lemans.html), covering spl-oem-sign / edl-secure-bootloader / edl-secure-package: what gets OEM-signed (XBL, XBL-CONFIG, TZ) and why uefi.elf does not need it on this bootflow, unlike sandbox.lemans's TF-A BL2 bootflow. The explanation is the board-confirmed mechanism, not just an observed target-by-target rule: TF-A BL2 trusts a fixed-address DRAM copy of the FIP that XBL-SEC is expected to have already loaded during SBL1 (PLAT_QTI_FIP_IOBASE); if XBL-SEC rejects an unsigned FIP, BL2 reads a 148-byte stub there and fails with "BL2: Failed to load image id 3 (-2)" (a plain FIP-ToC lookup miss -- TRUSTED_BOARD_BOOT is 0, so FIP signature checking is compiled out of BL2 entirely; the real fault is one stage earlier, in XBL-SEC). U-Boot SPL (SPL_LOAD_FIT) does not rely on that DRAM handoff at all -- it reads the uefi partition itself, directly off UFS, so an XBL-SEC-truncated DRAM copy is irrelevant. This was verified on hardware: a successful U-Boot SPL boot showed APPSBL (the uefi/FIT partition) truncated to 148 bytes by XBL-SEC exactly like an unsigned image always is, and the board still booted to Linux. Also updates the Make Targets table with spl-oem-sign, edl-secure-bootloader, and edl-secure-package, and adds an Agenda card + sidebar entry for the new section.
zelvam95
changed the title
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
1 participant
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.
Adds OEM secure-boot signing support for the U-Boot SPL bootflow, tested
end-to-end on a fused SA8775P Lemans EVK.
(LUN1-4, fast re-flash), mirroring edl-package/edl-bootloader. Both
OEM-sign XBL, XBL-CONFIG, and TZ (the SPL, via a new spl-oem-sign
target) using local sectools TEST mode -- no QTI/CASS signing anywhere.
This repo's default signing (qtestsign) does not produce a real
signature at all and only works with secure boot disabled, per its own
docstring, so it cannot be used as-is on a fused board.
U-Boot SPL reads the uefi partition itself from storage, so it never
depends on an XBL-SEC-loaded DRAM copy the way a TF-A-BL2-based bootflow
does. Verified on hardware: a boot with uefi.elf unsigned showed XBL-SEC
truncating it to a 148-byte stub exactly like it does to any unsigned
image, and the board still booted fine, since SPL never reads that DRAM
copy. See the new "OEM Secure-Boot Signing" section in
build/docs/lemans.html for the full mechanism.
table with spl-oem-sign / edl-secure-package / edl-secure-bootloader.
Verified on hardware: XBL/XBL-CONFIG/TZ OEM-signed (sectools --inspect:
OEM Signature Size 104, QTI Signature Size 0, same root of trust
throughout), VIP-flashed via fh_loader/QSaharaServer, boots to a running
Linux kernel.