[{"data":1,"prerenderedAt":612},["ShallowReactive",2],{"search-index":3,"doc-verified-boot-patterns-uboot-keys-failure-modes":101},[4,8,12,17,21,25,29,33,37,42,47,52,57,62,67,72,77,82,87,92,97],{"_path":5,"title":6,"description":7},"/dev/eu-cyber-resilience-act-firmware-evidence-pack","Eu Cyber Resilience Act Firmware Evidence Pack","title: \"EU Cyber Resilience Act in Practice for Firmware Teams: Engineering Tasks and Evidence Pack\"\ndescription: \"Practical breakdown of the EU Cyber Resilience Act requirements for embedded firmware teams, covering technical obligations, SBOM requirements, vulnerability handling, and the evidence pack needed for compliance.\"\ndate: 2026-04-19T08:00:00Z\nlastmod: 2026-04-19T08:00:00Z\ndraft: false\nhero: \"/images/hero/eu-cyber-resilience-act-firmware-evidence-pack-1600x900.jpg\"\ntags:",{"_path":9,"title":10,"description":11},"/dev/pkg/firmware-sboms-spdx-cyclonedx-2026","Firmware Sboms Spdx Cyclonedx 2026","title: \"Firmware SBOMs in 2026: SPDX vs CycloneDX, What to Publish, and What to Automate\"\ndescription: \"Practical comparison of SPDX and CycloneDX for firmware SBOMs, covering what to include, automation approaches, tooling, and publication strategies for embedded Linux products.\"\ndate: 2026-04-19T08:00:00Z\nlastmod: 2026-04-19T08:00:00Z\ndraft: false\nhero: \"/images/hero/firmware-sboms-spdx-cyclonedx-2026-1600x900.jpg\"\ntags:",{"_path":13,"title":14,"description":15,"date":16},"/dev/pkg/spdx-3-0-embedded-builds-practical","SPDX 3.0 for Embedded Builds: Packages, Files, and Relationships Engineers Actually Use","Practical guide to SPDX 3.0 for embedded Linux, covering the data model, package and file elements, relationship types, and how to produce useful SPDX documents from Yocto and Buildroot builds.","2026-04-19T08:00:00Z",{"_path":18,"title":19,"description":20},"/dev/slsa-build-provenance-firmware-sign-verify","Slsa Build Provenance Firmware Sign Verify","title: \"SLSA Build Provenance for Firmware: What to Collect, How to Sign, How to Verify\"\ndescription: \"Practical implementation guide for SLSA build provenance in firmware pipelines, covering provenance generation, signing with Sigstore, verification workflows, and integration with SBOMs.\"\ndate: 2026-04-19T08:00:00Z\nlastmod: 2026-04-19T08:00:00Z\ndraft: false\nhero: \"/images/hero/slsa-build-provenance-firmware-sign-verify-1600x900.jpg\"\ntags:",{"_path":22,"title":23,"description":24},"/dev/vex-csaf-embedded-not-affected-scale","Vex Csaf Embedded Not Affected Scale","title: \"VEX and CSAF for Embedded Devices: Publishing \"Not Affected\" at Scale\"\ndescription: \"How to produce and distribute VEX documents and CSAF advisories for embedded firmware, enabling downstream consumers to filter false positives from vulnerability scans.\"\ndate: 2026-04-15T20:03:00Z\nlastmod: 2026-04-15T20:03:00Z\ndraft: false\nhero: \"/images/hero/vex-csaf-embedded-not-affected-scale-1600x900.jpg\"\ntags:",{"_path":26,"title":27,"description":28},"/dev/yocto-5-2-walnascar-highlights-embedded-2026","Yocto 5 2 Walnascar Highlights Embedded 2026","title: \"Yocto 5.2 \"Walnascar\" Highlights for Embedded Teams: Toolchain, Security, SPDX 3.0\"\ndescription: \"Key changes in Yocto 5.2 Walnascar relevant to embedded product teams, covering toolchain updates, security improvements, SPDX 3.0 support, and migration notes.\"\ndate: 2026-04-12T08:14:00Z\nlastmod: 2026-04-12T08:14:00Z\ndraft: false\nhero: \"/images/hero/yocto-5-2-walnascar-highlights-embedded-2026-1600x900.jpg\"\ntags:",{"_path":30,"title":31,"description":32},"/dev/yocto-esdk-faster-iteration-2026","Yocto Esdk Faster Iteration 2026","title: \"Yocto eSDK in 2026: Faster Application Iteration Without Full Rebuild Cycles\"\ndescription: \"How to use Yocto's extensible SDK to speed up application development by building and testing packages without running full BitBake builds.\"\ndate: 2026-04-11T07:09:00Z\nlastmod: 2026-04-11T07:09:00Z\ndraft: false\nhero: \"/images/hero/yocto-esdk-faster-iteration-2026-1600x900.jpg\"\ntags:",{"_path":34,"title":35,"description":36},"/dev/yocto-layers-maintainable-strategy-2026","Yocto Layers Maintainable Strategy 2026","title: \"Yocto Layers That Stay Maintainable: Layer Model, Naming, and Upgrade Strategy (2026)\"\ndescription: \"Practical guidance on structuring Yocto layers for long-term maintainability, covering layer boundaries, naming conventions, version pinning, and upgrade workflows.\"\ndate: 2026-04-07T13:41:00Z\nlastmod: 2026-04-07T13:41:00Z\ndraft: false\nhero: \"/images/hero/yocto-layers-maintainable-strategy-2026-1600x900.jpg\"\ntags:",{"_path":38,"title":39,"description":40,"date":41},"/doc/bootlin-toolchains-arm-riscv-2026","Bootlin Toolchains in Practice: Picking the Right Prebuilt Toolchain for ARM and RISC-V","How to select and validate Bootlin prebuilt cross-compilation toolchains for ARM Cortex-A, Cortex-M, and RISC-V targets in embedded Linux projects.","2026-03-10T16:05:00Z",{"_path":43,"title":44,"description":45,"date":46},"/doc/buildroot-vs-yocto-2026","Buildroot vs Yocto in 2026: Which Embedded Linux Build System Fits Your Product Lifecycle?","A detailed comparison of Buildroot and Yocto for embedded Linux, covering build performance, long-term maintenance, layer ecosystems, and practical decision criteria for product teams in 2026.","2026-03-05T08:12:00Z",{"_path":48,"title":49,"description":50,"date":51},"/doc/cross-compilation-toolchain-triplet-clib-2026","Cross-Compilation in 2026: Choosing a Toolchain, Target Triplet, and C Library (glibc vs musl)","Practical guidance on selecting cross-compilation toolchains for embedded Linux, understanding target triplets, and choosing between glibc and musl for your production firmware.","2026-03-07T07:43:00Z",{"_path":53,"title":54,"description":55,"date":56},"/doc/erofs-vs-squashfs-2026","EROFS in 2026: When a Read-Only Filesystem Beats SquashFS (Performance, Dedupe, Updates)","Detailed comparison of EROFS and SquashFS for embedded Linux in 2026, covering read performance, compression ratios, deduplication, and integration with OTA update schemes.","2026-03-22T14:22:00Z",{"_path":58,"title":59,"description":60,"date":61},"/doc/ota-updates-rauc-swupdate-mender-2026","OTA Updates in 2026: RAUC vs SWUpdate vs Mender for Robust Fleet Management","Comparison of RAUC, SWUpdate, and Mender for embedded Linux OTA updates, covering update models, rollback strategies, fleet management, and integration with Yocto and Buildroot.","2026-03-28T19:07:00Z",{"_path":63,"title":64,"description":65,"date":66},"/doc/plat/device-tree-debugging-overlays-validation-2026","Device Tree Debugging for Embedded Linux: Overlays, Common Errors, and Validation","Practical guide to debugging device tree issues in embedded Linux, covering overlay mechanics, common DTS errors, validation tools, and runtime debugging techniques.","2026-04-05T06:58:00Z",{"_path":68,"title":69,"description":70,"date":71},"/doc/plat/porting-checklist-bootloader-kernel-rootfs-2026","Porting Checklist 2026: Bootloader → Kernel → RootFS for New Boards","Complete checklist for porting embedded Linux to a new board, from bootloader bring-up through kernel configuration to root filesystem validation, with practical tips for each stage.","2026-04-02T15:16:00Z",{"_path":73,"title":74,"description":75,"date":76},"/doc/real-time-linux-preempt-rt-latency-2026","Real-Time Linux in 2026: PREEMPT_RT Basics, Tuning, and How to Prove Latency","Practical guide to PREEMPT_RT on embedded Linux covering kernel configuration, IRQ threading, latency measurement with cyclictest, and tuning techniques for deterministic response times.","2026-03-23T05:48:00Z",{"_path":78,"title":79,"description":80,"date":81},"/doc/rootfs-integrity-dm-verity-immutable-images","Root Filesystem Integrity with dm-verity: Design Patterns for Immutable Images","How to design and implement dm-verity-protected root filesystems for embedded Linux, covering hash tree generation, kernel integration, error handling, and update strategies.","2026-03-19T08:56:00Z",{"_path":83,"title":84,"description":85,"date":86},"/doc/rtos-vs-embedded-linux-zephyr-2026","RTOS vs Embedded Linux in 2026: Where Zephyr Fits and Where Full Linux Wins","Practical comparison of RTOS (Zephyr, FreeRTOS) and embedded Linux for product design, covering latency, memory footprint, ecosystem maturity, and hybrid architectures.","2026-03-30T09:35:00Z",{"_path":88,"title":89,"description":90,"date":91},"/doc/secure-boot-uboot-fit-signatures-chain-of-trust","Secure Boot with U-Boot FIT Signatures: A Practical Chain-of-Trust Walkthrough","Step-by-step guide to implementing secure boot using U-Boot FIT image signatures, from key generation through verified boot to failure handling on embedded Linux targets.","2026-03-14T06:29:00Z",{"_path":93,"title":94,"description":95,"date":96},"/doc/verified-boot-patterns-uboot-keys-failure-modes","Verified Boot Patterns in U-Boot: What to Verify, Where Keys Live, and Failure Modes","Deep dive into U-Boot verified boot patterns covering signature scopes, key storage options, common failure modes, and practical debugging techniques for embedded Linux platforms.","2026-03-16T18:11:00Z",{"_path":98,"title":99,"description":100},"/image-manifest","ProteanOS Image Manifest","This document lists all hero and supporting images needed for the website.",{"_path":93,"_dir":102,"_draft":103,"_partial":103,"_locale":104,"title":94,"description":95,"date":96,"lastmod":96,"draft":103,"hero":105,"tags":106,"category":102,"body":110,"_type":606,"_id":607,"_source":608,"_file":609,"_stem":610,"_extension":611},"doc",false,"","/images/hero/verified-boot-patterns-uboot-keys-failure-modes-1600x900.jpg",[107,108,109],"Embedded Linux","ProteanOS","Security",{"type":111,"children":112,"toc":577},"root",[113,121,128,133,140,145,150,156,161,175,181,186,192,197,202,208,213,218,224,229,234,240,245,251,257,279,285,298,304,317,331,352,358,363,369,374,380,393,418,423,429,496,502,507,512,530,535,541,561,566,572],{"type":114,"tag":115,"props":116,"children":117},"element","p",{},[118],{"type":119,"value":120},"text","Verified boot in U-Boot goes beyond signing a kernel image. The practical challenge is deciding what to verify, where to store keys so they survive updates, and how to handle the failure modes that appear in real deployments. This guide covers the patterns that work in production and the anti-patterns that cause field failures.",{"type":114,"tag":122,"props":123,"children":125},"h2",{"id":124},"verification-scope-what-gets-signed",[126],{"type":119,"value":127},"Verification scope: what gets signed",{"type":114,"tag":115,"props":129,"children":130},{},[131],{"type":119,"value":132},"U-Boot's FIT signature mechanism can sign individual images (kernel, DTB, initramfs) or configurations (the combination of images for a specific boot scenario). The choice has security implications.",{"type":114,"tag":134,"props":135,"children":137},"h3",{"id":136},"image-level-signing",[138],{"type":119,"value":139},"Image-level signing",{"type":114,"tag":115,"props":141,"children":142},{},[143],{"type":119,"value":144},"Each image node in the FIT has its own signature. This allows mixing and matching signed components. For example, you could update the device tree without re-signing the kernel.",{"type":114,"tag":115,"props":146,"children":147},{},[148],{"type":119,"value":149},"The risk: if an attacker can combine a signed old kernel with a signed old DTB that has different security settings (debug UART enabled, for instance), they can downgrade the device's security posture without breaking any individual signature.",{"type":114,"tag":134,"props":151,"children":153},{"id":152},"configuration-level-signing-recommended",[154],{"type":119,"value":155},"Configuration-level signing (recommended)",{"type":114,"tag":115,"props":157,"children":158},{},[159],{"type":119,"value":160},"The configuration node ties specific images together and signs the combination. You cannot swap a kernel version without re-signing the entire configuration. This is more restrictive but more secure.",{"type":114,"tag":115,"props":162,"children":163},{},[164,166,173],{"type":119,"value":165},"For the ",{"type":114,"tag":167,"props":168,"children":170},"a",{"href":169},"/doc/secure-boot-uboot-fit-signatures-chain-of-trust/",[171],{"type":119,"value":172},"secure boot walkthrough",{"type":119,"value":174},", configuration-level signing is the recommended pattern.",{"type":114,"tag":122,"props":176,"children":178},{"id":177},"where-keys-live",[179],{"type":119,"value":180},"Where keys live",{"type":114,"tag":115,"props":182,"children":183},{},[184],{"type":119,"value":185},"The public key for verification must be accessible to U-Boot before it verifies anything. There are several storage patterns, each with trade-offs.",{"type":114,"tag":134,"props":187,"children":189},{"id":188},"embedded-in-u-boot-dtb-most-common",[190],{"type":119,"value":191},"Embedded in U-Boot DTB (most common)",{"type":114,"tag":115,"props":193,"children":194},{},[195],{"type":119,"value":196},"The public key is compiled directly into U-Boot's device tree blob. This is simple and reliable: the key is always available because it is part of U-Boot itself.",{"type":114,"tag":115,"props":198,"children":199},{},[200],{"type":119,"value":201},"Limitation: updating the key requires updating U-Boot. This is acceptable if your update mechanism can update the bootloader, but some products lock down the bootloader early and never update it.",{"type":114,"tag":134,"props":203,"children":205},{"id":204},"in-a-dedicated-key-partition",[206],{"type":119,"value":207},"In a dedicated key partition",{"type":114,"tag":115,"props":209,"children":210},{},[211],{"type":119,"value":212},"Store the public key in a separate flash partition that U-Boot reads during boot. This allows key rotation without reflashing U-Boot.",{"type":114,"tag":115,"props":214,"children":215},{},[216],{"type":119,"value":217},"Risk: the key partition itself becomes a target. It must be protected against unauthorized writes (e.g., by hardware write protection or by signing the key partition with a root key embedded in ROM).",{"type":114,"tag":134,"props":219,"children":221},{"id":220},"in-one-time-programmable-otp-fuses",[222],{"type":119,"value":223},"In one-time-programmable (OTP) fuses",{"type":114,"tag":115,"props":225,"children":226},{},[227],{"type":119,"value":228},"Some SoCs provide OTP fuse banks where a hash of the public key can be permanently written. U-Boot reads the key from flash but verifies its hash against the fused value. This provides a hardware root of trust.",{"type":114,"tag":115,"props":230,"children":231},{},[232],{"type":119,"value":233},"This is the most secure option but is irreversible. A wrong fuse write bricks the device permanently for secure boot purposes. Test thoroughly on development boards before fusing production units.",{"type":114,"tag":134,"props":235,"children":237},{"id":236},"in-the-soc-rom-boot-chain",[238],{"type":119,"value":239},"In the SoC ROM boot chain",{"type":114,"tag":115,"props":241,"children":242},{},[243],{"type":119,"value":244},"Some SoCs (NXP i.MX, TI AM64x, STM32MP1) have ROM bootloaders that verify the first-stage bootloader using keys stored in OTP fuses. U-Boot SPL is verified by ROM; U-Boot proper is verified by SPL; the FIT image is verified by U-Boot proper. This creates a complete hardware-rooted chain of trust.",{"type":114,"tag":122,"props":246,"children":248},{"id":247},"common-failure-modes",[249],{"type":119,"value":250},"Common failure modes",{"type":114,"tag":134,"props":252,"children":254},{"id":253},"_1-signature-algorithm-mismatch",[255],{"type":119,"value":256},"1. Signature algorithm mismatch",{"type":114,"tag":115,"props":258,"children":259},{},[260,262,269,271,277],{"type":119,"value":261},"The ",{"type":114,"tag":263,"props":264,"children":266},"code",{"className":265},[],[267],{"type":119,"value":268},".its",{"type":119,"value":270}," file specifies ",{"type":114,"tag":263,"props":272,"children":274},{"className":273},[],[275],{"type":119,"value":276},"sha256,rsa4096",{"type":119,"value":278}," but the key was generated as RSA-2048. U-Boot silently fails to find a matching key and reports verification failure. Always verify the key size matches the algorithm string in both the ITS and the U-Boot key node.",{"type":114,"tag":134,"props":280,"children":282},{"id":281},"_2-dtb-size-overflow",[283],{"type":119,"value":284},"2. DTB size overflow",{"type":114,"tag":115,"props":286,"children":287},{},[288,290,296],{"type":119,"value":289},"When ",{"type":114,"tag":263,"props":291,"children":293},{"className":292},[],[294],{"type":119,"value":295},"mkimage",{"type":119,"value":297}," embeds the public key into U-Boot's DTB, the DTB grows. If the DTB partition or memory allocation is too small, the key write silently truncates. U-Boot then cannot find the key. Reserve at least 8 KB extra in the DTB allocation for RSA-4096 keys.",{"type":114,"tag":134,"props":299,"children":301},{"id":300},"_3-legacy-image-format-fallback",[302],{"type":119,"value":303},"3. Legacy image format fallback",{"type":114,"tag":115,"props":305,"children":306},{},[307,309,315],{"type":119,"value":308},"If ",{"type":114,"tag":263,"props":310,"children":312},{"className":311},[],[313],{"type":119,"value":314},"CONFIG_IMAGE_FORMAT_LEGACY=y",{"type":119,"value":316}," is enabled, an attacker can bypass FIT verification by presenting a legacy uImage. U-Boot will happily boot it without checking any signatures. Always disable legacy image format in secure boot configurations.",{"type":114,"tag":134,"props":318,"children":320},{"id":319},"_4-missing-required-property",[321,323,329],{"type":119,"value":322},"4. Missing ",{"type":114,"tag":263,"props":324,"children":326},{"className":325},[],[327],{"type":119,"value":328},"required",{"type":119,"value":330}," property",{"type":114,"tag":115,"props":332,"children":333},{},[334,336,342,344,350],{"type":119,"value":335},"If the key node does not include ",{"type":114,"tag":263,"props":337,"children":339},{"className":338},[],[340],{"type":119,"value":341},"required = \"conf\"",{"type":119,"value":343}," or ",{"type":114,"tag":263,"props":345,"children":347},{"className":346},[],[348],{"type":119,"value":349},"required = \"image\"",{"type":119,"value":351},", signature verification is advisory only. U-Boot prints warnings but still boots unsigned images. This is the single most common secure boot misconfiguration.",{"type":114,"tag":134,"props":353,"children":355},{"id":354},"_5-fit-image-corruption-during-ota",[356],{"type":119,"value":357},"5. FIT image corruption during OTA",{"type":114,"tag":115,"props":359,"children":360},{},[361],{"type":119,"value":362},"A partially written FIT image during an OTA update produces an invalid FIT structure. U-Boot cannot parse it and may fall through to a recovery path or hang. The OTA update documentation covers atomic update patterns that prevent this scenario.",{"type":114,"tag":134,"props":364,"children":366},{"id":365},"_6-clock-drift-affecting-timestamp-verification",[367],{"type":119,"value":368},"6. Clock drift affecting timestamp verification",{"type":114,"tag":115,"props":370,"children":371},{},[372],{"type":119,"value":373},"Some U-Boot configurations include timestamp verification. If the RTC battery dies or the device has no RTC, time-based verification fails spuriously. Either use a reliable time source or avoid timestamp-based checks on embedded devices.",{"type":114,"tag":122,"props":375,"children":377},{"id":376},"debugging-verified-boot-failures",[378],{"type":119,"value":379},"Debugging verified boot failures",{"type":114,"tag":115,"props":381,"children":382},{},[383,385,391],{"type":119,"value":384},"When signature verification fails, U-Boot's default error messages are terse. Enable ",{"type":114,"tag":263,"props":386,"children":388},{"className":387},[],[389],{"type":119,"value":390},"CONFIG_FIT_VERBOSE=y",{"type":119,"value":392}," to get detailed output including:",{"type":114,"tag":394,"props":395,"children":396},"ul",{},[397,403,408,413],{"type":114,"tag":398,"props":399,"children":400},"li",{},[401],{"type":119,"value":402},"Which key was attempted",{"type":114,"tag":398,"props":404,"children":405},{},[406],{"type":119,"value":407},"The computed hash value",{"type":114,"tag":398,"props":409,"children":410},{},[411],{"type":119,"value":412},"The expected hash value",{"type":114,"tag":398,"props":414,"children":415},{},[416],{"type":119,"value":417},"Which image or configuration failed",{"type":114,"tag":115,"props":419,"children":420},{},[421],{"type":119,"value":422},"For development, add a serial console to capture boot logs. On production devices, store verification failure logs in a persistent partition for later retrieval.",{"type":114,"tag":134,"props":424,"children":426},{"id":425},"step-by-step-debug-process",[427],{"type":119,"value":428},"Step-by-step debug process",{"type":114,"tag":430,"props":431,"children":432},"ol",{},[433,452,469,479],{"type":114,"tag":398,"props":434,"children":435},{},[436,442,444,450],{"type":114,"tag":437,"props":438,"children":439},"strong",{},[440],{"type":119,"value":441},"Verify the FIT image is intact:",{"type":119,"value":443}," ",{"type":114,"tag":263,"props":445,"children":447},{"className":446},[],[448],{"type":119,"value":449},"dumpimage -l fitImage",{"type":119,"value":451}," on the host should show all images and configurations with correct hash values.",{"type":114,"tag":398,"props":453,"children":454},{},[455,460,461,467],{"type":114,"tag":437,"props":456,"children":457},{},[458],{"type":119,"value":459},"Verify the key is present in U-Boot DTB:",{"type":119,"value":443},{"type":114,"tag":263,"props":462,"children":464},{"className":463},[],[465],{"type":119,"value":466},"fdtdump u-boot.dtb | grep -A 20 signature",{"type":119,"value":468}," should show the public key data.",{"type":114,"tag":398,"props":470,"children":471},{},[472,477],{"type":114,"tag":437,"props":473,"children":474},{},[475],{"type":119,"value":476},"Verify algorithm alignment:",{"type":119,"value":478}," The algorithm string in the FIT configuration's signature node must match the algorithm string in the U-Boot DTB key node.",{"type":114,"tag":398,"props":480,"children":481},{},[482,487,488,494],{"type":114,"tag":437,"props":483,"children":484},{},[485],{"type":119,"value":486},"Try signing and verifying on the host:",{"type":119,"value":443},{"type":114,"tag":263,"props":489,"children":491},{"className":490},[],[492],{"type":119,"value":493},"mkimage -F -k /path/to/keys -K u-boot.dtb -r fitImage",{"type":119,"value":495}," should succeed. If it fails on the host, it will fail on target.",{"type":114,"tag":122,"props":497,"children":499},{"id":498},"anti-rollback-protection",[500],{"type":119,"value":501},"Anti-rollback protection",{"type":114,"tag":115,"props":503,"children":504},{},[505],{"type":119,"value":506},"Signing prevents tampering but not rollback. An attacker with physical access can flash an older, signed image that has known vulnerabilities. Anti-rollback protection uses a monotonic counter (typically stored in OTP fuses) that increments with each firmware version. U-Boot refuses to boot images with a counter value lower than the fused minimum.",{"type":114,"tag":115,"props":508,"children":509},{},[510],{"type":119,"value":511},"Implementation:",{"type":114,"tag":430,"props":513,"children":514},{},[515,520,525],{"type":114,"tag":398,"props":516,"children":517},{},[518],{"type":119,"value":519},"Include a version counter in the FIT configuration",{"type":114,"tag":398,"props":521,"children":522},{},[523],{"type":119,"value":524},"Store the minimum acceptable counter in OTP fuses",{"type":114,"tag":398,"props":526,"children":527},{},[528],{"type":119,"value":529},"After successful boot, increment the fused counter",{"type":114,"tag":115,"props":531,"children":532},{},[533],{"type":119,"value":534},"This is irreversible by design. A failed update that increments the counter before verifying the new image can brick the device. Only increment after the new image has been fully validated.",{"type":114,"tag":122,"props":536,"children":538},{"id":537},"integration-with-proteanos",[539],{"type":119,"value":540},"Integration with ProteanOS",{"type":114,"tag":115,"props":542,"children":543},{},[544,546,552,554,559],{"type":119,"value":545},"ProteanOS build workflows generate FIT images as part of the ",{"type":114,"tag":167,"props":547,"children":549},{"href":548},"/dev/prokit/",[550],{"type":119,"value":551},"ProKit",{"type":119,"value":553}," build process. The signing step is integrated into the build pipeline: keys are stored in a protected CI variable, and ",{"type":114,"tag":263,"props":555,"children":557},{"className":556},[],[558],{"type":119,"value":295},{"type":119,"value":560}," signs the FIT image as the final build step.",{"type":114,"tag":115,"props":562,"children":563},{},[564],{"type":119,"value":565},"For platform bring-up, the board bring-up documentation includes verified boot as a milestone after basic boot is working. Get unsigned boot stable first, then add verification.",{"type":114,"tag":122,"props":567,"children":569},{"id":568},"summary",[570],{"type":119,"value":571},"Summary",{"type":114,"tag":115,"props":573,"children":574},{},[575],{"type":119,"value":576},"Verified boot in U-Boot is straightforward to set up but has failure modes that only appear in production scenarios. Sign at the configuration level, disable legacy image format, mark keys as required, and test failure paths as thoroughly as success paths. Plan for key rotation and anti-rollback from the start—retrofitting them is significantly harder than including them in the initial design.",{"title":104,"searchDepth":578,"depth":578,"links":579},2,[580,585,591,600,603,604,605],{"id":124,"depth":578,"text":127,"children":581},[582,584],{"id":136,"depth":583,"text":139},3,{"id":152,"depth":583,"text":155},{"id":177,"depth":578,"text":180,"children":586},[587,588,589,590],{"id":188,"depth":583,"text":191},{"id":204,"depth":583,"text":207},{"id":220,"depth":583,"text":223},{"id":236,"depth":583,"text":239},{"id":247,"depth":578,"text":250,"children":592},[593,594,595,596,598,599],{"id":253,"depth":583,"text":256},{"id":281,"depth":583,"text":284},{"id":300,"depth":583,"text":303},{"id":319,"depth":583,"text":597},"4. Missing required property",{"id":354,"depth":583,"text":357},{"id":365,"depth":583,"text":368},{"id":376,"depth":578,"text":379,"children":601},[602],{"id":425,"depth":583,"text":428},{"id":498,"depth":578,"text":501},{"id":537,"depth":578,"text":540},{"id":568,"depth":578,"text":571},"markdown","content:doc:verified-boot-patterns-uboot-keys-failure-modes.md","content","doc/verified-boot-patterns-uboot-keys-failure-modes.md","doc/verified-boot-patterns-uboot-keys-failure-modes","md",1791796266079]