Nëse jeni të shqetësuar për integritetin e sistemit tuaj, dm-verity është një nga pjesët kryesore të ekosistemit Linux. për të nisur në mënyrë të sigurt dhe për të zbuluar ndërhyrjet në memorien e brendshme. Kjo filloi si pjesë e hartuesit të pajisjeve të kernelit dhe tani është baza për nisjen e verifikuar në Android, OpenWrt dhe shpërndarjet që kërkojnë siguri të përmirësuar.
Larg të qenit një koncept abstrakt, dm-verity është konfiguruar dhe përdorur me mjete reale si veritysetup dhe systemd-veritysetupAi validon blloqet menjëherë duke përdorur pemë hash dhe mund të reagojë ndaj korruptimit me politika që variojnë nga regjistrimi i ngjarjes deri te rinisja ose rrëzimi i sistemit. Le ta hedhim një vështrim më të afërt, pa lënë asnjë fund të paqartë.
Çfarë është dm-verity dhe pse mund t'ju interesojë
dm-verity është një objektiv i hartëzimit të pajisjeve në kernel që verifikon integritetin e një pajisjeje bllok ndërsa lexohen të dhënatFunksionon duke llogaritur dhe verifikuar hash-et e secilit bllok (zakonisht 4K) kundrejt një peme hash të parallogaritur, zakonisht duke përdorur SHA-256.
Ky dizajn lejon Skedarët nuk mund të modifikohen në heshtje midis rinisjeve ose gjatë ekzekutimitËshtë çelësi për zgjerimin e zinxhirit të besimit të nisjes në sistemin operativ, kufizimin e qëndrueshmërisë së programeve keqdashëse, forcimin e politikave të sigurisë dhe sigurimin e mekanizmave të enkriptimit dhe MAC gjatë nisjes.
Në Android (që nga versioni 4.4) dhe Linux në përgjithësi, Besimi është i ankoruar në hash-in rrënjësor të pemës, i cili është nënshkruar dhe validuar me një çelës publik të vendosur në një vendndodhje të mbrojtur (p.sh., në ndarjen e nisjes ose në një UKI të nënshkruar nga Secure Boot). Thyerja e çdo blloku do të kërkonte thyerjen e hash-it kriptografik themelor.
Verifikimi bëhet me bllok dhe sipas kërkesës: Latencia e shtuar është minimale në krahasim me koston e I/O-sëNëse një kontroll dështon, bërthama kthen një gabim I/O dhe sistemi i skedarëve duket i korruptuar, gjë që pritet kur të dhënat nuk janë të besueshme. Aplikacionet mund të vendosin nëse do të vazhdojnë apo jo bazuar në tolerancën e tyre ndaj gabimeve.
Si funksionon pema e verifikimit nga brenda
Pema e verifikimit është ndërtuar në shtresa. Shtresa 0 është të dhënat e papërpunuara nga pajisja, të ndara në blloqe 4K; një hash SHA-256 (i kripur) llogaritet për secilin bllok. Këto hashe më pas bashkohen për të formuar shtresën 1. Shtresa 1 më pas grupohet në blloqe dhe ri-hashohet për të formuar shtresën 2, e kështu me radhë derisa gjithçka të përshtatet në një bllok të vetëm: ai bllok, kur hashohet, prodhon hashin rrënjë.
Nëse ndonjë shtresë nuk e plotëson saktësisht një bllok, Është i mbushur me zero derisa të arrijë 4K për të shmangur paqartësinë. Madhësia totale e pemës varet nga madhësia e ndarjes që kontrollohet; në praktikë, zakonisht është më pak se 30 MB për ndarjet tipike të sistemit.
Procesi i përgjithshëm është: zgjidhni një kripë të rastësishme, hashoni në 4K, llogaritni SHA-256 me kripë për bllok, bashkohet për të formuar nivele, mbush kufirin e bllokut me zero dhe përsëritet me nivelin e mëparshëm derisa të mbetet një hash rrënjë i vetëm. Ky hash rrënjë, së bashku me kripën e përdorur, ushqen tabelën dm-verity dhe nënshkrimin.
Versionet dhe algoritmi i formatit të diskut
Formati i blloqeve hash në disk ka një version. Versioni 0 ishte versioni origjinal i përdorur në Chromium OS.Kripa shtohet në fund të procesit të hashimit, të dhënat e tretjes ruhen vazhdimisht dhe pjesa tjetër e bllokut mbushet me zero.
La Versioni 1 rekomandohet për pajisjet e rejaKripa i paraprihet hash-it dhe çdo përmbledhje plotësohet me zero deri në fuqitë e dy, duke përmirësuar shtrirjen dhe qëndrueshmërinë. Tabela dm-verity gjithashtu specifikon algoritmin (p.sh., sha1 ose sha256), megjithëse për sigurinë aktuale përdoret sha256.
tabela dm-verity dhe parametrat thelbësorë
Tabela e destinacionit dm-verity përshkruan ku janë të dhënat, ku është pema e hash-it dhe si të verifikohenFushat tipike të tabelës:
- dev: pajisje me të dhënat që do të verifikohen (lloji i shtegut /dev/sdXN ose më i madh: më i vogël).
- hash_dev: pajisje me pemën hash (mund të jetë e njëjtë; nëse po, hash_start duhet të jetë jashtë diapazonit të kontrolluar).
- madhësia e_bllokut_të_datave: madhësia e bllokut të të dhënave në bajt (p.sh. 4096).
- madhësia e_bllokut_të_hash-it: madhësia e bllokut hash në bajt.
- num_data_blocks: numri i blloqeve të të dhënave të verifikueshme.
- hash_start_block: zhvendosje (në blloqet hash_block_size) në bllokun rrënjë të pemës.
- algorithm: algoritmi i hashimit (p.sh. sha256).
- tretet: kodim heksadecimal i hash-it të bllokut rrënjë (duke përfshirë kripën sipas versionit të formatit); kjo vlerë është ajo që duhet besuar.
- kripë: kripë heksadecimale.
Përveç kësaj, nuk janë parametra opsionalë Shumë i dobishëm për rregullimin e sjelljes:
- ignore_corruptionRegjistron blloqet e dëmtuara, por lejon që leximi të vazhdojë.
- restart_on_corruption: rinis në zbulimin e korrupsionit (nuk është i pajtueshëm me ignore_corruption dhe kërkon mbështetje të hapësirës së përdoruesit për të shmangur sythet).
- panik_mbi_korrupsionin: : shkakton panik kur zbulon korruptim (nuk është i pajtueshëm me versionet e mëparshme).
- gabim_i_rifillimit y panic_on_error: të njëjtat reagime por për gabimet I/O.
- ignore_zero_blocks: nuk kontrollon blloqet që priten si zero dhe kthen zero.
- use_fec_from_device + fec_roots + fec_blocks + fec_startAktivizoni Reed-Solomon (FEC) për të rikuperuar të dhënat kur verifikimi dështon; zonat e të dhënave, hash-it dhe FEC nuk duhet të mbivendosen dhe madhësitë e bllokut duhet të përputhen.
- kontrollo_më së shumti_një herëKontrollon çdo bllok të dhënash vetëm herën e parë që lexohet (zvogëlon koston e sigurisë në sulmet e drejtpërdrejta).
- root_hash_sig_key_descReferencë për një çelës në varësen e çelësave për të validuar një nënshkrim PKCS7 të hash-it rrënjësor gjatë krijimit të mapimit (kërkon konfigurim të përshtatshëm të bërthamës dhe varëse çelësash të besuara).
- try_verify_in_taskletNëse hash-et janë të ruajtura në memorje dhe madhësia e I/O e lejon, kontrollon gjysmën e poshtme për të zvogëluar vonesën; rregullohet me /sys/module/dm_verity/parameters/use_bh_bytes për klasën I/O.
Nënshkrimi, metadatat dhe ankorimi i besimit
Që dm-verity të jetë i besueshëm, Hashi rrënjësor duhet të jetë i besueshëm dhe zakonisht i nënshkruarNë Android-in klasik, një çelës publik përfshihet në ndarjen e nisjes, e cila verifikohet nga jashtë nga prodhuesi; ai vërteton nënshkrimin e hash-it rrënjësor dhe siguron që ndarja e sistemit të mos jetë ndryshuar.
Metadata e Verity shton strukturën dhe kontrollin e versionit. Blloku i meta-të dhënave përfshin një numër magjik 0xb001b001 (bajt b0 01 b0 01), versioni (aktualisht 0), nënshkrimi i tabelës në PKCS1.5 (zakonisht 256 bajt për RSA-2048), gjatësia e tabelës, vetë tabela dhe mbushja me zero deri në 32K.
Në implementimet e Android, verifikimi mbështetet në fs_mgr dhe fstabShtimi i një shenje kontrolli në hyrjen përkatëse dhe vendosja e çelësit në /boot/verity_key. Nëse numri magjik nuk është aty ku duhet të jetë, verifikimi ndalet për të shmangur kontrollimin e gjësë së gabuar.
Operacioni i fillimit u verifikua
Mbrojtja ndodhet në bërthamë: Nëse kompromentohet përpara se të niset kerneli, sulmuesi e mban kontrollin.Kjo është arsyeja pse prodhuesit zakonisht e vërtetojnë në mënyrë strikte çdo fazë: një çelës i futur në pajisje verifikon ngarkuesin e parë të sistemit, i cili verifikon ngarkuesin tjetër të sistemit, ngarkuesin e aplikacionit dhe së fundmi, bërthamën.
Me kernelin e verifikuar, dm-verity aktivizohet kur montohet pajisja e bllokut të verifikuarNë vend që të heshohet e gjithë pajisja (gjë që do të ishte e ngadaltë dhe do të shpërdoronte energji), ajo verifikohet bllok pas blloku ndërsa aksesohet. Një dështim shkakton një gabim I/O dhe shërbimet dhe aplikacionet reagojnë sipas tolerancës së tyre: ose vazhdojnë pa ato të dhëna ose rrëzohen plotësisht.
Korrigjimi i Gabimit të Përparuar (FEC)
Që nga Android 7.0, FEC (Reed-Solomon) është i përfshirë me teknikat e ndërthurjes për të zvogëluar hapësirën dhe për të rritur aftësinë për të rikuperuar blloqet e dëmtuara. Kjo funksionon në lidhje me dm-verity: nëse një kontroll dështon, nënsistemi mund të përpiqet ta korrigjojë atë përpara se ta deklarojë të parikuperueshëm.
Performanca dhe optimizimi
Për të zvogëluar ndikimin: Aktivizo përshpejtimin SHA-2 nga NEON në ARMv7 dhe zgjerimet SHA-2 në ARMv8 nga bërthama. Rregulloni parametrat read-ahead dhe prefetch_cluster për harduerin tuaj; verifikimi për bllok zakonisht shton pak në koston e I/O, por këto cilësime bëjnë një ndryshim.
Fillimi në Linux (systemd, veritysetup) dhe Android
Në një Linux modern me systemd, dm-verity lejon një rrënjë të verifikuar vetëm për lexim duke përdorur veritysetup (pjesë e cryptsetup), systemd-veritysetup.generator dhe systemd-veritysetup@.service. Rekomandohet të përfshihen Secure Boot dhe një UKI (imazh i unifikuar i kernelit) i nënshkruar, megjithëse ato nuk janë të detyrueshme në mënyrë strikte.
Përgatitja dhe ndarja e rekomanduar
Pjesë e një sistemi funksional dhe të rregulluar. Rezervoni një vëllim për pemën e hash-it (Zakonisht mjafton 8–10% e madhësisë së rrënjës) dhe merrni në konsideratë ndarjen e /home dhe /var nëse keni nevojë të shkruani. Një skemë tipike përfshin: ESP (për bootloader-in), XBOOTLDR (për UKI-të), rrënjën (me ose pa enkriptim), ndarjen VERITY dhe opsionalisht /home dhe /var.
Si një rrënjë, EROFS është një alternativë shumë interesante ndaj ext4 ose squashfs.Është projektuar vetëm për lexim, me performancë shumë të mirë në flash/SSD, kompresim lz4 si parazgjedhje dhe përdoret gjerësisht në telefonat Android me dm-verity.
Skedarët që duhet të jenë të shkrueshëm
Me root ro, disa programe presin të shkruajnë në /etc ose gjatë inicializimitMund ta zhvendosësh te /var/etc dhe të vendosësh një lidhje simbolike në çdo gjë që duhet të ndryshohet (p.sh., lidhjet NetworkManager në /etc/NetworkManager/system-connections). Vini re se systemd-journald kërkon që /etc/machine-id të ekzistojë në direktorinë rrënjë (jo një lidhje simbolike) për të shmangur ndërprerjen e nisjeve të hershme.
Për të zbuluar se çfarë ndryshon në ekzekutim, përdor dracut-overlayroot: mbivendos një tmpfs mbi rrënjën, dhe gjithçka e shkruar shfaqet në /run/overlayroot/u. Shtoni modulin te /usr/lib/dracut/modules.d/, përfshini overlayroot në dracut dhe vendosni overlayroot=1 në rreshtin e kernelit; në këtë mënyrë do të shihni se çfarë duhet të migroni te /var.
Shembuj të dobishëm: pacman dhe NetworkManager
Në Arch, është i përshtatshëm Zhvendosni bazën e të dhënave Pacman në /usr/lib/pacman në mënyrë që rootfs të pasqyrojë gjithmonë paketat e instaluara. Pastaj, ridrejtoni memorien e përkohshme te /var/lib/pacman dhe lidhni. Për të ndryshuar listën e pasqyrave pa prekur rrënjën, zhvendoseni atë te /var/etc dhe lidheni atë gjithsesi.
Me NetworkManager, zhvendos lidhjet e sistemit në /var/etc/NetworkManager dhe lidhja nga /etc/NetworkManager/system-connections. Kjo e mban rrënjën të pandryshueshme dhe konfigurimin aty ku duhet të jetë i shkrueshëm.
Ndërtimi i vërtetësisë dhe testimi
Nga një live dhe me gjithçka perfekte dhe të montuar në RO, krijoni pemën dhe roothash me formati i veritysetupKur ekzekutohet, printon rreshtin Root Hash, të cilin mund ta ruani në roothash.txt. Ekzekutojeni për testim me veritysetup, hapni root-device, root, verity-device $(cat roothash.txt) dhe montoni /dev/mapper/root.
Nëse preferoni, së pari gjeneron pemën në një skedar (verity.bin) dhe pastaj shkruajeni atë në ndarjen VERITY. Seti që rezulton është: imazhi rrënjë, pema e verity dhe hash-i rrënjë që do ta pinni gjatë nisjes.
Konfiguro linjën e kernelit
Shtoni këto parametra: systemd.verity=1, roothash=contents_of_roothash.txt, systemd.verity_root_data=ROOT-PATH (p.sh. LABEL=OS), dhe systemd.verity_root_hash=VERITY-PATH (p.sh. LABEL=VERITY). Caktoni systemd.verity_root_options në restart-on-corruption ose panic-on-corruption për politika strikte.
Opsione të tjera të rekomanduara: ro (nëse nuk përdorni EROFS/squashfs), rd.emergency=rinisje y rd.shell=0 (parandaloni shell-et e paautorizuara nëse nisja dështon), dhe bllokim = konfidencialitet për të mbrojtur memorien e bërthamës nga qasja.
Ndarje shtesë me vërtetësi
Jo vetëm rrënja: Mund të përcaktoni mapime të tjera në /etc/veritytab dhe systemd-veritysetup@.service do t'i montojë ato gjatë nisjes. Mos harroni: është më e lehtë të montosh në RW një ndarje jo-root, dhe një përdorues root mund të çaktivizojë Verity në ato ndarje, kështu që vlera e sigurisë atje është më e ulët.
Siguria: Nisje e Sigurt, UKI dhe module të nënshkruara
dm-verity nuk është një zgjidhje e shkëlqyer. Nënshkruani UKI-në dhe aktivizoni Secure Boot me çelësat tuaj për të parandaluar që dikush të mbivendosë kernel/initramfs/cmdline (që përfshin hash-in rrënjë). Mjete si sbupdate-git ose sbctl ndihmojnë në mbajtjen e imazheve të nënshkruara dhe zinxhirit të nisjes të paprekur.
Nëse aktivizoni bllokimin e kernelit ose verifikimin e nënshkrimit të modulit, DKMS ose modulet jashtë pemës duhet të nënshkruhen ose nuk do të ngarkohen. Konsideroni një kernel të personalizuar me mbështetje për nënshkrimin për tubacionin tuaj (shih modulet e kernelit të nënshkruar).
Enkriptimi, TPM dhe matja
dm-verity mbron integritetin, jo-konfidencialitetMund ta lini root-in të pakriptuar nëse nuk përmban sekrete dhe zinxhiri i nisjes është i mbrojtur. Nëse përdorni skedarë çelësash nga root për të zhbllokuar vëllime të tjera, atëherë është një ide e mirë ta enkriptoni atë.
Me TPM 2.0, systemd-cryptenroll lejon lidhjen e çelësave me PCR-të 0,1,5,7 (firmware, opsione, GPT, status i nisjes së sigurt). Shtoni rd.luks.options=LUKS_UUID=tpm2-device=auto dhe sigurohuni që të përfshini mbështetjen për TPM2 në initramfs. systemd-boot mat kernel.efi në PCR4, i dobishëm për të pavlefshëm çelësat nëse UKI ose komanda e tij ndryshon.
Përditësimet dhe modelet e vendosjes
Një rrënjë e verifikuar vetëm për lexim Nuk përditësohet me menaxherin e paketave në mënyrën tradicionaleIdeali është të ndërtohen imazhe të reja me mjete si projekti Yocto dhe publikojini ato. systemd ka systemd-sysupdate dhe systemd-repart për shkarkim dhe instalim të fuqishëm të imazheve.
Një strategji tjetër është Skema A/BJu mbani dy rrënjë dhe dy vërtetësi. Kopjoni rrënjën aktive në rrënjën joaktive, aplikoni ndryshimet dhe ribëni vërtetsinë. Kthehuni përsëri në nisjen tjetër. Nëse po përdorni UKI, mos harroni të përditësoni hash-in e rrënjës në rreshtin cmd ose të rindërtoni UKI-në e nënshkruar.
Për qëndrueshmëri opsionale, përdorni OverlayFS në rrënjën e verifikuar me pjesën e sipërme në tmpfs ose disk. Gjithashtu mund të kaloni systemd.volatile=overlay për qëndrueshmëri të përkohshme. Flatpak e bën të lehtë instalimin e aplikacioneve në /var dhe /home pa prekur /.
Ekzistojnë paketa të automatizuara (p.sh. verity-squash-root në AUR) që ndërtojnë një rrënjë squashfs dhe Nënshkruaj roothash-in me kernel dhe initramfs, duke ju lejuar të zgjidhni midis modalitetit persistent ose efemeral dhe duke ruajtur rootf-et më të fundit si kopje rezervë. Shënim: shtimi i persistencës në një root të verifikuar ka raste përdorimi të ngushta; provoni të ruani të dhënat e aplikacionit persistent në ndarje të ndara.
Android: sistem-si-root, AVB dhe mbivendosje të shitësve
Që nga Android 10, RootFS ndalon së punuari në diskun RAM dhe integrohet me system.img. (sistemi-si-root). Pajisjet që lançohen me Android 10 përdorin gjithmonë këtë skemë dhe kërkojnë një ramdisk për dm-linear. BOARD_BUILD_SYSTEM_ROOT_IMAGE është vendosur në false në këtë version për të dalluar përdorimin e një ramdisk dhe aktivizimin direkt të system.img.
Android 10 përfshin ndarje dinamike dhe një init i fazës së parë gjë që aktivizon ndarjen logjike të sistemit; bërthama nuk e monton më atë drejtpërdrejt. OTA-të vetëm për sistemin kërkojnë një dizajn sistemi-si-rrënjë, i cili është i detyrueshëm në pajisjet Android 10.
Në asnjë A/B, mbaje rikuperimin të ndarë nga nisjaNdryshe nga A/B, nuk ka kopje rezervë boot_a/boot_b, kështu që heqja e rikuperimit në jo-A/B mund t'ju lërë pa modalitetin e rikuperimit nëse një përditësim i nisjes dështon.
Bërthama monton system.img në /converity nëpërmjet dy shtigjeve: vboot 1.0 (patch-e për kernelin për të analizuar meta të dhënat e Android në /system dhe për të nxjerrë parametrat dm-verity; cmdline përfshin root=/dev/dm-0, skip_initramfs dhe init=/init me dm=…) ose vboot 2.0/AVB, ku bootloader-i integron libavb, lexon përshkruesin e hashtree-s (në vbmeta ose sistem), ndërton parametrat dhe ia kalon ato kernelit në cmdline, me mbështetje FEC dhe flamuj si restart_on_corruption.
Me sistemin si rrënjë, mos përdorni BOARD_ROOT_EXTRA_FOLDERS për dosjet rrënjë specifike të pajisjes: këto do të zhduken kur të instalohet një GSI. Përcaktoni montime specifike nën /mnt/vendor/ , të cilat fs_mgr i krijon automatikisht, dhe i referon ato në fstab të pemës së pajisjeve.
Android lejon një mbivendosja e shitësit nga /product/vendor_overlay/init do të montojë në /vendor nën-direktoritë që plotësojnë kërkesat e kontekstit SELinux dhe ekzistencën e /vendor/ Kërkon CONFIG_OVERLAY_FS=yy, në kernelet më të vjetra, patch-in override_creds=off.
Implementimi tipik: instalon skedarë të parapërgatitur në pajisje/ / /vendor_overlay/, shtojini ato te PRODUCT_COPY_FILES me find-copy-subdir-files te $(TARGET_COPY_OUT_PRODUCT)/vendor_overlay, përcaktoni kontekstet në file_contexts për etj. dhe aplikacionin (p.sh. vendor_configs_file dhe vendor_app_file) dhe lejoni montimin në ato kontekste në init.te. Testoni me atest vfs_mgr_vendor_overlay_test në userdebug.
Zgjidhja e problemeve: mesazhi i korruptimit të dm-verity në Android
Në pajisjet me slote A/B, ndërroni slotet ose Duke ndezur vbmeta/boot pa konsistencë me roothash-in Kjo mund të aktivizojë paralajmërimin: dm-verity corruption, your device is untrusted. Komandat si fastboot flash –disable-verity –disable-verification vbmeta vbmeta.img çaktivizojnë verifikimin, por e lënë sistemin pa asnjë garanci integriteti.
Disa ngarkues boot mbështesin fastboot oem disable_dm_verity dhe e kundërta e saj, enable_dm_verity. Funksionon në disa modele, por jo në të tjera; dhe mund të kërkojë kernel/magisk me flamuj të rregulluar. Përdoreni me rrezikun tuaj: veprimi i kujdesshëm është rreshto boot, vbmeta dhe system, nënshkruani ose rigjeneroni pemën dhe sigurohuni që hashi i rrënjës së pritur përputhet me atë të konfiguruar.
Nëse pas paralajmërimit mund të vazhdoni të shtypni butonin e energjisë, sistemi fillon, por nuk ke më një zinxhir të paprekur besimiPër ta hequr mesazhin pa sakrifikuar sigurinë, rivendosni imazhet origjinale të nënshkruara ose rindërtoni/verifikoni vbmeta me hashtree-n e saktë, në vend që ta çaktivizoni verity-n.
Platformat i.MX dhe OpenWrt
Në i.MX6 (p.sh. sabresd), konfiguroni kernelin me mbështetje për DM_VERITY dhe FEC, gjeneroni pemën me veritysetup, ruani në mënyrë të sigurt hash-in rrënjësor dhe kaloni parametrat e duhur në rreshtin cmd ose integrojeni nëpërmjet initramfs me systemd-veritysetup. Nëse nuk përdorni dm-crypt, nuk keni nevojë për CAAM për verity; fokusi është te integriteti.
Në OpenWrt dhe në sisteme të integruara Linux me OpenEmbedded, Ka përpjekje për të integruar dm-verity dhe SELinux. (Punët e Bootlin janë rishikuar me qëllim përfshirjen e mbështetjes). Është një përshtatje e natyrshme: routerët dhe pajisjet e rrjetit përfitojnë nga një rrënjë e pandryshueshme, e verifikuar dhe e përforcuar nga MAC.
Ndërtimi manual i pemës dhe meta të dhënave (pamje e detajuar)
cryptsetup mund ta gjenerojë pemën për ju, por nëse preferoni ta kuptoni formatin, përkufizimi kompakt i vijës së tabelës përfshin: emri i hartëzimit, pajisja e të dhënave, madhësia e bllokut të të dhënave dhe madhësia e hash-it, madhësia e imazhit në blloqe, pozicioni i hash_start (imazhi i bllokut + 8 nëse është i bashkuar), hash-i rrënjësor dhe kripa. Pasi të keni gjeneruar shtresat e bashkuara (nga lart poshtë, duke përjashtuar shtresën 0), ju e shkruani pemën në disk.
Për të paketuar gjithçka, hartoni tabelën dm-verity, nënshkruajeni atë (RSA-2048 tipike) dhe gruponi tabelën + nënshkrimin në metadata me një kokë të versionuar dhe një numër magjik. Pastaj, bashkon imazhin e sistemit, meta të dhënat e Verity dhe pemën hash. Në fstab, shënon fs_mgr si verifiko dhe vendos çelësin publik në /boot/verity_key për të validuar nënshkrimin.
Optimizo me Shpejtimet SHA-2 për CPU-në tuaj dhe rregulloni read-ahead/prefetch_cluster. Në harduerin ARM, NEON SHA-2 (ARMv7) dhe zgjerimet SHA-2 (ARMv8) e zvogëlojnë ndjeshëm mbingarkesën e verifikimit.
Në çdo vendosje, mbani mend se Vlera e hash-it rrënjësor duhet të mbrohet: qoftë i kompiluar në një UKI të nënshkruar, në ndarjen e boot-it të nënshkruar, apo i validuar nga bootloader-i duke përdorur AVB. Çdo gjë pas kësaj pike trashëgon atë besim.
Me të gjitha sa më sipër në vend, dm-verity bëhet një themel i fortë për sisteme të pandryshueshme, të lëvizshme dhe të integruara, duke mbështetur përditësimet transaksionale, mbivendosjet e konfigurimit dhe një model modern sigurie që zvogëlon sipërfaqen e sulmit dhe parandalon vazhdimësinë pa sakrifikuar performancën.
