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. Achter dit alles schuilt een belangrijk onderdeel van de kernel: dm-verity, een mechanisme dat is ontworpen om te garanderen dat er niet met het bestandssysteem is geknoeid.noch wanneer het apparaat is ingeschakeld, noch tussen herstarts.

Het lijkt misschien een klein probleem, maar het heeft wel degelijk invloed op alledaagse dingen, zoals het feit dat je telefoon geen stabiele verbinding behoudt. malware verborgen in de systeempartitie, of dat een router Of een "gesloten" server start altijd in dezelfde betrouwbare staat. dm-verity gebruikt een SHA-256-hashstructuur en cryptografische handtekeningen om blok voor blok te verifiëren of de gegevens op de schijf nog steeds zijn zoals ze zouden moeten zijn.En als er iets niet klopt, kan de kernel leesfouten retourneren, de computer opnieuw opstarten of zelfs in paniek raken om te voorkomen dat twijfelachtige code verder 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 die het rootbestandssysteem of een kritieke partitie bevat (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.

Op Android sinds versie 4.4 en op veel moderne Linux-distributies, dm-verity vormt de basis van de geverifieerde bootloader.Dit zorgt ervoor dat de systeempartitie exact hetzelfde is als toen de image werd gemaakt. Hierdoor wordt 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/mapperHierdoor kunnen ze worden aangekoppeld alsof het gewone schijven zijn. Voor de bovengenoemde bestandssystemen (ext4, EROFS, squashfs, enz.) lijkt alles standaard, maar elke leesbewerking doorloopt het cryptografische filter van Verity.

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

In systemen zoals Android, applicaties of binaire bestanden die privileges verkrijgen wortel Ze kunnen zich beter verbergen dan de detectiesystemen zelf.Omdat ze meer bevoegdheden hebben dan antivirus- of beveiligingsprogramma's, kunnen ze "valse" informatie geven over bestanden, processen of configuraties, waardoor ze moeilijker te detecteren en te verwijderen zijn.

Zonder een mechanisme zoals dm-verity, Een aanvaller kan systeembestanden, bibliotheken of opstartscripts aanpassen om persistentie te bereiken.en zo voorkomen dat tools worden ingezet die het mogelijk maken controleer de integriteit van het bestand Ze detecteren de wijziging; dat wil zeggen, ze blijven actief, zelfs als je het apparaat uit- en weer inschakelt. Dat is de klassieke nachtmerrie van hardnekkige rootkits.

dm-verity fungeert als bewaker aan de basis van het systeem: De kernel accepteert alleen die blokken als geldig die voldoen aan de verwachte hash van de controleboom.Als iemand handmatig de systeempartitie heeft gewijzigd, komen de hashes niet meer overeen en zal de kernel dit detecteren zodra deze de gewijzigde gegevens probeert te lezen.

Hoe dm-verity intern werkt

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

Hashboomstructuur

De verificatieboom is opgebouwd uit niveaus. Laag 0 bevat de daadwerkelijke gegevens (bijvoorbeeld de ext4/EROFS-image van het systeem), verdeeld in blokken van 4K.Voor elk van deze blokken wordt een SHA-256-hash berekend (meestal met een willekeurige salt om aanvallen vóór de berekening te bemoeilijken).

De hashes in laag 0 worden samengevoegd om laag 1 te vormen. Laag 1 wordt opnieuw ingedeeld in blokken van 4K en voor elk resulterend blok wordt een SHA-256-hash berekend.Dit levert laag 2 op. Het 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 hele boom vertegenwoordigt.

Wanneer een laag geen volledig blok vult, Het wordt gevuld met nullen totdat het 4K bereikt.Dit voorkomt dubbelzinnigheden en maakt het mogelijk om pogingen te detecteren om de boom te "knippen" door delen te vervangen door willekeurige gegevens: de verwachte structuur omvat die bekende opvulling met nullen.

Op schijf, De boomstructuur wordt opgeslagen door de lagen van boven naar beneden aan elkaar te koppelen (met uitzondering van datalaag 0).De totale omvang van de boom 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 in de loop der tijd veranderd. Versie 0 van het formaat, oorspronkelijk gebruikt door Chromium OS, voegde de salt aan het einde toe tijdens het berekenen van de hash en bewaarde de digests continu.waarbij de rest van het blok met nullen wordt opgevuld.

Versie 1, aanbevolen voor nieuwe systemen. plaatst het zout vóór de gegevens bij het berekenen van de hash. en vult elke hash 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 stamboom handmatig wilt opbouwen, is de algemene opzet duidelijk. Eerst wordt een willekeurige salt in hexadecimale notatie gekozen, de afbeelding wordt verdeeld in blokken van 4K, en voor elk blok wordt de bijbehorende salted SHA-256 berekend.Deze hashes vormen het eerste "logische" niveau bovenop de gegevens.

dan, De hashes worden aan elkaar gekoppeld totdat blokken van 4K gevuld zijn.Als er onvoldoende ruimte is, wordt deze opgevuld met nullen. Elk resulterend blok wordt vervolgens ook gehasht met SHA-256 om het volgende niveau van de boom te vormen. Dit proces van "hashing hashes" wordt herhaald totdat er nog maar één hash over is: de root-hash.

In de praktijk voeren tools zoals cryptsetup/veritysetup al deze berekeningen uit en genereren ze direct de resultaten. het boomstructuurbestand (verity.bin) en de root-hashwaarde (roothash), klaar voor gebruik in de dm-verity-tabel of in de 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 nauwkeurige beschrijving nodig van waar de data zich bevindt, waar de hash-tree zich bevindt en welke parameters gebruikt moeten worden. Die beschrijving is de dm-verity-tabel, een reeks parameters die de device-mapper interpreteert bij het aanmaken van het geverifieerde logische apparaat..

in een typische vereenvoudigde versieDe definitie kan als volgt worden weergegeven:

De belangrijkste velden De dm-verity-tabel bevat doorgaans het volgende:

• 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 basisvakken, Er zijn optionele parameters waarmee de reactie van het systeem op corruptie of fouten kan worden aangepast.U kunt bijvoorbeeld specificeren dat in geval van corruptie het systeem opnieuw moet worden opgestart, er een paniekfout moet worden gegenereerd of dat het probleem moet worden genegeerd en alleen naar het systeem moet worden gelogd. logsof dat het FEC-herstel wordt geactiveerd vóór het falen.

Geavanceerde tabelopties: corruptie, FEC en prestaties

dm-verity bevat een set vlaggen voor het profileren van gedrag. ignore_corruption zorgt ervoor dat het lezen doorgaat, zelfs als er corruptie wordt gedetecteerd, maar laat wel een spoor achter in de logbestanden., nuttig in omgevingen waar beschikbaarheid prioriteit heeft boven strikte integriteit.

Als je op zoek bent naar een strenge aanpak, `restart_on_corruption` of `panic_on_corruption` forceren een herstart of een panic wanneer een blok de verificatie niet doorstaat.Er bestaan ​​vergelijkbare varianten voor I/O-fouten (restart_on_error, panic_on_error). Er is ook een ignore_zero_blocks-optie die het controleren van blokken die naar verwachting nul zijn, overslaat en direct nullen retourneert.

Voor systemen die voorwaartse correctie integreren, `use_fec_from_device` maakt samen met `fec_roots`, `fec_blocks` en `fec_start` het gebruik van Reed-Solomon-codes mogelijk.Met FEC is het mogelijk om, in geval van een verificatiefout, te proberen het blok te reconstrueren met behulp van redundante informatie voordat het als verloren wordt beschouwd.

Andere opties, zoals check_at_most_once, Ze zorgen ervoor dat elk blok alleen de eerste keer dat het wordt benaderd, wordt geverifieerd.Dit vermindert de overhead ten koste van het niet detecteren van live wijzigingen; 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 zijn, moet de hashwaarde van de root betrouwbaar zijn. In klassieke Android-systemen is een publieke sleutel opgenomen in de opstartpartitie, 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 die informatie. Een blok van 32K bevat een magic number, versie, handtekening, tabellengte en inhoud, plus opvulling met nullen.Deze gecontroleerde structuur maakt het mogelijk om de metadata ondubbelzinnig te lokaliseren en te valideren.

Typische velden Deze metadata omvat:

• 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 magische getal niet wordt gevonden bij het analyseren van het einde van de systeemimage, Er wordt vanuit gegaan dat de partitie niet is voorbereid voor verificatie en dat het verificatieproces niet is geactiveerd.Dit voorkomt bijvoorbeeld dat een partitie als geverifieerd wordt beschouwd, terwijl dat niet het geval is.

Op Android fs_mgr en het fstab-bestand bepalen welke partities worden gecontroleerd.Voeg simpelweg het vinkje toe (bijvoorbeeld "verify" in de fs_mgr-vlaggen) en plaats de juiste publieke sleutel in /boot/verity_key om het end-to-end verificatieproces te starten.

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, in mobiel En beveiligde platforms, de root hash en de dm-verity tabel maken deel uit van een vertrouwensketen die begint bij hardware.

Doorgaans brandt de fabrikant een publieke sleutel op het apparaat. Die sleutel valideert de handtekening van de eerste bootloader, die op zijn beurt het volgende niveau controleert, de bootloader van apps en tot slot, de kernelafbeeldingVan daaruit neemt de kernel, die nu geverifieerd is, de controle over en gebruikt dm-verity om dat vertrouwen uit te breiden naar de systeempartitie.

Op moderne Android-apparaten met AVB (Android Verified Boot 2.0), De bootloader bevat libavb en leest hashtree-descriptors in partities of in vbmeta.Met die informatie construeert het de dm-verity-parameters en geeft deze door aan de kernel op de regel van commando's, samen met instructies zoals of er een FEC is, wat te doen in geval van corruptie, enz.

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 systeem-als-root-ontwerp rootfs direct in system.img.waardoor veel klassieke configuraties overbodig worden en dm-verity vanaf de eerste init-fase moet worden afgehandeld.

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

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

Bij apparaten met een A/B-schema kan er gemakkelijk iets misgaan met de uitlijning. Als je boot of vbmeta flasht zonder dat de roothash en de daadwerkelijke systeempartitiestructuur overeenkomen, is het gebruikelijke 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.imgOf, bij sommige fabrikanten, `fastboot oem disable_dm_verity`. Maar wees voorzichtig: Dit schakelt geverifieerd opstarten uit en heft integriteitsgaranties op.zelfs als het je lukt om het op te starten zonder vervelende meldingen.

De "nette" manier om het op te lossen houdt in dat Zorg ervoor dat de systeem-, opstart- en vbmeta-images consistent met elkaar zijn.Genereer (of herstel) de verificatieboom en werk de handtekeningen of beschrijvingen bij, zodat de verwachte root-hash overeenkomt met de werkelijke. Alleen op deze manier kunt u de vertrouwensketen in stand houden zonder Tricks peligros.

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 bij het rooten van hun apparaat. Om TWRP te gebruiken, firmware te flashen of mods te installeren, heb je meestal een ontgrendelde bootloader nodig.omdat het geverifieerde opstartproces voorkomt dat images worden opgestart die niet door de fabrikant zijn ondertekend.

Er zijn procedures die bijvoorbeeld aanbevelen: Installeer eerst een specifieke firmware, start de bootloader opnieuw op en voer commando's uit zoals "fastboot oem disable_dm_verity" gevolgd door "fastboot oem enable_dm_verity".en installeer vervolgens een nieuwere firmware. Deze stappen zijn bedoeld om de Verity-status te "resetten", zodat nieuwe afbeeldingen zonder corruptiemeldingen worden geaccepteerd.

Als je na crashes of foutmeldingen bij elke herstart de waarschuwing "dm-verity corruption" ziet, Het is verstandig om te controleren of het partitiesysteem geen fysieke schade heeft en of de gebruikte afbeeldingen geschikt zijn voor uw model.Soms kan een simpele mismatch tussen modem, bootloader 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 met systemd, wordt het steeds populairder als basis voor zeer betrouwbare, alleen-lezen root-systemen.Het werkt op een vergelijkbare manier als sommige routers, apparaten of mediaboxen.

Een typische root-mount met dm-verity omvat het volgende: een root-image of -partitie, een bestand met de verity-structuur (verity.bin), de root-hashwaarde, de systemd-veritysetup-eenheden en de bijbehorende kernelregelparametersOptioneel kunnen een ondertekende UKI (Unified Kernel Image) en Secure Boot worden toegevoegd om het hele systeem goed te beschermen.

Partitioneringsschema en bestandssysteem

Het gebruikelijke advies is om een ​​specifieke partitie te reserveren voor hashes. Een veelgebruikte configuratie bestaat uit: een EFI-partitie (ESP), een XBOOTLDR-partitie voor de UKIs, een rootpartitie (met of zonder versleuteling), een VERITY-partitie voor de tree, en optioneel beschrijfbare /home- en /var-partities..

In plaats van het klassieke ext4 voor de root, EROFS is een zeer interessante optie.Het is ontworpen als een alleen-lezen geheugenmodule, heeft zeer goede flashprestaties en SSD En het ondersteunt LZ4-compressie direct uit de doos. 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 wel of niet bewerkbaar mogen 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 deze symbolisch te linken vanuit /etc.

Bv NetworkManager-verbindingen kunnen worden verplaatst naar /var/etc/NetworkManager/system-connections en laat een symbolische link staan ​​van /etc/NetworkManager/system-connections. Op deze manier blijft het onveranderlijke root-ontwerp behouden, maar kunnen configuraties die gewijzigd moeten worden, toch nog aangepast worden.

Om te ontdekken wat er daadwerkelijk wordt geschreven tijdens het opstarten en de uitvoering, Je kunt dracut-overlayroot gebruiken, waarmee een tmpfs-overlay bovenop de root wordt gemount en alle daadwerkelijke schrijfbewerkingen worden gelogd in /run/overlayroot/uNadat u het systeem een ​​tijdje hebt gebruikt, kunt u de betreffende map controleren om te zien wat er uit de geverifieerde rootmap moet worden verplaatst.

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

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

De typische stroom Op een Linux-systeem dat dm-verity wil gebruiken voor root-toegang, zou het er als volgt uitzien:

• 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 moet je de kernelopdrachtregel aanpassen. Met systemd worden parameters zoals systemd.verity=1, roothash=…, systemd.verity_root_data=… en systemd.verity_root_hash=… gebruikt.Naast opties zoals systemd.verity_root_options=restart-on-corruption of panic-on-corruption, afhankelijk van de gewenste beveiligingsgraad.

Als er gebruik wordt gemaakt van een UKI, Al deze parameters zijn geïntegreerd in de kernel.efi-image, die is ondertekend en opgestart met Secure Boot.Dit voorkomt dat iemand de roothash via de commandoregel wijzigt 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 integriteit, niet vertrouwelijkheid. Gegevens kunnen worden ingezien als ze niet versleuteld zijn, maar ze kunnen niet worden gewijzigd zonder dat dit wordt opgemerkt.Daarom wordt het vaak gecombineerd met encryptie (LUKS) en een TPM om de sleutels te beschermen.

Een veelgebruikte strategie is Koppel LUKS-ontsleutelingssleutels aan bepaalde TPM PCR's met behulp van systemd-cryptenroll. (bijvoorbeeld PCR 0, 1, 5, 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 verity-controle negeert, zonder tegelijkertijd de decryptieketen te verbreken.

Als systemd-boot wordt gebruikt, De bootloader meet de kernel.efi-image in PCR 4.Als die meting verandert, worden de bijbehorende sleutels niet vrijgegeven en wordt de versleutelde partitie niet geopend. Dit is een extra schakel in de keten om ervoor te zorgen 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 wortel de meest gangbare praktijk is, dm-verity kan worden toegepast op andere partities die bij het opstarten worden aangekoppeld.Op systemen met systemd worden deze extra partities beschreven in /etc/veritytab en automatisch geconfigureerd door systemd-veritysetup@.service.

Een geverifieerde partitie die geen root-toegang heeft, is echter minder veilig: Het is relatief eenvoudig om de lees- en schrijfrechten te herstellen, en een rootgebruiker kan Verity er zelfs op uitschakelen.Desondanks is het handig voor gegevens die u wilt monitoren of voor alleen-lezen afbeeldingen die op andere locaties zijn gekoppeld.

Wat betreft updates: een geverifieerde, alleen-lezen rootmap verandert het denkkader. Van de beheerder wordt niet verwacht dat hij een commando als "pacman -Syu" uitvoert op de productieroot.maar eerder dat er nieuwe beelden van het systeem worden gegenereerd, met de bijbehorende verificatiebomen, en dat deze op transactionele wijze worden ingezet.

Hiervoor bestaan ​​verschillende strategieën: Gebruik tools zoals systemd-sysupdate en systemd-repart om nieuwe images te downloaden en te flashen.Of stel een A/B-schema voor met twee wortels en twee veriteiten, waarbij je de inactieve partitie bijwerkt en vervolgens de rollen verwisselt.

Als je iets flexibeler wilt, De geverifieerde rootmap kan als een onderliggende map op een OverlayFS worden gemount, met een bovenliggende laag op tmpfs of schijf.Wijzigingen worden dus toegepast op de bovenste laag, maar de basis blijft de geverifieerde afbeelding. Je kunt zelfs kiezen voor optionele of tijdelijke persistentie (bijvoorbeeld systemd.volatile=overlay) om "wegwerpsessies" te hebben.

In de desktopwereld worden technologieën zoals Flatpak past goed bij deze filosofie.Ze installeren en updaten applicaties 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 van elkaar te beheren.

Dit hele ecosysteem maakt van dm-verity veel meer dan alleen een curiositeit binnen de kernel: Het vormt de hoeksteen van onveranderlijke, mobiele en ingebedde systemen die altijd in een bekende toestand moeten starten en elke manipulatie ervan moeten detecteren. opslagruimteen integreert met geverifieerd opstarten, Secure Boot, encryptie en TPM om een ​​modern beveiligingsmodel te bieden zonder al te veel in te leveren op prestaties of flexibiliteit.