Wat is dm-verity en hoe beschermt het de systeemintegriteit?

Als je met Android, Linux of embedded systemen werkt, heb je waarschijnlijk wel eens berichten gezien zoals "dm-verity corruption" of gehoord van verified boot, AVB of Secure Boot. Daarachter schuilt een belangrijk onderdeel van de kernel: dm-verity, een mechanisme dat is ontworpen om ervoor te zorgen dat het bestandssysteem niet is gemanipuleerd , zowel tijdens het inschakelen van het apparaat als tussen herstarts.

Het lijkt misschien een onbelangrijk probleem, maar het heeft wel degelijk invloed op alledaagse zaken, zoals het voorkomen dat je telefoon malware bevat die verborgen zit in de systeempartitie, of het garanderen dat een router of een "gesloten" server altijd in dezelfde vertrouwde staat opstart. dm-verity gebruikt een SHA-256-hashboom en cryptografische handtekeningen om blok voor blok te controleren of de gegevens op de schijf nog steeds kloppen . Als er iets niet overeenkomt, kan de kernel leesfouten retourneren, de computer opnieuw opstarten of zelfs in paniek raken om te voorkomen dat er nog meer verdachte code wordt uitgevoerd.

Wat is dm-verity en welk probleem lost het op?

`dm-verity` is een doel van het `device-mapper`-subsysteem van de Linux-kernel waarmee de integriteit van een blokapparaat in realtime kan worden geverifieerd. Dit is doorgaans een partitie of image met het rootbestandssysteem of een kritieke partitie (bijvoorbeeld `/system` op Android). In plaats van de schijf "blindelings" te lezen, wordt elk benaderd blok cryptografisch gecontroleerd aan de hand van een vooraf berekende hashstructuur.

In Android sinds versie 4.4 en in veel moderne Linux-distributies vormt dm-verity de basis van verified boot : het zorgt ervoor dat de systeempartitie exact hetzelfde is als toen de image werd aangemaakt. Dit maakt het voor een rootkit of ander type malware moeilijk om na een herstart actief te blijven door schadelijke bestanden of binaire programma's in het systeem te injecteren.

Een van de voordelen van deze aanpak is dat dm-verity-apparaten verschijnen als normale blokapparaten onder /dev/mapper , waardoor ze net als elke andere schijf kunnen worden aangekoppeld. Voor het onderliggende bestandssysteem (ext4, EROFS, squashfs, enz.) lijkt alles standaard, maar elke leesbewerking wordt gefilterd door het cryptografische filter van Verity.

Waarom dit nodig is: malware met root-toegang en vertrouwde opstartopties.

In systemen zoals Android kunnen applicaties of binaire bestanden die rootrechten verkrijgen zich beter verbergen dan detectiesystemen . Doordat ze meer rechten hebben dan antivirus- of beveiligingsprogramma's, kunnen ze "liegen" over bestanden, processen of configuraties, waardoor ze moeilijker te detecteren en te verwijderen zijn.

Zonder een mechanisme zoals dm-verity kan een aanvaller systeembestanden, bibliotheken of opstartscripts wijzigen om persistentie te bereiken , waardoor tools voor bestandsintegriteitscontrole de wijziging niet kunnen detecteren; met andere woorden, de wijziging blijft actief, zelfs nadat het apparaat is uit- en weer ingeschakeld. Dit is de klassieke nachtmerrie van persistente rootkits.

dm-verity fungeert als een bewaker aan de basis van het systeem: de kernel accepteert alleen die blokken als geldig die overeenkomen met de verwachte hash uit de verificatiestructuur . Als iemand de systeempartitie zonder toestemming heeft gewijzigd, komen de hashes niet meer overeen en detecteert de kernel dit zodra deze probeert de gewijzigde gegevens te lezen.

Hoe dm-verity intern werkt

Het basisidee is eenvoudig maar krachtig: een cryptografische boom van hashes (meestal SHA-256) wordt hiërarchisch opgebouwd over alle blokken op het apparaat. Deze boom wordt op de schijf opgeslagen en wordt tijdens normaal gebruik gebruikt om elk gelezen blok te valideren.

Hashboomstructuur

De verificatiestructuur is opgebouwd uit lagen. Laag 0 bevat de daadwerkelijke gegevens (bijvoorbeeld de ext4/EROFS-systeemimage), verdeeld in blokken van 4 KB . Voor elk van deze blokken wordt een SHA-256-hash berekend (meestal met een willekeurige salt om aanvallen met voorberekening te voorkomen).

De hashes van laag 0 worden samengevoegd tot laag 1. Laag 1 wordt vervolgens gegroepeerd in blokken van 4K en voor elk resulterend blok wordt een SHA-256-hash berekend , wat resulteert in laag 2. Dit proces wordt laag voor laag herhaald totdat de volledige set hashes in één blok past; de hash van dat laatste blok is de root-hash, die de gehele boom vertegenwoordigt.

Wanneer een laag geen volledig blok vult, wordt deze aangevuld met nullen totdat 4K is bereikt . Dit voorkomt dubbelzinnigheden en maakt het mogelijk om pogingen tot "snoeien" van de boom door delen te vervangen door willekeurige gegevens te detecteren: de verwachte structuur omvat deze bekende aanvulling met nullen.

Op de schijf wordt de boomstructuur opgeslagen door de lagen van boven naar beneden aan elkaar te koppelen (met uitzondering van datalaag 0) . De totale grootte van de boomstructuur varieert afhankelijk van de grootte van de gecontroleerde partitie, maar in de praktijk is deze meestal vrij klein, doorgaans minder dan 30 MB, zelfs voor grote systeempartities.

Formaatversies en hash-algoritmen

Het formaat waarin hashblokken worden opgeslagen, is geëvolueerd. Versie 0 van het formaat, oorspronkelijk gebruikt door Chromium OS, voegde de salt toe aan het einde bij het berekenen van de hash en bewaarde de digests continu , waarbij de rest van het blok werd opgevuld met nullen.

Versie 1, aanbevolen voor nieuwere systemen, voegt een zoutwaarde toe aan de hash vóór de data en vult elke digest aan tot een macht van twee. Dit verbetert de uitlijning en de robuustheid tegen bepaalde soorten aanvallen of corruptie. De dm-verity-tabel geeft ook aan welk algoritme is gebruikt (sha1, sha256, enz.), hoewel het tegenwoordig verstandig is om SHA-256 te gebruiken.

Stapsgewijze berekening van de root-hash

Als je de boom handmatig wilt opbouwen, is het algemene schema duidelijk. Eerst kies je een willekeurige salt in hexadecimale notatie, verdeel je de afbeelding in blokken van 4K en bereken je voor elk blok de bijbehorende salted SHA-256-hash . Deze hashes vormen het eerste "logische" niveau boven de data.

Vervolgens worden de hashes samengevoegd totdat blokken van 4K gevuld zijn ; als er onvoldoende ruimte is, worden nullen toegevoegd. Elk resulterend blok wordt ook gehasht met SHA-256 om het volgende niveau van de boom te vormen. Dit proces van "hash op hashes" wordt herhaald totdat er slechts één hash overblijft: de root-hash.

In de praktijk voeren tools zoals cryptsetup/veritysetup al deze berekeningen uit en genereren ze direct het boomstructuurbestand (verity.bin) en de root-hashwaarde (roothash) , die direct gebruikt kunnen worden in de dm-verity-tabel of in ondertekende metadata.

De dm-verity-tabel: een beschrijving van wat en hoe te verifiëren

Om dm-verity te kunnen gebruiken, heeft de kernel een precieze beschrijving nodig van waar de data zich bevindt, waar de hash-structuur is opgeslagen en welke parameters moeten worden gebruikt. Die beschrijving is de dm-verity-tabel, een regel met parameters die de device-mapper interpreteert bij het aanmaken van het geverifieerde logische apparaat.

In een typische, vereenvoudigde versie kan de definitie als volgt worden weergegeven:

<mappingnaam> <dataapparaat> <datablokgrootte> <hashblokgrootte> <afbeeldingsgrootte in blokken> <hash_start> <root-hash> <salt>

De belangrijkste velden in de dm-verity-tabel zijn doorgaans:

• dev: apparaat dat de te verifiëren gegevens bevat (bijvoorbeeld een /dev/sdXN-partitie of een major:minor-paar).
• hash_dev: apparaat dat de hashboom opslaat; dit kan hetzelfde zijn als dev, zolang hash_start maar buiten het bereik van de geverifieerde gegevens wijst.
• data_block_grootte: grootte van het datablok in bytes, doorgaans 4096.
• hash_block_grootte: blokgrootte voor hashes, die is meestal ook 4096.
• num_data_blokken: aantal te beschermen datablokken.
• hash_start_blok: offset in blokken vanaf het begin van het apparaat tot waar de hashboom begint.
• algoritme: hash-algoritme (sha256 is de de facto standaard).
• samenvatting (root hash): hash van het rootblok van de boom, uitgedrukt in hexadecimaal; dit is het vertrouwde "anker".
• zout: zoutwaarde die wordt gebruikt bij het berekenen van hashes, ook in hexadecimale vorm.

Naast deze basisvelden zijn er optionele parameters die bepalen hoe het systeem reageert op corruptie of fouten . U kunt bijvoorbeeld specificeren dat het systeem in geval van corruptie opnieuw moet opstarten, in paniek moet raken, genegeerd moet worden en alleen gelogd moet worden , of dat FEC-herstel moet worden geactiveerd vóór een storing.

Geavanceerde tabelopties: corruptie, FEC en prestaties

dm-verity bevat een set vlaggen voor het profileren van gedrag. ignore_corruption maakt het mogelijk om door te lezen, zelfs als corruptie wordt gedetecteerd, maar laat een spoor achter in de logbestanden . Dit is handig in omgevingen waar beschikbaarheid prioriteit heeft boven strikte integriteit.

Voor strengere handhaving dwingen `restart_on_corruption` of `panic_on_corruption` een herstart of een panic af wanneer een blok de verificatie niet doorstaat . Vergelijkbare varianten bestaan ​​voor I/O-fouten (`restart_on_error`, `panic_on_error`). Er is ook een `ignore_zero_blocks`-optie die het verifiëren van blokken die naar verwachting nul zijn, overslaat en direct nullen retourneert.

Voor systemen die gebruikmaken van forward correction, maken `use_fec_from_device` samen met `fec_roots`, `fec_blocks` en `fec_start` het gebruik van Reed-Solomon-codes mogelijk . Met FEC kan, in geval van een verificatiefout, een poging worden gedaan om het blok te reconstrueren met behulp van redundante informatie voordat het wordt verworpen.

Andere opties, zoals `check_at_most_once`, zorgen ervoor dat elk blok slechts de eerste keer dat het wordt benaderd, wordt gecontroleerd. Dit vermindert de overhead, maar detecteert geen wijzigingen die tijdens het proces plaatsvinden; het is een afweging tussen beveiliging en prestaties. Vlaggen zoals `root_hash_sig_key_desc` stellen de kernel in staat om een ​​PKCS7-handtekening van de root-hash te valideren met behulp van sleutels die in de sleutelring zijn opgeslagen.

Handtekening, metadata en verificatienummer

Om alles logisch te laten verlopen, moet de root-hashwaarde betrouwbaar zijn. In klassieke Android-systemen wordt een publieke sleutel in de opstartpartitie opgenomen, en de fabrikant is verantwoordelijk voor de externe verificatie ervan . Deze sleutel wordt gebruikt om de handtekening van de root-hash of de dm-verity-tabel te valideren, zodat wordt gegarandeerd dat de hashstructuur niet is gemanipuleerd.

De metadata van Verity bevat deze informatie. Een blok van 32 KB bevat een magic number, versie, handtekening, tabellengte en inhoud, plus nulopvulling . Deze gecontroleerde structuur maakt het mogelijk om de metadata eenduidig ​​te lokaliseren en te valideren.

Typische velden in deze metadata zijn onder andere:

• Magisch getal: vaste waarde 0xb001b001, gebruikt door componenten zoals fs_mgr om te herkennen dat het een geldig verity-blok is.
• VersieMomenteel is de waarde 0; deze wordt gebruikt om toekomstige formaatwijzigingen door te voeren.
• Signature / Firma: dm-verity tabelhandtekening, meestal PKCS1.5 met een RSA-2048 (256 bytes) sleutel.
• TafellengteGrootte in bytes van de dm-verity-tabel die hieronder is opgeslagen.
• Tabla: de geserialiseerde dm-verity-tabel zelf.
• Vulling: nullen totdat de 32.000 bytes van het blok zijn voltooid.

Als het magic number niet wordt gevonden bij het analyseren van het einde van de systeemimage, wordt aangenomen dat de partitie niet gereed is voor verificatie en wordt het verificatieproces niet geactiveerd . Dit voorkomt bijvoorbeeld dat een partitie als geverifieerd wordt beschouwd terwijl dit niet het geval is.

In Android bepalen fs_mgr en het fstab-bestand welke partities worden geverifieerd . Voeg eenvoudig de verificatievlag toe (bijvoorbeeld "verify" in de fs_mgr-vlaggen) en plaats de juiste publieke sleutel in /boot/verity_key om het volledige verificatieproces te activeren.

Hoe het verband houdt met de geverifieerde startup

dm-verity zou weinig nut hebben als een aanvaller een aangepaste kernel of bootloader zou kunnen inbouwen die alles accepteert. Daarom maken de root-hash en de dm-verity-tabel op mobiele apparaten en beveiligde platforms deel uit van een vertrouwensketen die begint op hardwareniveau.

Doorgaans brandt de fabrikant een publieke sleutel op het apparaat. Deze sleutel valideert de handtekening van de eerste bootloader, die op zijn beurt het volgende niveau, de app- bootloader , en uiteindelijk de kernelimage verifieert . Vanaf dat moment neemt de geverifieerde kernel de controle over en gebruikt dm-verity om dat vertrouwen uit te breiden naar de systeempartitie.

In moderne Android-systemen met AVB (Android Verified Boot 2.0) gebruikt de bootloader libavb en leest hashtree-beschrijvingen uit partities of vbmeta . Aan de hand van deze informatie construeert de bootloader de dm-verity-parameters en geeft deze via de commandoregel door aan de kernel , samen met instructies zoals of FEC aanwezig is, wat te doen in geval van corruptie, enzovoort.

dm-verity op Android: meldingen over systeem-als-root, AVB en corruptie

Android maakt al jaren gebruik van dm-verity. Sinds Android 4.4 wordt het gebruikt als basis voor geverifieerd opstarten, en vanaf Android 10 integreert het 'system-as-root'-ontwerp rootfs direct in system.img , waardoor veel klassieke mounts overbodig worden en dm-verity vanaf de eerste init-fase moet worden afgehandeld.

Met system-as-root en moderne OTA-updates is de systeempartitie doorgaans alleen-lezen en beschermd door een geverifieerde hashtree . De kernel bekijkt deze via een dm-verity-apparaat, wat transparant is voor de bovenliggende Android-laag.

Slots A/B, vbmeta en “dm-verity corruption”-fouten

Bij apparaten met een A/B-schema kan er vrij gemakkelijk iets misgaan. Als je boot of vbmeta flasht zonder dat de roothash en de daadwerkelijke systeempartitiestructuur overeenkomen, is het typische resultaat de gevreesde melding "dm-verity corruption, your device is not trusted".

Om de verificatie te omzeilen, zijn er commando's zoals `fastboot flash --disable-verity --disable-verification vbmeta vbmeta.img` of, voor sommige fabrikanten, `fastboot oem disable_dm_verity`. Wees echter voorzichtig: dit schakelt geverifieerd opstarten uit en heft de integriteitsgaranties op , zelfs als u erin slaagt op te starten zonder vervelende foutmeldingen.

De "nette" manier om dit op te lossen houdt in dat de systeem-, opstart- en vbmeta-images consistent met elkaar zijn , dat de verity-structuur opnieuw wordt gegenereerd (of hersteld) en dat de signatures of descriptors worden bijgewerkt zodat de verwachte root-hash overeenkomt met de werkelijke. Alleen op deze manier kunt u de vertrouwensketen behouden zonder uw toevlucht te nemen tot gevaarlijke trucs.

Relatie met TWRP, ontgrendelde bootloader en mods

In de praktijk komen veel mensen dm-verity tegen bij het installeren van ROM's, aangepaste kernels of het rooten van hun apparaten. Om te experimenteren met TWRP, firmware te flashen of mods te installeren, is een ontgrendelde bootloader meestal nodig, omdat verified boot voorkomt dat er opgestart kan worden vanaf niet-ondertekende bootimages.

Sommige procedures raden bijvoorbeeld aan om eerst een specifieke firmware te flashen, opnieuw op te starten in de bootloader-modus en commando's uit te voeren zoals "fastboot oem disable_dm_verity" gevolgd door "fastboot oem enable_dm_verity" , en vervolgens een nieuwere firmware te installeren. Deze stappen zijn bedoeld om de verity-status te "resetten", zodat nieuwe images zonder corruptiefouten worden geaccepteerd.

Als je na crashes of flashfouten bij elke herstart de melding "dm-verity corruption" ziet, is het verstandig om te controleren of het partitiesysteem niet fysiek beschadigd is en of de gebruikte images geschikt zijn voor jouw model . Soms kan een simpele mismatch tussen de modem-, boot- en systeemfirmware het geverifieerde opstartproces verstoren.

dm-verity op Linux-desktops en -servers (systemd, veritysetup)

dm-verity is niet exclusief voor Android. In moderne Linux-distributies, met name in combinatie met systemd, wordt het steeds populairder als basis voor zeer betrouwbare, alleen-lezen root-systemen , vergelijkbaar met de werking van sommige routers, apparaten of mediaboxen.

Een typische root-mount met dm-verity omvat: een root-image of -partitie, een bestand met de verity-structuur (verity.bin), de root-hashwaarde, de systemd-veritysetup-eenheden en de juiste kernelregelparameters . Optioneel worden een ondertekende UKI (Unified Kernel Image) en Secure Boot toegevoegd om het systeem verder te beveiligen.

Partitioneringsschema en bestandssysteem

Het gebruikelijke advies is om een ​​specifieke partitie te reserveren voor hashes. Een veelvoorkomende indeling bestaat uit: een EFI-partitie (ESP), een XBOOTLDR-partitie voor UKI's, een root-partitie (met of zonder versleuteling), een VERITY-partitie voor de tree, en optioneel beschrijfbare /home- en /var-partities.

In plaats van het klassieke ext4 voor root, is EROFS een zeer interessante optie : het is van nature alleen-lezen, presteert uitstekend op flashgeheugen en SSD's en ondersteunt standaard lz4-compressie. Het is geen toeval dat het veelvuldig wordt gebruikt op Android-telefoons in combinatie met dm-verity.

Bestanden die geschreven moeten worden en veelgebruikte trucs

Als de hoofdmap alleen-lezen is aangekoppeld, moet u zorgvuldig overwegen welke bestanden bewerkbaar moeten zijn. Veel programma's verwachten te kunnen schrijven naar /etc, /var of vergelijkbare paden . In plaats van /etc volledig beschrijfbaar te maken, is het efficiënter om alleen de noodzakelijke bestanden naar /var/etc te verplaatsen en er symbolisch naar te linken vanuit /etc.

Zo kunnen NetworkManager-verbindingen bijvoorbeeld worden verplaatst naar /var/etc/NetworkManager/system-connections en kan er een symbolische link naar /etc/NetworkManager/system-connections worden achtergelaten. Dit doorbreekt het onveranderlijke root-ontwerp niet, maar configuraties die moeten worden gewijzigd, kunnen nog steeds worden aangepast.

Om te ontdekken wat er daadwerkelijk wordt geschreven tijdens het opstarten en de uitvoering, kunt u `dracut-overlayroot` gebruiken. Dit programma koppelt een tmpfs-overlay bovenop de rootdirectory en registreert alle daadwerkelijke schrijfbewerkingen in `/run/overlayroot/u` . Nadat u het systeem een ​​tijdje hebt gebruikt, kunt u deze directory inspecteren om te zien wat er uit de geverifieerde rootdirectory moet worden verplaatst.

In Arch Linux is het ook gebruikelijk om de pacman-database naar /usr/lib/pacman en de cache naar /var/lib/pacman te verplaatsen , zodat de root-image altijd de "verzegelde" status van het systeem weerspiegelt, terwijl synchronisatie- en updatebewerkingen in beschrijfbare gebieden worden uitgevoerd.

Het creëren van de verity en het configureren van het opstartproces met systemd

De gebruikelijke workflow op een Linux-systeem dat dm-verity als root wil gebruiken, ziet er als volgt uit:

• Start op vanuit een live-omgeving en koppel de hoofdmap als alleen-lezen., zodra het systeem precies zo is achtergelaten als u het wilt hebben "bevroren".
• Voer `veritysetup format root-device verity-device` uit om de hashstructuur en de root-hash te genereren.Het commando print doorgaans de regel met de root-hash, die wordt opgeslagen in een bestand (bijvoorbeeld roothash.txt).
• Test de mapping met VeritySetup Open., waarbij een geverifieerde /dev/mapper/root wordt aangemaakt en gemount om te controleren of alles werkt.

Vervolgens moeten we de kernelopdrachtregel aanpassen. Met systemd gebruiken we parameters zoals systemd.verity=1, roothash=…, systemd.verity_root_data=… en systemd.verity_root_hash=… , evenals opties zoals systemd.verity_root_options=restart-on-corruption of panic-on-corruption, afhankelijk van de gewenste beveiligingsgraad.

Als een UKI wordt gebruikt, worden al deze parameters geïntegreerd in de kernel.efi-image, die wordt ondertekend en opgestart met Secure Boot . Dit voorkomt dat iemand de roothash via de commandoregel kan wijzigen zonder de handtekening ongeldig te maken, waardoor het vertrouwensmodel behouden blijft.

Secure Boot, encryptie en TPM: de puzzelstukjes op hun plaats laten vallen.

dm-verity garandeert alleen de integriteit, niet de vertrouwelijkheid. Gegevens kunnen worden ingezien als ze niet versleuteld zijn, maar ze kunnen niet worden gewijzigd zonder dat dit wordt gedetecteerd . Daarom wordt het vaak gecombineerd met versleuteling (LUKS) en een TPM om de sleutels te beschermen.

Een veelgebruikte strategie is om LUKS-ontsleutelingssleutels te koppelen aan specifieke TPM PCR's met behulp van systemd-cryptenroll (bijvoorbeeld PCR's 0, 1, 5 en 7), zodat het wijzigen van de firmware, de partitie-indeling of de Secure Boot-status de sleutels ongeldig maakt. Dit voorkomt dat een aanvaller Secure Boot uitschakelt om een ​​kernel te installeren die de verificatie negeert, zonder tegelijkertijd de ontsleutelingsketen te verbreken.

Als systemd-boot wordt gebruikt, meet de bootloader de kernel.efi-image in PCR 4. Als deze meting verandert, worden de bijbehorende sleutels niet vrijgegeven en wordt de versleutelde partitie niet geopend. Dit is een extra schakel om te garanderen dat de kernel, initramfs en cmdline (inclusief roothash) niet zijn gemanipuleerd.

Gebruik buiten de hoofdmap: andere partities, overlays en updates

Hoewel het beschermen van de rootpartitie de meest gangbare praktijk is, kan dm-verity ook worden toegepast op andere partities die bij het opstarten worden aangekoppeld . Op systemen die systemd gebruiken, worden deze extra partities beschreven in /etc/ veritytab en automatisch geconfigureerd.

Een geverifieerde niet-rootpartitie is echter minder veilig: er kan relatief eenvoudig naar een rootpartitie worden gelezen en geschreven, en een rootgebruiker kan Verity erop uitschakelen . Desondanks is het nuttig voor gegevens die u wilt bewaken of voor alleen-lezen-images die elders zijn gemount.

Wat betreft updates, een geverifieerde, alleen-lezen root verandert de denkwijze. Van de beheerder wordt niet langer verwacht dat hij commando's zoals "pacman -Syu" uitvoert op de productieroot ; in plaats daarvan worden nieuwe systeemimages gegenereerd, samen met de bijbehorende verity-trees, en transactioneel geïmplementeerd.

Hiervoor zijn verschillende strategieën mogelijk: het gebruik van tools zoals systemd-sysupdate en systemd-repart om nieuwe images te downloaden en te flashen , of het opzetten van een A/B-schema met twee root- en twee verity-partities, waarbij je de inactieve partitie bijwerkt en vervolgens de rollen verwisselt.

Voor meer flexibiliteit kunt u de geverifieerde root als een onderliggende map op een OverlayFS mounten, met een bovenliggende laag op tmpfs of schijf . Op deze manier worden wijzigingen toegepast op de bovenliggende laag, maar blijft de basis de geverifieerde image. U kunt zelfs kiezen voor optionele of tijdelijke persistentie (bijv. systemd.volatile=overlay) om "wegwerpsessies" te hebben.

In de desktopwereld passen technologieën zoals Flatpak goed bij deze filosofie , omdat ze applicaties installeren en bijwerken in /var en /home zonder de door verity beschermde rootdirectory aan te raken. Dit zorgt voor een onveranderlijk basissysteem en maakt het mogelijk om applicaties onafhankelijk te beheren.

Dit complete ecosysteem maakt van dm-verity veel meer dan een curiositeit in de kernel: het vormt de hoeksteen van onveranderlijke, mobiele en embedded systemen die altijd in een bekende staat moeten opstarten, elke manipulatie van de opslag moeten detecteren en integreert met verified boot, Secure Boot, encryptie en TPM om een ​​modern beveiligingsmodel te bieden zonder al te veel in te leveren op prestaties of flexibiliteit.