Kung nag-aalala ka tungkol sa integridad ng iyong system, Ang dm-verity ay isa sa mga pangunahing bahagi ng Linux ecosystem upang ligtas na mag-boot at matukoy ang pakikialam sa imbakan. Nagmula ito bilang bahagi ng device mapper ng kernel at ngayon ang batayan para sa na-verify na pag-boot sa Android, OpenWrt, at mga distribusyon na naghahanap ng pinahusay na seguridad.
Malayo sa pagiging abstract na konsepto, Ang dm-verity ay na-configure at ginagamit sa mga totoong tool tulad ng veritysetup at systemd-veritysetupPinapatunayan nito ang mga bloke sa mabilisang paggamit ng mga hash tree at maaaring tumugon sa katiwalian gamit ang mga patakaran mula sa pag-log sa kaganapan hanggang sa pag-reboot o pag-crash sa system. Tingnan natin nang mas malapitan, nang hindi nag-iiwan ng anumang maluwag na dulo.
Ano ang dm-verity at kung bakit maaaring may pakialam ka
Ang dm-verity ay isang target na device-mapper sa kernel na bini-verify ang integridad ng isang block device habang binabasa ang dataGumagana ito sa pamamagitan ng pagkalkula at pag-verify ng mga hash ng bawat block (karaniwan ay 4K) laban sa isang pre-computed hash tree, karaniwang gumagamit ng SHA-256.
Ang disenyong ito ay nagbibigay-daan para sa Ang mga file ay hindi maaaring tahimik na mabago sa pagitan ng mga pag-reboot o sa panahon ng pagpapatupadIto ay susi sa pagpapalawak ng boot chain ng tiwala sa operating system, nililimitahan ang pagtitiyaga ng malware, pagpapalakas ng mga patakaran sa seguridad, at pagtiyak ng pag-encrypt at mga mekanismo ng MAC sa panahon ng boot.
Sa Android (mula noong 4.4) at Linux sa pangkalahatan, Ang tiwala ay nakaangkla sa root hash ng puno, na nilagdaan at na-validate gamit ang isang pampublikong key na matatagpuan sa isang protektadong lokasyon (hal., sa boot partition o sa isang Secure Boot-signed UKI). Ang pagsira sa anumang block ay mangangailangan ng pagsira sa pinagbabatayan na cryptographic hash.
Ang pag-verify ay ginagawa sa pamamagitan ng block at on demand: Ang idinagdag na latency ay minimal kumpara sa halaga ng I/OKung ang isang tseke ay nabigo, ang kernel ay nagbabalik ng isang I/O error at ang file system ay lilitaw na sira, na inaasahan kapag ang data ay hindi maaasahan. Maaaring magpasya ang mga app kung magpapatuloy o hindi batay sa kanilang pagpapahintulot sa kasalanan.
Paano gumagana ang verification tree sa loob
Ang verification tree ay binuo sa mga layer. Ang Layer 0 ay ang raw data mula sa device, na nahahati sa 4K na bloke; isang SHA-256 (salted) hash ang kinakalkula para sa bawat block. Ang mga hash na ito ay pagkatapos ay pinagsama-sama upang bumuo ng layer 1. Ang Layer 1 ay pagkatapos ay pinagsama-sama sa mga bloke at rehash upang bumuo ng layer 2, at iba pa hanggang ang lahat ay magkasya sa isang bloke: ang bloke na iyon, kapag na-hash, ay gumagawa ng root hash.
Kung ang anumang layer ay hindi eksaktong nakumpleto ang isang bloke, Ito ay nilagyan ng mga zero hanggang umabot sa 4K upang maiwasan ang kalabuan. Ang kabuuang sukat ng puno ay depende sa laki ng partisyon na sinusuri; sa pagsasagawa, ito ay karaniwang mas mababa sa 30 MB para sa karaniwang mga partition ng system.
Ang pangkalahatang proseso ay: pumili ng random na asin, hash hanggang 4K, kalkulahin ang SHA-256 na may per-block na asin, nagsasama-sama upang bumuo ng mga antas, pad ang hangganan ng block na may mga zero, at umuulit sa nakaraang antas hanggang sa isang solong root hash ay naiwan. Ang root hash na iyon, kasama ang asin na ginamit, ay nagpapakain sa dm-verity table at ang lagda.
Mga bersyon at algorithm ng format ng disk
Ang format ng mga hash block sa disk ay may bersyon. Ang Bersyon 0 ay ang orihinal na bersyon na ginamit sa Chromium OS: Ang asin ay idinagdag sa dulo ng proseso ng pag-hash, ang mga digest ay patuloy na iniimbak, at ang natitirang bahagi ng bloke ay nilagyan ng mga zero.
La Inirerekomenda ang Bersyon 1 para sa mga bagong device: Ang asin ay inilalagay sa hash, at ang bawat digest ay nilagyan ng mga zero hanggang sa dalawang kapangyarihan, na nagpapahusay sa pagkakahanay at tibay. Tinukoy din ng dm-verity table ang algorithm (hal., sha1 o sha256), bagama't para sa kasalukuyang seguridad, sha256 ang ginagamit.
dm-verity table at mahahalagang parameter
Inilalarawan ng target na talahanayan ang dm-verity kung nasaan ang data, nasaan ang hash tree, at kung paano i-verifyKaraniwang mga patlang ng talahanayan:
- dev: device na may data na ibe-verify (uri ng path /dev/sdXN o mas mataas:mas maliit).
- hash_dev: device na may hash tree (maaaring pareho; kung gayon, ang hash_start ay dapat nasa labas ng checked range).
- data_block_size: laki ng data block sa bytes (hal. 4096).
- hash_block_size: laki ng hash block sa bytes.
- num_data_blocks: bilang ng mga nabe-verify na bloke ng data.
- hash_start_block: offset (sa hash_block_size blocks) sa root block ng puno.
- algorithm: hash algorithm (hal. sha256).
- tumunaw: hexadecimal encoding ng root block hash (kabilang ang asin ayon sa bersyon ng format); ang halagang ito ang dapat pagkatiwalaan.
- asin: hexadecimal na asin.
Bilang karagdagan, mayroong opsyonal na mga parameter lubhang kapaki-pakinabang para sa pagsasaayos ng pag-uugali:
- huwag pansinin ang_katiwalian: Itinatala ang mga tiwaling bloke, ngunit pinapayagan ang pagbabasa na magpatuloy.
- restart_on_corruption: simulan muli sa pagtuklas ng katiwalian (hindi tugma sa ignore_corruption at nangangailangan ng suporta sa espasyo ng gumagamit upang maiwasan ang mga loop).
- panic_on_corruption: : nagdudulot ng gulat kapag nakakakita ng katiwalian (hindi tugma sa mga nakaraang bersyon).
- restart_on_error y panic_on_error: parehong mga reaksyon ngunit para sa mga error sa I/O.
- ignore_zero_blocks: hindi sinusuri ang mga bloke na inaasahan bilang mga zero at nagbabalik ng mga zero.
- use_fec_from_device + fec_roots + fec_blocks + fec_start: Paganahin ang Reed–Solomon (FEC) upang mabawi ang data kapag nabigo ang pag-verify; ang mga lugar ng data, hash, at FEC ay hindi dapat mag-overlap, at dapat tumugma ang mga laki ng block.
- suriin_sa_karamihan_isang beses: Sinusuri ang bawat bloke ng data sa unang pagkakataon lamang na basahin ito (binabawasan ang overhead sa halaga ng seguridad sa mga live na pag-atake).
- root_hash_sig_key_desc: Sanggunian sa isang susi sa keyring upang mapatunayan ang isang PKCS7 na lagda ng root hash kapag gumagawa ng pagmamapa (nangangailangan ng naaangkop na configuration ng kernel at pinagkakatiwalaang keyrings).
- try_verify_in_tasklet: Kung ang mga hash ay naka-cache at pinahihintulutan ang laki ng I/O, sinusuri ang bottom-half upang bawasan ang latency; inayos gamit ang /sys/module/dm_verity/parameters/use_bh_bytes bawat klase ng I/O.
Signature, metadata at trust anchoring
Para maging maaasahan ang dm-verity, Ang root hash ay dapat na pinagkakatiwalaan at karaniwang pinirmahanSa classic na Android, may kasamang pampublikong key sa boot partition, na panlabas na na-verify ng manufacturer; pinapatunayan nito ang lagda ng root hash at tinitiyak na hindi binago ang partition ng system.
Ang verity metadata ay nagdaragdag ng istraktura at kontrol sa bersyon. Ang metadata block ay may kasamang magic number na 0xb001b001 (bytes b0 01 b0 01), bersyon (kasalukuyang 0), ang lagda ng talahanayan sa PKCS1.5 (karaniwang 256 byte para sa RSA-2048), ang haba ng talahanayan, ang talahanayan mismo at zero padding hanggang 32K.
Sa mga pagpapatupad ng Android, umaasa ang pag-verify fs_mgr at fstab: Pagdaragdag ng check mark sa kaukulang entry at paglalagay ng key sa /boot/verity_key. Kung ang magic number ay wala kung saan ito dapat, hihinto ang pag-verify upang maiwasan ang pagsuri sa maling bagay.
Na-verify ang pagsisimula ng operasyon
Ang proteksyon ay nabubuhay sa kernel: Kung nakompromiso bago mag-boot ang kernel, mananatili ang kontrol ng umaatakeIyon ang dahilan kung bakit karaniwang mahigpit na pinapatunayan ng mga tagagawa ang bawat yugto: ang isang key na na-burn sa device ay nagve-verify sa unang bootloader, na nagbe-verify sa susunod, ang app bootloader, at panghuli, ang kernel.
Sa na-verify na kernel, Ang dm-verity ay pinagana kapag ini-mount ang na-verify na block deviceSa halip na i-hash ang buong device (na magiging mabagal at mag-aaksaya ng enerhiya), na-verify ito sa bawat bloke habang ina-access ito. Ang pagkabigo ay nagdudulot ng I/O error, at tumutugon ang mga serbisyo at app ayon sa kanilang pagpapaubaya: maaaring magpatuloy nang wala ang data na iyon o ganap na nag-crash.
Pagpasa ng Error Correction (FEC)
Mula noong Android 7.0, Ang FEC (Reed–Solomon) ay isinama sa mga interlacing technique upang bawasan ang espasyo at dagdagan ang kakayahang mabawi ang mga nasirang bloke. Gumagana ito kasabay ng dm-verity: kung nabigo ang isang tseke, maaaring subukan ng subsystem na itama ito bago ideklarang hindi ito mababawi.
Pagganap at pag-optimize
Para mabawasan ang epekto: Paganahin ang SHA-2 acceleration ng NEON sa ARMv7 at SHA-2 extension sa ARMv8 mula sa kernel. Isaayos ang read-ahead at prefetch_cluster na mga parameter para sa iyong hardware; Ang per-block na pag-verify ay kadalasang nagdaragdag ng kaunti sa halaga ng I/O, ngunit ang mga setting na ito ay may pagkakaiba.
Pagsisimula sa Linux (systemd, veritysetup) at Android
Sa isang modernong Linux na may systemd, Ang dm-verity ay nagbibigay-daan sa isang na-verify na read-only na ugat gamit ang veritysetup (bahagi ng cryptsetup), systemd-veritysetup.generator, at systemd-veritysetup@.service. Inirerekomenda na isama ang Secure Boot at isang nilagdaang UKI (unified kernel image), bagama't hindi ito mahigpit na kinakailangan.
Paghahanda at inirerekumendang paghahati
Bahagi ng isang functional at adjusted system. Magreserba ng volume para sa hash tree (8–10% ng sukat ng ugat ay karaniwang sapat) at isaalang-alang ang paghiwalayin ang /home at /var kung kailangan mong magsulat. Kasama sa karaniwang scheme ang: ESP (para sa bootloader), XBOOTLDR (para sa mga UKI), ugat (mayroon o walang encryption), VERITY partition, at opsyonal na /home at /var.
Bilang ugat, Ang EROFS ay isang napaka-interesante na alternatibo sa ext4 o squashfs: Ito ay read-only ayon sa disenyo, na may napakahusay na performance sa flash/SSD, lz4 compression bilang default, at malawakang ginagamit sa mga Android phone na may dm-verity.
Mga file na dapat maisulat
Sa root ro, ang ilang mga programa ay inaasahan na sumulat sa /etc o sa panahon ng initMaaari mo itong ilipat sa /var/etc at i-symlink ang anumang kailangang baguhin (hal., mga koneksyon sa NetworkManager sa /etc/NetworkManager/system-connections). Tandaan na ang systemd-journald ay nangangailangan ng /etc/machine-id na umiral sa root directory (hindi isang symlink) upang maiwasang masira ang mga maagang startup.
Upang malaman kung ano ang mga pagbabago sa pagpapatupad, gumamit ng dracut-overlayroot: nag-overlay ng tmpfs sa ugat, at lahat ng nakasulat ay lilitaw sa /run/overlayroot/u. Idagdag ang module sa /usr/lib/dracut/modules.d/, isama ang overlayroot sa dracut, at itakda ang overlayroot=1 sa kernel line; sa paraang ito makikita mo kung ano ang i-migrate sa /var.
Mga kapaki-pakinabang na halimbawa: pacman at NetworkManager
Sa Arch, ito ay maginhawa Ilipat ang database ng Pacman sa /usr/lib/pacman upang ang mga rootfs ay laging sumasalamin sa mga naka-install na pakete. Pagkatapos, i-redirect ang cache sa /var/lib/pacman at i-link. Upang baguhin ang mirrorlist nang hindi hinahawakan ang ugat, ilipat ito sa /var/etc at i-link pa rin ito.
Sa NetworkManager, ilipat ang mga koneksyon sa system sa /var/etc/NetworkManager at link mula sa /etc/NetworkManager/system-connections. Pinapanatili nitong hindi nababago ang ugat at nabubuhay ang configuration kung saan dapat itong maisulat.
Konstruksyon ng katotohanan at pagsubok
Mula sa isang live at sa lahat ng bagay na perpekto at naka-mount sa ro, lumikha ng puno at roothash na may veritysetup format: Kapag tumakbo, ito ay nagpi-print ng Root Hash line, na maaari mong i-save sa roothash.txt. Patakbuhin ito para sa pagsubok gamit ang veritysetup open root-device root verity-device $(cat roothash.txt) at i-mount /dev/mapper/root.
Kung gusto mo, unang bumubuo ng puno sa isang file (verity.bin) at pagkatapos ay isulat ito sa VERITY partition. Ang resultang set ay: root image, verity tree, at ang root hash na ipi-pin mo sa boot.
I-configure ang linya ng kernel
Idagdag ang mga parameter na ito: systemd.verity=1, roothash=contents_of_roothash.txt, systemd.verity_root_data=ROOT-PATH (hal. LABEL=OS), at systemd.verity_root_hash=VERITY-PATH (hal. LABEL=VERITY). Itakda ang systemd.verity_root_options na mag-restart-on-corruption o panic-on-corruption para sa mahigpit na patakaran.
Iba pang mga inirerekomendang opsyon: ro (kung hindi ka gumagamit ng EROFS/squashfs), rd.emergency=reboot y rd.shell=0 (iwasan ang mga hindi awtorisadong shell kung nabigo ang boot), at lockdown=kumpidensyal upang protektahan ang kernel memory mula sa pag-access.
Karagdagang mga partisyon nang may katotohanan
Hindi lamang ang ugat: Maaari mong tukuyin ang iba pang mga pagmamapa sa /etc/veritytab at systemd-veritysetup@.service ay bubuuin ang mga ito sa boot. Tandaan: mas madaling mag-mount ang RW ng non-root na partition, at maaaring i-disable ng root user ang Verity sa mga partition na iyon, kaya mas mababa ang security value doon.
Seguridad: Secure Boot, UKI at nilagdaang mga module
Ang dm-verity ay hindi isang pilak na bala. Lagdaan ang UKI at paganahin ang Secure Boot gamit ang sarili mong mga susi upang maiwasan ang sinuman na i-overriding ang kernel/initramfs/cmdline (na kinabibilangan ng root hash). Ang mga tool tulad ng sbupdate-git o sbctl ay nakakatulong na panatilihing naka-sign ang mga larawan at buo ang boot chain.
Kung pinagana mo ang kernel lockdown o module signature verification, Dapat pirmahan ang DKMS o out-of-tree modules o hindi sila maglo-load. Isaalang-alang ang isang custom na kernel na may suporta sa pag-sign para sa iyong pipeline (tingnan ang mga naka-sign na kernel module).
Pag-encrypt, TPM at pagsukat
pinoprotektahan ng dm-verity ang integridad, hindi kompidensyalMaaari mong iwanang hindi naka-encrypt ang ugat kung wala itong anumang mga lihim at protektado ang boot chain. Kung gumagamit ka ng mga keyfile mula sa ugat upang i-unlock ang iba pang mga volume, magandang ideya na i-encrypt ito.
Sa TPM 2.0, pinapayagan ng systemd-cryptenroll ang mga binding key sa PCRs 0,1,5,7 (firmware, mga opsyon, GPT, secure na katayuan ng boot). Magdagdag ng rd.luks.options=LUKS_UUID=tpm2-device=auto at tiyaking isama ang suporta ng TPM2 sa initramfs. sinusukat ng systemd-boot ang kernel.efi sa PCR4, kapaki-pakinabang para sa pagpapawalang-bisa ng mga key kung magbabago ang UKI o ang cmdline nito.
Mga update at modelo ng deployment
Isang na-verify na read-only na ugat Hindi ito na-update sa manager ng package sa tradisyonal na paraan. Ang mainam ay bumuo ng mga bagong larawan gamit ang mga tool tulad ng ang Yocto project at i-publish ang mga ito. Ang systemd ay may systemd-sysupdate at systemd-repart para sa matatag na pag-download at pag-flash ng imahe.
Ang isa pang diskarte ay A/B scheme: Pinapanatili mo ang dalawang ugat at dalawang katotohanan. Kopyahin ang aktibong ugat sa hindi aktibong ugat, ilapat ang mga pagbabago, at gawing muli ang katotohanan. Bumalik sa susunod na boot. Kung gumagamit ka ng UKI, tandaan na i-update ang root hash sa linya ng cmd o muling buuin ang nilagdaang UKI.
Para sa opsyonal na pagtitiyaga, gamitin ang OverlayFS sa na-verify na ugat na may upper sa tmpfs o disk. Maaari mo ring ipasa ang systemd.volatile=overlay para sa pansamantalang pagtitiyaga. Pinapadali ng Flatpak ang pag-install ng mga app sa /var at /home nang hindi hinahawakan /.
May mga automated na package (hal. verity-squash-root sa AUR) na bumubuo ng squashfs root at lagdaan ang roothash gamit ang kernel at initramfs, na nagbibigay-daan sa iyong pumili sa pagitan ng persistent o ephemeral mode at pagpepreserba ng pinakabagong rootfs bilang backup. Tandaan: ang pagdaragdag ng pagtitiyaga sa isang na-verify na ugat ay may makitid na mga kaso ng paggamit; subukan ang patuloy na data ng app sa magkahiwalay na partition.
Android: system-as-root, AVB at mga overlay ng vendor
Mula noong Android 10, Ang RootFS ay humihinto sa pagtakbo sa RAM disk at sumasama sa system.img. (system-as-root). Palaging ginagamit ng mga device na naglulunsad sa Android 10 ang scheme na ito at nangangailangan ng ramdisk para sa dm-linear. Ang BOARD_BUILD_SYSTEM_ROOT_IMAGE ay nakatakda sa false sa build na ito upang makilala ang pagkakaiba sa pagitan ng paggamit ng ramdisk at direktang pag-activate ng system.img.
Kasama sa Android 10 mga dynamic na partisyon at isang unang yugto ng init na nagpapagana ng lohikal na pagkahati ng sistema; hindi na direktang ini-mount ito ng kernel. Ang mga system-only na OTA ay nangangailangan ng system-as-root na disenyo, na mandatory sa mga Android 10 na device.
Sa walang A/B, panatilihing hiwalay ang pagbawi mula sa bootHindi tulad ng A/B, walang boot_a/boot_b backup, kaya ang pag-alis ng recovery sa non-A/B ay maaaring mag-iwan sa iyo na walang recovery mode kung mabigo ang isang boot update.
Ini-mount ng kernel ang system.img sa /converity sa pamamagitan ng dalawang landas: vboot 1.0 (mga patch para sa kernel para i-parse ang Android metadata sa /system at makuha ang dm-verity na mga parameter; kasama sa cmdline ang root=/dev/dm-0, skip_initramfs at init=/init na may dm=...) o vboot 2.0/AVB, kung saan isinasama ng bootloader ang libavb, binabasa ang hashtree descriptor (sa vbmeta o system), binubuo ang mga parameter at ipinapasa ang mga ito sa kernel sa cmdline, na may suporta sa FEC at mga flag tulad ng restart_on_corruption.
Gamit ang system-as-root, huwag gumamit ng BOARD_ROOT_EXTRA_FOLDERS para sa mga root folder na partikular sa device: mawawala ang mga ito kapag nag-flash ng GSI. Tukuyin ang mga partikular na mount sa ilalim ng /mnt/vendor/ , na awtomatikong ginagawa ng fs_mgr, at tinutukoy ang mga ito sa fstab ng device tree.
Pinapayagan ng Android ang a overlay ng vendor mula sa /product/vendor_overlay/: init ay ilalagay sa /vendor ang mga subdirectory na nakakatugon sa mga kinakailangan sa konteksto ng SELinux at ang pagkakaroon ng /vendor/ . Nangangailangan ng CONFIG_OVERLAY_FS=yy, sa mas lumang mga kernel, ang override_creds=off patch.
Karaniwang pagpapatupad: nag-i-install ng mga precompiled na file sa device/ / /vendor_overlay/, idagdag ang mga ito sa PRODUCT_COPY_FILES na may find-copy-subdir-files sa $(TARGET_COPY_OUT_PRODUCT)/vendor_overlay, tukuyin ang mga konteksto sa file_contexts para sa atbp at app (hal. vendor_configs_file at vendor_app_file) at payagan ang mounton sa mga kontekstong iyon sa init.te. Subukan gamit ang atest vfs_mgr_vendor_overlay_test sa userdebug.
Pag-troubleshoot: dm-verity corruption message sa Android
Sa mga device na may mga A/B slot, palitan ang mga slot o Ang pag-flash ng vbmeta/boot nang walang pare-pareho sa roothash Maaari itong mag-trigger ng babala: dm-verity corruption, hindi pinagkakatiwalaan ang iyong device. Mga command tulad ng fastboot flash –disable-verity –disable-verification vbmeta vbmeta.img i-disable ang pag-verify, ngunit iwanan ang system nang walang anumang garantiya ng integridad.
Sinusuportahan ng ilang mga bootloader fastboot oem disable_dm_verity at ang kabaligtaran nito, enable_dm_verity. Gumagana ito sa ilang mga modelo, ngunit hindi sa iba; at maaaring mangailangan ito ng kernel/magisk na may mga inayos na flag. Gamitin sa iyong sariling peligro: ang maingat na paraan ng pagkilos ay ihanay ang boot, vbmeta, at system, lagdaan o i-regenerate ang puno at tiyaking tumutugma ang inaasahang root hash sa na-configure.
Kung pagkatapos ng babala maaari mong ipagpatuloy ang pagpindot sa kapangyarihan, magsisimula ang system, ngunit wala ka nang buo na chain of trustUpang alisin ang mensahe nang hindi isinakripisyo ang seguridad, ibalik ang orihinal na nilagdaang mga larawan o muling buuin/i-verify ang vbmeta gamit ang tamang hashtree, sa halip na i-disable ang verity.
i.MX at OpenWrt platform
Sa i.MX6 (hal. sabresd), i-configure ang kernel na may suporta sa DM_VERITY at FEC, buuin ang puno gamit ang veritysetup, iimbak ang root hash nang secure, at ipasa ang naaangkop na mga parameter sa linya ng cmd o isama sa pamamagitan ng initramfs sa systemd-veritysetup. Kung hindi ka gumagamit ng dm-crypt, hindi mo kailangan ng CAAM para sa katotohanan; ang pokus ay nasa integridad.
Sa OpenWrt at sa naka-embed na Linux system na may OpenEmbedded, May mga pagsisikap na isama ang dm-verity at SELinux (Binago ang mga trabaho sa Bootlin na may layuning isama ang suporta). Ito ay natural na akma: ang mga router at network equipment ay nakikinabang mula sa isang hindi nababago, na-verify, at MAC-hardened na ugat.
Manu-manong pagbuo ng puno at metadata (detalyadong view)
Maaaring buuin ng cryptsetup ang puno para sa iyo, ngunit kung mas gusto mong maunawaan ang format, ang kahulugan ng linya ng compact na talahanayan ay kinabibilangan ng: pangalan ng pagmamapa, data device, data block at laki ng hash, laki ng larawan sa mga bloke, hash_start position (block image + 8 kung pinagsama-sama), root hash, at asin. Pagkatapos mabuo ang pinagsama-samang mga layer (mula sa itaas hanggang sa ibaba, hindi kasama ang layer 0), isusulat mo ang puno sa disk.
Upang i-pack ang lahat, buuin ang dm-verity table, lagdaan ito (typical RSA-2048) at group signature+table sa metadata na may bersyong header at magic number. Pagkatapos, pinagsasama nito ang imahe ng system, verity metadata, at hash tree. Sa fstab, minarkahan nito ang fs_mgr bilang verify at inilalagay ang pampublikong key sa /boot/verity_key upang mapatunayan ang lagda.
I-optimize gamit ang Mga pagpapabilis ng SHA-2 para sa iyong CPU at ayusin ang read-ahead/prefetch_cluster. Sa ARM hardware, ang NEON SHA-2 (ARMv7) at SHA-2 extension (ARMv8) ay makabuluhang binabawasan ang overhead ng pag-verify.
Sa anumang deployment, tandaan iyon dapat protektahan ang halaga ng root hash: kung pinagsama-sama sa isang nilagdaang UKI, sa nilagdaang boot partition, o na-validate ng bootloader gamit ang AVB. Lahat pagkatapos ng puntong iyon ay nagmamana ng tiwala na iyon.
Sa lahat ng nasa itaas sa lugar, ang dm-verity ay nagiging isang matatag na pundasyon para sa hindi nababago, mobile at naka-embed na mga system, pagsuporta sa mga transaksyonal na update, mga overlay ng configuration, at isang modernong modelo ng seguridad na binabawasan ang pag-atake at pinipigilan ang pagtitiyaga nang hindi sinasakripisyo ang pagganap.
