[{"data":1,"prerenderedAt":938},["ShallowReactive",2],{"search-index":3,"doc-rootfs-integrity-dm-verity-immutable-images":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":78,"_dir":102,"_draft":103,"_partial":103,"_locale":104,"title":79,"description":80,"date":81,"lastmod":81,"draft":103,"hero":105,"tags":106,"category":102,"body":110,"_type":932,"_id":933,"_source":934,"_file":935,"_stem":936,"_extension":937},"doc",false,"","/images/hero/rootfs-integrity-dm-verity-immutable-images-1600x900.jpg",[107,108,109],"Embedded Linux","ProteanOS","Security",{"type":111,"children":112,"toc":913},"root",[113,121,128,142,147,172,177,183,188,233,238,244,258,360,365,371,376,384,413,461,466,472,477,575,580,586,591,624,630,635,640,647,652,660,666,671,728,734,739,745,750,773,778,784,789,832,837,843,848,853,859,872,878,891,896,902,907],{"type":114,"tag":115,"props":116,"children":117},"element","p",{},[118],{"type":119,"value":120},"text","dm-verity provides transparent block-level integrity verification for read-only filesystems. Every block read from disk is checked against a pre-computed hash tree. If a block has been modified—whether by an attacker, bit rot, or a failed flash write—the read returns an error instead of corrupted data. For embedded devices with immutable system partitions, dm-verity closes the gap between secure boot and runtime integrity.",{"type":114,"tag":122,"props":123,"children":125},"h2",{"id":124},"where-dm-verity-fits-in-the-security-chain",[126],{"type":119,"value":127},"Where dm-verity fits in the security chain",{"type":114,"tag":115,"props":129,"children":130},{},[131,133,140],{"type":119,"value":132},"Secure boot (covered in the ",{"type":114,"tag":134,"props":135,"children":137},"a",{"href":136},"/doc/secure-boot-uboot-fit-signatures-chain-of-trust/",[138],{"type":119,"value":139},"FIT signatures guide",{"type":119,"value":141},") verifies the kernel and initramfs at boot time. But once the kernel is running and mounts the root filesystem, there is no ongoing verification of the blocks read from storage—unless you add it.",{"type":114,"tag":115,"props":143,"children":144},{},[145],{"type":119,"value":146},"dm-verity provides that ongoing verification. The chain becomes:",{"type":114,"tag":148,"props":149,"children":150},"ol",{},[151,157,162,167],{"type":114,"tag":152,"props":153,"children":154},"li",{},[155],{"type":119,"value":156},"ROM → verifies SPL",{"type":114,"tag":152,"props":158,"children":159},{},[160],{"type":119,"value":161},"SPL → verifies U-Boot",{"type":114,"tag":152,"props":163,"children":164},{},[165],{"type":119,"value":166},"U-Boot → verifies kernel + initramfs (FIT signature)",{"type":114,"tag":152,"props":168,"children":169},{},[170],{"type":119,"value":171},"Kernel → verifies root filesystem blocks (dm-verity)",{"type":114,"tag":115,"props":173,"children":174},{},[175],{"type":119,"value":176},"With all four stages in place, every piece of software running on the device has been cryptographically verified.",{"type":114,"tag":122,"props":178,"children":180},{"id":179},"how-dm-verity-works",[181],{"type":119,"value":182},"How dm-verity works",{"type":114,"tag":115,"props":184,"children":185},{},[186],{"type":119,"value":187},"dm-verity uses a Merkle tree (hash tree) computed over the filesystem image. The tree structure:",{"type":114,"tag":189,"props":190,"children":191},"ul",{},[192,203,213,223],{"type":114,"tag":152,"props":193,"children":194},{},[195,201],{"type":114,"tag":196,"props":197,"children":198},"strong",{},[199],{"type":119,"value":200},"Data blocks:",{"type":119,"value":202}," The actual filesystem content, divided into fixed-size blocks (typically 4096 bytes)",{"type":114,"tag":152,"props":204,"children":205},{},[206,211],{"type":114,"tag":196,"props":207,"children":208},{},[209],{"type":119,"value":210},"Hash blocks:",{"type":119,"value":212}," Each hash block contains the hashes of multiple data blocks",{"type":114,"tag":152,"props":214,"children":215},{},[216,221],{"type":114,"tag":196,"props":217,"children":218},{},[219],{"type":119,"value":220},"Higher-level hash blocks:",{"type":119,"value":222}," Each higher level hashes the blocks below it",{"type":114,"tag":152,"props":224,"children":225},{},[226,231],{"type":114,"tag":196,"props":227,"children":228},{},[229],{"type":119,"value":230},"Root hash:",{"type":119,"value":232}," A single hash at the top of the tree",{"type":114,"tag":115,"props":234,"children":235},{},[236],{"type":119,"value":237},"The root hash is the trust anchor. If you know the root hash is correct (because it was signed or embedded in the verified kernel command line), dm-verity can verify every block on demand.",{"type":114,"tag":122,"props":239,"children":241},{"id":240},"generating-the-hash-tree",[242],{"type":119,"value":243},"Generating the hash tree",{"type":114,"tag":115,"props":245,"children":246},{},[247,249,256],{"type":119,"value":248},"Use ",{"type":114,"tag":250,"props":251,"children":253},"code",{"className":252},[],[254],{"type":119,"value":255},"veritysetup",{"type":119,"value":257}," from the cryptsetup package:",{"type":114,"tag":259,"props":260,"children":264},"pre",{"code":261,"language":262,"meta":104,"className":263,"style":104},"# Create the hash tree\nveritysetup format /path/to/rootfs.img /path/to/rootfs.hashtree\n\n# Output includes:\n# Root hash: 4a2c...\n# Salt: 8b1f...\n# Data blocks: 65536\n# Hash algorithm: sha256\n","bash","language-bash shiki shiki-themes github-dark",[265],{"type":114,"tag":250,"props":266,"children":267},{"__ignoreMap":104},[268,280,305,315,324,333,342,351],{"type":114,"tag":269,"props":270,"children":273},"span",{"class":271,"line":272},"line",1,[274],{"type":114,"tag":269,"props":275,"children":277},{"style":276},"--shiki-default:#6A737D",[278],{"type":119,"value":279},"# Create the hash tree\n",{"type":114,"tag":269,"props":281,"children":283},{"class":271,"line":282},2,[284,289,295,300],{"type":114,"tag":269,"props":285,"children":287},{"style":286},"--shiki-default:#B392F0",[288],{"type":119,"value":255},{"type":114,"tag":269,"props":290,"children":292},{"style":291},"--shiki-default:#9ECBFF",[293],{"type":119,"value":294}," format",{"type":114,"tag":269,"props":296,"children":297},{"style":291},[298],{"type":119,"value":299}," /path/to/rootfs.img",{"type":114,"tag":269,"props":301,"children":302},{"style":291},[303],{"type":119,"value":304}," /path/to/rootfs.hashtree\n",{"type":114,"tag":269,"props":306,"children":308},{"class":271,"line":307},3,[309],{"type":114,"tag":269,"props":310,"children":312},{"emptyLinePlaceholder":311},true,[313],{"type":119,"value":314},"\n",{"type":114,"tag":269,"props":316,"children":318},{"class":271,"line":317},4,[319],{"type":114,"tag":269,"props":320,"children":321},{"style":276},[322],{"type":119,"value":323},"# Output includes:\n",{"type":114,"tag":269,"props":325,"children":327},{"class":271,"line":326},5,[328],{"type":114,"tag":269,"props":329,"children":330},{"style":276},[331],{"type":119,"value":332},"# Root hash: 4a2c...\n",{"type":114,"tag":269,"props":334,"children":336},{"class":271,"line":335},6,[337],{"type":114,"tag":269,"props":338,"children":339},{"style":276},[340],{"type":119,"value":341},"# Salt: 8b1f...\n",{"type":114,"tag":269,"props":343,"children":345},{"class":271,"line":344},7,[346],{"type":114,"tag":269,"props":347,"children":348},{"style":276},[349],{"type":119,"value":350},"# Data blocks: 65536\n",{"type":114,"tag":269,"props":352,"children":354},{"class":271,"line":353},8,[355],{"type":114,"tag":269,"props":356,"children":357},{"style":276},[358],{"type":119,"value":359},"# Hash algorithm: sha256\n",{"type":114,"tag":115,"props":361,"children":362},{},[363],{"type":119,"value":364},"The root hash and salt must be recorded and passed to the kernel at boot time. Store them in the FIT image configuration or in the kernel command line.",{"type":114,"tag":122,"props":366,"children":368},{"id":367},"kernel-command-line-integration",[369],{"type":119,"value":370},"Kernel command line integration",{"type":114,"tag":115,"props":372,"children":373},{},[374],{"type":119,"value":375},"The simplest approach passes verity parameters on the kernel command line:",{"type":114,"tag":259,"props":377,"children":379},{"code":378},"root=/dev/dm-0\ndm-mod.create=\"verity,,,ro,0 524288 verity 1 /dev/mmcblk0p2 /dev/mmcblk0p3 4096 4096 65536 1 sha256 ROOT_HASH SALT\"\n",[380],{"type":114,"tag":250,"props":381,"children":382},{"__ignoreMap":104},[383],{"type":119,"value":378},{"type":114,"tag":115,"props":385,"children":386},{},[387,389,395,397,403,405,411],{"type":119,"value":388},"Replace ",{"type":114,"tag":250,"props":390,"children":392},{"className":391},[],[393],{"type":119,"value":394},"ROOT_HASH",{"type":119,"value":396}," and ",{"type":114,"tag":250,"props":398,"children":400},{"className":399},[],[401],{"type":119,"value":402},"SALT",{"type":119,"value":404}," with the values from ",{"type":114,"tag":250,"props":406,"children":408},{"className":407},[],[409],{"type":119,"value":410},"veritysetup format",{"type":119,"value":412},". The command line parameters specify:",{"type":114,"tag":189,"props":414,"children":415},{},[416,429,441,446,451,456],{"type":114,"tag":152,"props":417,"children":418},{},[419,421,427],{"type":119,"value":420},"The data device (",{"type":114,"tag":250,"props":422,"children":424},{"className":423},[],[425],{"type":119,"value":426},"/dev/mmcblk0p2",{"type":119,"value":428},")",{"type":114,"tag":152,"props":430,"children":431},{},[432,434,440],{"type":119,"value":433},"The hash device (",{"type":114,"tag":250,"props":435,"children":437},{"className":436},[],[438],{"type":119,"value":439},"/dev/mmcblk0p3",{"type":119,"value":428},{"type":114,"tag":152,"props":442,"children":443},{},[444],{"type":119,"value":445},"Block sizes (data and hash)",{"type":114,"tag":152,"props":447,"children":448},{},[449],{"type":119,"value":450},"Number of data blocks",{"type":114,"tag":152,"props":452,"children":453},{},[454],{"type":119,"value":455},"Hash algorithm",{"type":114,"tag":152,"props":457,"children":458},{},[459],{"type":119,"value":460},"Root hash and salt",{"type":114,"tag":115,"props":462,"children":463},{},[464],{"type":119,"value":465},"Since the kernel command line is part of the signed FIT image, the root hash is protected by the secure boot chain.",{"type":114,"tag":122,"props":467,"children":469},{"id":468},"initramfs-based-setup-recommended",[470],{"type":119,"value":471},"Initramfs-based setup (recommended)",{"type":114,"tag":115,"props":473,"children":474},{},[475],{"type":119,"value":476},"For more flexibility, set up dm-verity in the initramfs:",{"type":114,"tag":259,"props":478,"children":480},{"code":479,"language":262,"meta":104,"className":263,"style":104},"#!/bin/sh\n# In init script\nveritysetup open /dev/mmcblk0p2 rootfs /dev/mmcblk0p3 ${ROOT_HASH}\nmount /dev/mapper/rootfs /newroot\nexec switch_root /newroot /sbin/init\n",[481],{"type":114,"tag":250,"props":482,"children":483},{"__ignoreMap":104},[484,492,500,533,551],{"type":114,"tag":269,"props":485,"children":486},{"class":271,"line":272},[487],{"type":114,"tag":269,"props":488,"children":489},{"style":276},[490],{"type":119,"value":491},"#!/bin/sh\n",{"type":114,"tag":269,"props":493,"children":494},{"class":271,"line":282},[495],{"type":114,"tag":269,"props":496,"children":497},{"style":276},[498],{"type":119,"value":499},"# In init script\n",{"type":114,"tag":269,"props":501,"children":502},{"class":271,"line":307},[503,507,512,517,522,527],{"type":114,"tag":269,"props":504,"children":505},{"style":286},[506],{"type":119,"value":255},{"type":114,"tag":269,"props":508,"children":509},{"style":291},[510],{"type":119,"value":511}," open",{"type":114,"tag":269,"props":513,"children":514},{"style":291},[515],{"type":119,"value":516}," /dev/mmcblk0p2",{"type":114,"tag":269,"props":518,"children":519},{"style":291},[520],{"type":119,"value":521}," rootfs",{"type":114,"tag":269,"props":523,"children":524},{"style":291},[525],{"type":119,"value":526}," /dev/mmcblk0p3",{"type":114,"tag":269,"props":528,"children":530},{"style":529},"--shiki-default:#E1E4E8",[531],{"type":119,"value":532}," ${ROOT_HASH}\n",{"type":114,"tag":269,"props":534,"children":535},{"class":271,"line":317},[536,541,546],{"type":114,"tag":269,"props":537,"children":538},{"style":286},[539],{"type":119,"value":540},"mount",{"type":114,"tag":269,"props":542,"children":543},{"style":291},[544],{"type":119,"value":545}," /dev/mapper/rootfs",{"type":114,"tag":269,"props":547,"children":548},{"style":291},[549],{"type":119,"value":550}," /newroot\n",{"type":114,"tag":269,"props":552,"children":553},{"class":271,"line":326},[554,560,565,570],{"type":114,"tag":269,"props":555,"children":557},{"style":556},"--shiki-default:#79B8FF",[558],{"type":119,"value":559},"exec",{"type":114,"tag":269,"props":561,"children":562},{"style":291},[563],{"type":119,"value":564}," switch_root",{"type":114,"tag":269,"props":566,"children":567},{"style":291},[568],{"type":119,"value":569}," /newroot",{"type":114,"tag":269,"props":571,"children":572},{"style":291},[573],{"type":119,"value":574}," /sbin/init\n",{"type":114,"tag":115,"props":576,"children":577},{},[578],{"type":119,"value":579},"This approach allows error handling, fallback logic, and logging before the root filesystem is mounted.",{"type":114,"tag":122,"props":581,"children":583},{"id":582},"filesystem-choices-for-dm-verity",[584],{"type":119,"value":585},"Filesystem choices for dm-verity",{"type":114,"tag":115,"props":587,"children":588},{},[589],{"type":119,"value":590},"dm-verity requires a read-only filesystem. Common choices:",{"type":114,"tag":189,"props":592,"children":593},{},[594,604,614],{"type":114,"tag":152,"props":595,"children":596},{},[597,602],{"type":114,"tag":196,"props":598,"children":599},{},[600],{"type":119,"value":601},"SquashFS:",{"type":119,"value":603}," Compressed, widely supported, good tool ecosystem. Typical for embedded systems with flash storage constraints.",{"type":114,"tag":152,"props":605,"children":606},{},[607,612],{"type":114,"tag":196,"props":608,"children":609},{},[610],{"type":119,"value":611},"EROFS:",{"type":119,"value":613}," Enhanced Read-Only File System with better random-read performance. See the EROFS documentation for detailed benchmarks.",{"type":114,"tag":152,"props":615,"children":616},{},[617,622],{"type":114,"tag":196,"props":618,"children":619},{},[620],{"type":119,"value":621},"ext4 (read-only):",{"type":119,"value":623}," An ext4 image mounted read-only works with dm-verity but offers no compression. Useful when you need ext4 tooling compatibility.",{"type":114,"tag":122,"props":625,"children":627},{"id":626},"error-handling-strategies",[628],{"type":119,"value":629},"Error handling strategies",{"type":114,"tag":115,"props":631,"children":632},{},[633],{"type":119,"value":634},"When dm-verity detects a corrupted block, the default kernel behaviour is to return an I/O error to the reading process. This usually means the process crashes, which may leave the system in an unpredictable state.",{"type":114,"tag":115,"props":636,"children":637},{},[638],{"type":119,"value":639},"Better strategies:",{"type":114,"tag":641,"props":642,"children":644},"h3",{"id":643},"restart-mode",[645],{"type":119,"value":646},"Restart mode",{"type":114,"tag":115,"props":648,"children":649},{},[650],{"type":119,"value":651},"Configure dm-verity to trigger a kernel panic on corruption. Combined with a watchdog, this causes a reboot into a recovery partition:",{"type":114,"tag":259,"props":653,"children":655},{"code":654},"dm-verity.error_behavior=3  # panic\n",[656],{"type":114,"tag":250,"props":657,"children":658},{"__ignoreMap":104},[659],{"type":119,"value":654},{"type":114,"tag":641,"props":661,"children":663},{"id":662},"corruption-logging",[664],{"type":119,"value":665},"Corruption logging",{"type":114,"tag":115,"props":667,"children":668},{},[669],{"type":119,"value":670},"Log the corrupted block number to a persistent partition before rebooting. This helps diagnose whether the corruption is systematic (storage failure) or targeted (attack):",{"type":114,"tag":259,"props":672,"children":674},{"code":673,"language":262,"meta":104,"className":263,"style":104},"# In a verity error handler script\necho \"verity corruption at block ${BLOCK}\" >> /data/verity-errors.log\nreboot\n",[675],{"type":114,"tag":250,"props":676,"children":677},{"__ignoreMap":104},[678,686,720],{"type":114,"tag":269,"props":679,"children":680},{"class":271,"line":272},[681],{"type":114,"tag":269,"props":682,"children":683},{"style":276},[684],{"type":119,"value":685},"# In a verity error handler script\n",{"type":114,"tag":269,"props":687,"children":688},{"class":271,"line":282},[689,694,699,704,709,715],{"type":114,"tag":269,"props":690,"children":691},{"style":556},[692],{"type":119,"value":693},"echo",{"type":114,"tag":269,"props":695,"children":696},{"style":291},[697],{"type":119,"value":698}," \"verity corruption at block ${",{"type":114,"tag":269,"props":700,"children":701},{"style":529},[702],{"type":119,"value":703},"BLOCK",{"type":114,"tag":269,"props":705,"children":706},{"style":291},[707],{"type":119,"value":708},"}\"",{"type":114,"tag":269,"props":710,"children":712},{"style":711},"--shiki-default:#F97583",[713],{"type":119,"value":714}," >>",{"type":114,"tag":269,"props":716,"children":717},{"style":291},[718],{"type":119,"value":719}," /data/verity-errors.log\n",{"type":114,"tag":269,"props":721,"children":722},{"class":271,"line":307},[723],{"type":114,"tag":269,"props":724,"children":725},{"style":286},[726],{"type":119,"value":727},"reboot\n",{"type":114,"tag":641,"props":729,"children":731},{"id":730},"forward-error-correction",[732],{"type":119,"value":733},"Forward error correction",{"type":114,"tag":115,"props":735,"children":736},{},[737],{"type":119,"value":738},"dm-verity supports an optional FEC (Forward Error Correction) mode that can repair corrupted blocks using Reed-Solomon codes. This adds space overhead (typically 2–8% of the image size) but allows transparent recovery from minor storage corruption.",{"type":114,"tag":122,"props":740,"children":742},{"id":741},"update-strategies-with-dm-verity",[743],{"type":119,"value":744},"Update strategies with dm-verity",{"type":114,"tag":115,"props":746,"children":747},{},[748],{"type":119,"value":749},"Since dm-verity protects a read-only image, updates mean replacing the entire image and hash tree. This aligns naturally with A/B update schemes:",{"type":114,"tag":148,"props":751,"children":752},{},[753,758,763,768],{"type":114,"tag":152,"props":754,"children":755},{},[756],{"type":119,"value":757},"Download new rootfs image + hash tree to the inactive slot",{"type":114,"tag":152,"props":759,"children":760},{},[761],{"type":119,"value":762},"Verify the download integrity (checksum or signature)",{"type":114,"tag":152,"props":764,"children":765},{},[766],{"type":119,"value":767},"Update the boot configuration to point to the new slot",{"type":114,"tag":152,"props":769,"children":770},{},[771],{"type":119,"value":772},"Reboot",{"type":114,"tag":115,"props":774,"children":775},{},[776],{"type":119,"value":777},"The OTA update tooling documentation covers RAUC and SWUpdate integration with dm-verity-protected partitions.",{"type":114,"tag":122,"props":779,"children":781},{"id":780},"writable-overlay-for-runtime-data",[782],{"type":119,"value":783},"Writable overlay for runtime data",{"type":114,"tag":115,"props":785,"children":786},{},[787],{"type":119,"value":788},"A fully read-only root filesystem is impractical for most systems. Logs, configuration changes, and runtime state need writeable storage. The standard pattern is an overlayfs mount:",{"type":114,"tag":259,"props":790,"children":792},{"code":791,"language":262,"meta":104,"className":263,"style":104},"mount -t overlay overlay -o lowerdir=/rootfs,upperdir=/data/upper,workdir=/data/work /merged\n",[793],{"type":114,"tag":250,"props":794,"children":795},{"__ignoreMap":104},[796],{"type":114,"tag":269,"props":797,"children":798},{"class":271,"line":272},[799,803,808,813,817,822,827],{"type":114,"tag":269,"props":800,"children":801},{"style":286},[802],{"type":119,"value":540},{"type":114,"tag":269,"props":804,"children":805},{"style":556},[806],{"type":119,"value":807}," -t",{"type":114,"tag":269,"props":809,"children":810},{"style":291},[811],{"type":119,"value":812}," overlay",{"type":114,"tag":269,"props":814,"children":815},{"style":291},[816],{"type":119,"value":812},{"type":114,"tag":269,"props":818,"children":819},{"style":556},[820],{"type":119,"value":821}," -o",{"type":114,"tag":269,"props":823,"children":824},{"style":291},[825],{"type":119,"value":826}," lowerdir=/rootfs,upperdir=/data/upper,workdir=/data/work",{"type":114,"tag":269,"props":828,"children":829},{"style":291},[830],{"type":119,"value":831}," /merged\n",{"type":114,"tag":115,"props":833,"children":834},{},[835],{"type":119,"value":836},"The lower layer is the dm-verity-protected read-only image. The upper layer is on a separate, writable partition. Changes appear in the upper layer without modifying the verified lower layer.",{"type":114,"tag":122,"props":838,"children":840},{"id":839},"performance-considerations",[841],{"type":119,"value":842},"Performance considerations",{"type":114,"tag":115,"props":844,"children":845},{},[846],{"type":119,"value":847},"dm-verity adds overhead to every block read. On flash-based storage (eMMC, NAND), the overhead is typically 5–15% for sequential reads and negligible for cached reads. The hash tree is small enough to fit in page cache for most embedded images.",{"type":114,"tag":115,"props":849,"children":850},{},[851],{"type":119,"value":852},"For latency-sensitive applications, pre-populate the hash tree in page cache during boot by reading it sequentially before mounting.",{"type":114,"tag":122,"props":854,"children":856},{"id":855},"adoption-across-linux-distributions",[857],{"type":119,"value":858},"Adoption across Linux distributions",{"type":114,"tag":115,"props":860,"children":861},{},[862,864,870],{"type":119,"value":863},"dm-verity and immutable root filesystem patterns have become standard practice across modern Linux distributions. Distributions like ",{"type":114,"tag":134,"props":865,"children":867},{"href":866},"https://ubuntuportal.com/posts/ubuntu-2604-resolute-raccoon-features/",[868],{"type":119,"value":869},"Ubuntu Resolute Raccoon Features",{"type":119,"value":871}," are increasingly shipping with immutable filesystem tooling and secure boot integration, reflecting how these patterns have moved from specialist embedded systems into general-purpose Linux environments. Understanding how these approaches work—and where their constraints lie—helps portable OS projects make informed architectural decisions.",{"type":114,"tag":122,"props":873,"children":875},{"id":874},"integration-with-proteanos",[876],{"type":119,"value":877},"Integration with ProteanOS",{"type":114,"tag":115,"props":879,"children":880},{},[881,883,889],{"type":119,"value":882},"ProteanOS build workflows can integrate dm-verity hash tree generation as a post-build step. The ",{"type":114,"tag":134,"props":884,"children":886},{"href":885},"/dev/prokit/",[887],{"type":119,"value":888},"ProKit documentation",{"type":119,"value":890}," covers adding custom post-processing steps to the build pipeline.",{"type":114,"tag":115,"props":892,"children":893},{},[894],{"type":119,"value":895},"For new hardware platforms, the board bring-up documentation includes dm-verity validation as a security milestone after basic boot and secure boot are working.",{"type":114,"tag":122,"props":897,"children":899},{"id":898},"summary",[900],{"type":119,"value":901},"Summary",{"type":114,"tag":115,"props":903,"children":904},{},[905],{"type":119,"value":906},"dm-verity provides runtime integrity verification for read-only root filesystems. Combined with secure boot, it creates a complete chain of trust from power-on to application execution. The implementation involves generating a hash tree, passing the root hash through a verified channel (signed kernel command line or initramfs), and handling corruption gracefully. Plan your partition layout and update strategy around the read-only constraint from the start.",{"type":114,"tag":908,"props":909,"children":910},"style",{},[911],{"type":119,"value":912},"html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}",{"title":104,"searchDepth":282,"depth":282,"links":914},[915,916,917,918,919,920,921,926,927,928,929,930,931],{"id":124,"depth":282,"text":127},{"id":179,"depth":282,"text":182},{"id":240,"depth":282,"text":243},{"id":367,"depth":282,"text":370},{"id":468,"depth":282,"text":471},{"id":582,"depth":282,"text":585},{"id":626,"depth":282,"text":629,"children":922},[923,924,925],{"id":643,"depth":307,"text":646},{"id":662,"depth":307,"text":665},{"id":730,"depth":307,"text":733},{"id":741,"depth":282,"text":744},{"id":780,"depth":282,"text":783},{"id":839,"depth":282,"text":842},{"id":855,"depth":282,"text":858},{"id":874,"depth":282,"text":877},{"id":898,"depth":282,"text":901},"markdown","content:doc:rootfs-integrity-dm-verity-immutable-images.md","content","doc/rootfs-integrity-dm-verity-immutable-images.md","doc/rootfs-integrity-dm-verity-immutable-images","md",1791882668043]