Ja jūs uztrauc jūsu sistēmas integritāte, dm-verity ir viena no galvenajām Linux ekosistēmas daļām. lai droši ielādētu sistēmu un atklātu atmiņas manipulācijas. Tā sākotnēji bija daļa no kodola ierīču kartētāja un tagad ir pamats verificētai ielādei operētājsistēmās Android, OpenWrt un distribūcijās, kas meklē uzlabotu drošību.
Tālu no abstrakta jēdziena, dm-verity tiek konfigurēts un izmantots ar reāliem rīkiem, piemēram, veritysetup un systemd-veritysetup.Tas validē blokus acumirklī, izmantojot jaucējkokus, un var reaģēt uz bojājumiem ar politikām, sākot no notikuma reģistrēšanas līdz sistēmas pārstartēšanai vai avārijai. Apskatīsim to tuvāk, neatstājot nekādus vaļīgus galus.
Kas ir dm-verity un kāpēc tas jums varētu interesēt
dm-verity ir ierīču kartēšanas mērķis kodolā, kas pārbauda bloka ierīces integritāti, lasot datusTas darbojas, aprēķinot un pārbaudot katra bloka (parasti 4 KB) hešus pret iepriekš aprēķinātu heša koku, parasti izmantojot SHA-256.
Šis dizains ļauj Failus nevar klusībā modificēt starp atkārtotām palaišanām vai izpildes laikāTas ir svarīgi, lai paplašinātu operētājsistēmas palaišanas uzticamības ķēdi, ierobežotu ļaunprogrammatūras noturību, stiprinātu drošības politikas un nodrošinātu šifrēšanu un MAC mehānismus palaišanas laikā.
Operētājsistēmās Android (kopš 4.4. versijas) un Linux kopumā Uzticība ir balstīta uz koka saknes hešu, kas ir parakstīts un apstiprināts ar publisku atslēgu, kas atrodas aizsargātā vietā (piemēram, sāknēšanas nodalījumā vai ar drošu sāknēšanu parakstītā UKI). Jebkura bloka uzlaušana prasītu pamatā esošā kriptogrāfiskā jaucējkoda uzlaušanu.
Verifikācija tiek veikta pa blokiem un pēc pieprasījuma: Pievienotā latentuma vērtība ir minimāla, salīdzinot ar I/O izmaksām.Ja pārbaude neizdodas, kodols atgriež I/O kļūdu un failu sistēma šķiet bojāta, kas ir sagaidāms, ja dati nav uzticami. Lietotnes var izlemt, vai turpināt vai nē, pamatojoties uz savu kļūdu toleranci.
Kā verifikācijas koks darbojas iekšēji
Verifikācijas koks ir veidots slāņos. 0. slānis ir ierīces neapstrādātie dati, kas sadalīti 4 KB blokos.; katram blokam tiek aprēķināts SHA-256 (sālīts) hešs. Pēc tam šie heši tiek apvienoti, veidojot 1. slāni. Pēc tam 1. slānis tiek grupēts blokos un atkārtoti hešēts, veidojot 2. slāni, un tā tālāk, līdz viss ietilpst vienā blokā: šis bloks, hešējot, ģenerē saknes hešu.
Ja kāds slānis precīzi nepabeidz bloku, Tas tiek papildināts ar nullēm, līdz tas sasniedz 4K lai izvairītos no neskaidrībām. Koka kopējais lielums ir atkarīgs no pārbaudāmās nodalījuma lieluma; praksē tipiskām sistēmas nodalījumiem tas parasti ir mazāks par 30 MB.
Vispārīgais process ir šāds: izvēlieties nejaušu sāli, hešu līdz 4K, aprēķiniet SHA-256 ar sāli katrā blokā, savienojas, veidojot līmeņus, papildina bloka robežu ar nullēm un atkārtojas ar iepriekšējo līmeni, līdz paliek viens saknes hešs. Šis saknes hešs kopā ar izmantoto sāls vērtību ievada dm-verity tabulu un parakstu.
Diska formāta versijas un algoritms
Haša bloku formātam diskā ir versija. 0. versija bija sākotnējā versija, kas tika izmantota operētājsistēmā Chromium OS.Sāls tiek pievienots jaucējkoda apstrādes beigās, sagremotie dati tiek glabāti nepārtraukti, un pārējā bloka daļa tiek papildināta ar nullēm.
La Jaunām ierīcēm ir ieteicama 1. versijaSāls tiek pievienots jaucējkodam (hash), un katrs īssavilkums tiek papildināts ar nullēm līdz divi pakāpēm, uzlabojot izlīdzināšanu un robustumu. dm-verity tabulā ir norādīts arī algoritms (piemēram, sha1 vai sha256), lai gan pašreizējai drošībai tiek izmantots sha256.
dm-verity tabula un svarīgākie parametri
Mērķa tabulā dm-verity ir aprakstīts kur atrodas dati, kur atrodas jaucējkoks un kā to pārbaudītTipiski tabulas lauki:
- dev: ierīce ar pārbaudāmajiem datiem (ceļa tips /dev/sdXN vai lielāks:mazs).
- hash_dev: ierīce ar jaucējkoku (var būt tas pats; ja tā, tad hash_start jābūt ārpus pārbaudītā diapazona).
- datu_bloka_izmērs: datu bloka lielums baitos (piemēram, 4096).
- hash_block_size: jaucējkodu bloka izmērs baitos.
- datu_bloku_skaits: pārbaudāmo datu bloku skaits.
- hash_start_block: nobīde (hash_block_size blokos) pret koka saknes bloku.
- algoritmsheša algoritms (piemēram, sha256).
- sagremot: saknes bloka jaucējkoda heksadecimālais kodējums (ieskaitot sāls vērtību atbilstoši formāta versijai); šai vērtībai ir jāuzticas.
- sāls: heksadecimālais sāls.
Turklāt ir neobligātie parametri ļoti noderīgi uzvedības pielāgošanai:
- ignorēt_korupciju: Ieraksta bojātus blokus, bet ļauj turpināt lasīšanu.
- restart_on_corruption: restartēt pēc bojājumu noteikšanas (nav saderīgs ar ignore_corruption un prasa lietotāja telpas atbalstu, lai izvairītos no cilpām).
- panika_par_korupciju: : izraisa paniku, atklājot bojājumus (nav saderīgs ar iepriekšējām versijām).
- restartēt_kļūdas_rezultātā y panika_kļūdas_reizē: tās pašas reakcijas, bet I/O kļūdām.
- ignorēt_nulles_blokus: nepārbauda blokus, kuriem vajadzētu būt nullēm, un atgriež nulles.
- izmantot_fec_from_device + fec_roots + fec_bloki + fec_start: Iespējojiet Reed-Solomon (FEC) datu atgūšanu, ja verifikācija neizdodas; datu, jaucējkoda un FEC apgabali nedrīkst pārklāties, un bloku izmēriem ir jāsakrīt.
- pārbaudīt_vismaz_vienu_reiziPārbauda katru datu bloku tikai pirmajā lasīšanas reizē (samazina papildu izmaksas uz drošības rēķina tiešraides uzbrukumos).
- root_hash_sig_key_descAtsauce uz atslēgu atslēgu saišķī, lai validētu saknes jaucējkoda PKCS7 parakstu, veidojot kartējumu (nepieciešama atbilstoša kodola konfigurācija un uzticami atslēgu saišķi).
- try_verify_in_taskletJa heši ir kešatmiņā un I/O lielums to atļauj, pārbauda apakšējo pusi, lai samazinātu latentumu; pielāgo ar /sys/module/dm_verity/parameters/use_bh_bytes katrai I/O klasei.
Paraksts, metadati un uzticamības nodrošināšana
Lai dm-verity būtu uzticams, Saknes jaucējkodam ir jābūt uzticamam un parasti parakstītam.Klasiskajā Android versijā sāknēšanas nodalījumā ir iekļauta publiskā atslēga, kuru ārēji verificē ražotājs; tā apstiprina saknes jaucējkoda parakstu un nodrošina, ka sistēmas nodalījums nav mainīts.
Verity metadati pievieno struktūru un versiju kontroli. Metadatu blokā ir iekļauts maģiskais skaitlis 0xb001b001. (baiti b0 01 b0 01), versija (pašlaik 0), tabulas paraksts PKCS1.5 valodā (parasti 256 baiti RSA-2048), tabulas garums, pati tabula un nulles papildināšana līdz 32 KB.
Android ieviešanā verifikācija balstās uz fs_mgr un fstabAtzīmes pievienošana atbilstošajam ierakstam un atslēgas ievietošana mapē /boot/verity_key. Ja maģiskais skaitlis neatrodas tur, kur tam jābūt, verifikācija tiek pārtraukta, lai izvairītos no nepareizas lietas pārbaudes.
Darbības uzsākšana verificēta
Aizsardzība atrodas kodolā: Ja uzbrucējs tiek apdraudēts pirms kodola ielādes, tas saglabā kontroli.Tāpēc ražotāji parasti stingri pārbauda katru posmu: ierīcē ierakstīta atslēga pārbauda pirmo sāknēšanas ielādētāju, kas pārbauda nākamo — lietotnes sāknēšanas ielādētāju un visbeidzot — kodolu.
Kad kodols ir verificēts, dm-verity ir iespējots, uzstādot verificētu bloka ierīciTā vietā, lai hešētu visu ierīci (kas būtu lēni un tērētu enerģiju), tā tiek pārbaudīta bloku pa blokam, kad tai piekļūst. Kļūme izraisa I/O kļūdu, un pakalpojumi un lietotnes reaģē atbilstoši savai tolerancei: vai nu turpina darboties bez šiem datiem, vai pilnībā avarē.
Tiešās kļūdas korekcija (FEC)
Kopš Android 7.0, FEC (Reed-Solomon) ir apvienots ar savīšanas metodēm lai samazinātu vietu un palielinātu bojātu bloku atgūšanas iespējas. Tas darbojas kopā ar dm-verity: ja pārbaude neizdodas, apakšsistēma var mēģināt to labot, pirms tā tiek pasludināta par neatjaunojamu.
Veiktspēja un optimizācija
Lai mazinātu ietekmi: Iespējot SHA-2 paātrinājumu ar NEON ARMv7 un SHA-2 paplašinājumus ARMv8 no kodola. Pielāgojiet aparatūras iepriekšējas lasīšanas un prefetch_cluster parametrus; bloka verifikācija parasti maz palielina I/O izmaksas, taču šiem iestatījumiem ir nozīme.
Darba sākšana operētājsistēmās Linux (systemd, veritysetup) un Android
Mūsdienīgā Linux sistēmā ar systemd, dm-verity atļauj pārbaudītu tikai lasāmu sakni izmantojot veritysetup (daļa no cryptsetup), systemd-veritysetup.generator un systemd-veritysetup@.service. Ieteicams iekļaut drošo sāknēšanu un parakstītu UKI (vienoto kodola attēlu), lai gan tie nav obligāti.
Sagatavošana un ieteicamā sadalīšana
Funkcionālas un pielāgotas sistēmas sastāvdaļa. Rezervēt apjomu jaucējkokam (Parasti pietiek ar 8–10 % no root nodalījuma lieluma) un, ja nepieciešams rakstīt, apsveriet /home un /var atdalīšanu. Tipiska shēma ietver: ESP (sāknēšanas ielādētājam), XBOOTLDR (UKI), root (ar vai bez šifrēšanas), VERITY nodalījumu un pēc izvēles /home un /var.
Kā sakne, EROFS ir ļoti interesanta alternatīva ext4 vai squashfs.Tas ir paredzēts tikai lasīšanai, tam ir ļoti laba veiktspēja zibatmiņā/SSD, pēc noklusējuma tiek izmantota lz4 saspiešana, un tas tiek plaši izmantots Android tālruņos ar dm-verity.
Faili, kuriem jābūt rakstāmiem
Ar root ro dažas programmas sagaida rakstīšanu uz /etc vai init laikāVarat to pārvietot uz /var/etc un izveidot simbolisku saiti visam, kas jāmaina (piemēram, NetworkManager savienojumus failā /etc/NetworkManager/system-connections). Ņemiet vērā, ka systemd-journald prasa, lai /etc/machine-id atrastos saknes direktorijā (nevis simboliska saite), lai izvairītos no agrīnas startēšanas traucējumiem.
Lai uzzinātu, kas mainās izpildījumā, izmantojiet dracut-overlayroot: pārklāj saknes direktoriju ar tmpfs, un viss uzrakstītais parādās failā /run/overlayroot/u. Pievienojiet moduli failā /usr/lib/dracut/modules.d/, iekļaujiet failā dracut overlayroot un kodola rindā iestatiet overlayroot=1; tādā veidā redzēsiet, kas jāmigrē uz /var.
Noderīgi piemēri: pacman un NetworkManager
Archā tas ir ērti Pārvietojiet Pacman datubāzi uz /usr/lib/pacman lai rootfs vienmēr spoguļotu instalētās pakotnes. Pēc tam novirziet kešatmiņu uz /var/lib/pacman un izveidojiet saiti. Lai mainītu spoguļsarakstu, nepieskaroties saknei, pārvietojiet to uz /var/etc un jebkurā gadījumā izveidojiet saiti.
Ar tīkla pārvaldnieku, pārvietot sistēmas savienojumus uz /var/etc/NetworkManager un saiti no /etc/NetworkManager/system-connections. Tas saglabā saknes indeksu nemainīgu un konfigurāciju tur, kur tai jābūt rakstāmai.
Patiesības konstruēšana un testēšana
No tiešraides, kad viss ir perfekti un uzstādīts root vidē, izveidojiet koku un roothash ar Veritysetup formātsPalaižot, tas izdrukā Root Hash rindiņu, kuru var saglabāt failā roothash.txt. Palaidiet to testēšanai, izmantojot veritysetup: open root-device root verity-device $(cat roothash.txt) un mount /dev/mapper/root.
Ja vēlaties, vispirms ģenerē koku failā (verity.bin) un pēc tam ierakstiet to VERITY nodalījumā. Iegūtais kopums ir: saknes attēls, Verity koks un saknes jaucējkoda (hash), ko piesprausiet sāknēšanas laikā.
Konfigurējiet kodola rindu
Pievienojiet šos parametrus: systemd.verity=1, roothash=contents_of_roothash.txt, systemd.verity_root_data=ROOT-PATH (piemēram, LABEL=OS) un systemd.verity_root_hash=VERITY-PATH (piemēram, LABEL=VERITY). Lai izmantotu stingras politikas, iestatiet systemd.verity_root_options uz restart-on-corruption vai panic-on-corruption.
Citas ieteicamās iespējas: ro (ja neizmantojat EROFS/squashfs), rd.avārijas situācija=pārstartēšana y rd.shell=0 (novērst neatļautas čaulas, ja sāknēšana neizdodas), un karantīna = konfidencialitāte lai aizsargātu kodola atmiņu no piekļuves.
Papildu starpsienas ar patiesumu
Ne tikai sakne: Citas kartēšanas var definēt failā /etc/veritytab un systemd-veritysetup@.service tos apkopos sāknēšanas laikā. Atcerieties: ir vieglāk RW piemontēt ne-root nodalījumu, un root lietotājs varētu atspējot Verity šajās nodalījumos, tāpēc drošības vērtība tur ir zemāka.
Drošība: Secure Boot, UKI un parakstīti moduļi
dm-verity nav brīnumlīdzeklis. Parakstiet UKI un iespējojiet drošo sāknēšanu ar savām atslēgām lai neviens nevarētu ignorēt kernel/initramfs/cmdline (kas ietver root hešu). Tādi rīki kā sbupdate-git vai sbctl palīdz saglabāt attēlus parakstītus un sāknēšanas ķēdi neskartu.
Ja iespējojat kodola bloķēšanu vai moduļa paraksta verifikāciju, DKMS vai ārpus koka esošiem moduļiem jābūt parakstītiem vai arī tie netiks ielādēti. Apsveriet pielāgotu kodolu ar parakstīšanas atbalstu jūsu cauruļvadam (skatiet parakstītos kodola moduļus).
Šifrēšana, TPM un mērīšana
dm-verity aizsargā integritāti, nekonfidencialitāteSaknes lietotāju var nešifrēt, ja tajā nav nekādu noslēpumu un sāknēšanas ķēde ir aizsargāta. Ja saknes lietotāju atslēgu failus izmantojat citu sējumu atbloķēšanai, ieteicams tos šifrēt.
Ar TPM 2.0, systemd-cryptenroll ļauj saistīt atslēgas ar PCR 0,1,5,7 (programmatūra, opcijas, GPT, drošās sāknēšanas statuss). Pievienojiet rd.luks.options=LUKS_UUID=tpm2-device=auto un pārliecinieties, vai initramfs ir iekļauts TPM2 atbalsts. systemd-boot mēra kernel.efi PCR4, kas ir noderīgi atslēgu anulēšanai, ja mainās UKI vai tās cmdline.
Atjauninājumi un izvietošanas modeļi
Pārbaudīta tikai lasāma sakne Tas netiek atjaunināts ar pakotņu pārvaldnieku tradicionālā veidā.Ideālā gadījumā jaunus attēlus var veidot ar tādiem rīkiem kā Yocto projekts un publicējiet tos. systemd ir systemd-sysupdate un systemd-repart stabilai attēlu lejupielādei un pārprogrammēšanai.
Vēl viena stratēģija ir A/B shēmaJūs paturat divas saknes un divas verities. Kopējiet aktīvo sakni uz neaktīvo sakni, lietojiet izmaiņas un atkārtojiet verity. Pārslēdzieties atpakaļ nākamajā startēšanas reizē. Ja izmantojat UKI, atcerieties atjaunināt saknes jaucējkodu cmd rindā vai atjaunot parakstīto UKI.
Papildu noturībai izmantot OverlayFS verificētajā saknē ar augšējo vērtību tmpfs vai diskā. Varat arī nodot systemd.volatile=overlay pagaidu saglabāšanai. Flatpak atvieglo lietotņu instalēšanu /var un /home mapēs, nepieskaroties /.
Ir automatizētas pakotnes (piemēram, verity-squash-root AUR vidē), kas veido squashfs sakni un parakstiet roothash ar kodolu un initramfs, ļaujot izvēlēties starp pastāvīgo vai īslaicīgo režīmu un saglabājot jaunākos rootfs kā dublējumu. Piezīme: pastāvīguma pievienošanai verificētai saknei ir šauri lietošanas gadījumi; mēģiniet saglabāt lietotnes datus atsevišķās nodalījumos.
Android: sistēma kā root, AVB un pārdevēja pārklājumi
Kopš Android 10, RootFS pārstāj darboties RAM diskā un integrējas ar system.img. (sistēma kā root). Ierīces, kas tiek palaistas ar Android 10, vienmēr izmanto šo shēmu un tām ir nepieciešams RAM disks dm-lineārai darbībai. Šajā versijā BOARD_BUILD_SYSTEM_ROOT_IMAGE ir iestatīts uz false, lai atšķirtu RAM diska izmantošanu no tiešas system.img aktivizēšanas.
Android 10 ietver dinamiskas starpsienas un pirmās pakāpes init kas aktivizē loģisko sistēmas nodalījumu; kodols to vairs nepievieno tieši. Tikai sistēmai paredzētām OTA versijām ir nepieciešams sistēmas kā root dizains, kas ir obligāts Android 10 ierīcēs.
Nevienā A/B gadījumā atkopšanu veikt atsevišķi no sāknēšanasAtšķirībā no A/B, nav boot_a/boot_b dublējuma, tāpēc atkopšanas noņemšana no citas versijas, kas nav A/B, var atstāt jūs bez atkopšanas režīma, ja sāknēšanas atjauninājums neizdodas.
Kodols pieslēdz system.img /converity, izmantojot divus ceļus: vboot 1.0 (ielāpi kodolam, lai parsētu Android metadatus /system un iegūtu dm-verity parametrus; komandrinda ietver root=/dev/dm-0, skip_initramfs un init=/init ar dm=…) vai vboot 2.0/AVB, kur sāknēšanas ielādētājs integrē libavb, nolasa heštree deskriptoru (failā vbmeta vai system), konstruē parametrus un nodod tos kodolam cmdline komandrindā ar FEC atbalstu un tādiem karodziņiem kā restart_on_corruption.
Ar sistēmas root piekļuvi, Nelietojiet BOARD_ROOT_EXTRA_FOLDERS ierīcei specifiskām saknes mapēm: tās pazudīs, veicot GSI pārprogrammēšanu. Definējiet konkrētus pieslēgumus sadaļā /mnt/vendor/ , ko fs_mgr izveido automātiski, un atsaucieties uz tiem ierīču koka fstab failā.
Android ļauj pārdevēja pārklājums no /product/vendor_overlay/: init pievienos /vendor apakšdirektorijās esošās apakšdirektorijas, kas atbilst SELinux konteksta prasībām un /vendor/ esamībai. Nepieciešama CONFIG_OVERLAY_FS=yy, vecākiem kodoliem — override_creds=off ielāps.
Tipiska ieviešana: instalē iepriekš kompilētus failus ierīcē/ / /piegādātāja_pārklājums/, pievienojiet tos PRODUCT_COPY_FILES failam ar find-copy-subdir-files failā $(TARGET_COPY_OUT_PRODUCT)/vendor_overlay, definējiet kontekstus file_contexts failos etc un lietotnēm (piemēram, vendor_configs_file un vendor_app_file) un atļaujiet pievienošanu šiem kontekstiem init.te failā. Pārbaudiet ar atest vfs_mgr_vendor_overlay_test failā userdebug.
Problēmu novēršana: dm-verity bojājuma ziņojums operētājsistēmā Android
Ierīcēs ar A/B slotiem nomainiet slotus vai Vbmeta/boot mirgošana bez atbilstības roothash Tas var izraisīt brīdinājumu: dm-verity bojājums, jūsu ierīce nav uzticama. Tādas komandas kā fastboot flash –disable-verity –disable-verification vbmeta vbmeta.img atspējo verifikāciju, bet atstāj sistēmu bez jebkādām integritātes garantijām.
Daži sāknēšanas ielādētāji atbalsta ātrās palaišanas OEM disable_dm_verity un tā pretstats — enable_dm_verity. Tas darbojas dažos modeļos, bet ne citos; un tam var būt nepieciešams kodols/magisk ar pielāgotiem karodziņiem. Lietojiet uz savu atbildību: piesardzīga rīcība ir šāda. izlīdzināt sāknēšanas, vbmeta un sistēmas iestatījumus, parakstiet vai reģenerējiet koku un pārliecinieties, vai paredzētais saknes hešs atbilst konfigurētajam.
Ja pēc brīdinājuma varat turpināt nospiest ieslēgšanas/izslēgšanas pogu, sistēma iedarbojas, bet jums vairs nav neskartas uzticības ķēdesLai noņemtu ziņojumu, neupurējot drošību, atjaunojiet sākotnējos parakstītos attēlus vai atjaunojiet/pārbaudiet vbmeta ar pareizo heštreju, nevis atspējojiet verity.
i.MX un OpenWrt platformas
i.MX6 (piemēram, sabresd) konfigurējiet kodolu ar DM_VERITY un FEC atbalstu, ģenerējiet koku ar veritysetup, droši saglabājiet saknes jaucējkodu un cmd rindā nododiet atbilstošos parametrus vai integrējiet, izmantojot initramfs ar systemd-veritysetup. Ja neizmantojat dm-crypt, jums nav nepieciešams CAAM verity; galvenā uzmanība ir pievērsta integritātei.
OpenWrt un iegultās Linux sistēmas ar OpenEmbedded, Ir centieni integrēt dm-verity un SELinux. (Bootlin darbi pārskatīti ar nolūku iekļaut atbalstu). Tā ir dabiska izvēle: maršrutētāji un tīkla iekārtas gūst labumu no nemaināmas, verificētas un ar MAC adresi aizsargātas saknes.
Manuāla koka un metadatu veidošana (detalizēts skats)
cryptsetup var ģenerēt koku jūsu vietā, bet, ja vēlaties saprast formātu, kompaktajā tabulas rindas definīcijā ir iekļauts: kartēšanas nosaukums, datu ierīce, datu bloks un jaucējkrāna izmēri, attēla izmērs blokos, hash_start pozīcija (bloka attēls + 8, ja savienots), saknes jaucējkoda un sāls. Pēc savienoto slāņu ģenerēšanas (no augšas uz leju, izņemot 0. slāni) koku ierakstāt diskā.
Lai visu iesaiņotu, Izveidojiet dm-verity tabulu, parakstiet to (tipisks RSA-2048) un metadatos grupējiet paraksta+tabulu ar versijas galveni un maģisko numuru. Pēc tam tas apvieno sistēmas attēlu, Verity metadatus un jaucējkoku. Fstab failā tas atzīmē fs_mgr kā verify un ievieto publisko atslēgu failā /boot/verity_key, lai validētu parakstu.
Optimizēt ar SHA-2 paātrinājumi jūsu centrālajam procesoram un pielāgot iepriekšēju lasīšanu/prefetch_cluster. ARM aparatūrā NEON SHA-2 (ARMv7) un SHA-2 paplašinājumi (ARMv8) ievērojami samazina verifikācijas izmaksas.
Jebkurā izvietojumā atcerieties, ka saknes jaucējvērtībai jābūt aizsargātai: neatkarīgi no tā, vai tas ir kompilēts parakstītā UKI, parakstītajā sāknēšanas nodalījumā vai validēts sāknēšanas ielādētājā, izmantojot AVB. Viss pēc šī punkta manto šo uzticamību.
Ar visu iepriekš minēto, dm-verity kļūst par stabils pamats nemainīgām, mobilām un iegultām sistēmām, atbalstot transakciju atjauninājumus, konfigurācijas pārklājumus un modernu drošības modeli, kas samazina uzbrukuma virsmu un novērš noturību, nezaudējot veiktspēju.
