Hvis du er bekymret for systemets integritet, dm-verity er en av nøkkeldelene i Linux-økosystemet. for å starte opp trygt og oppdage lagringsmanipulering. Det oppsto som en del av kjernens enhetskartlegger og er nå grunnlaget for verifisert oppstart i Android, OpenWrt og distribusjoner som søker forbedret sikkerhet.
Langt fra å være et abstrakt konsept, dm-verity er konfigurert og brukt med ekte verktøy som veritysetup og systemd-veritysetupDen validerer blokker underveis ved hjelp av hash-trær og kan reagere på korrupsjon med policyer som spenner fra å logge hendelsen til å starte på nytt eller krasje systemet. La oss ta en nærmere titt, uten å legge igjen noen løse tråder.
Hva er dm-verity og hvorfor du kanskje bryr deg
dm-verity er et enhetstilordningsmål i kjernen som verifiserer integriteten til en blokkenhet når data lesesDet fungerer ved å beregne og verifisere hash-verdier for hver blokk (vanligvis 4K) mot et forhåndsberegnet hash-tre, vanligvis ved bruk av SHA-256.
Denne designen gir mulighet for Filer kan ikke endres stille mellom omstarter eller under kjøringDet er nøkkelen til å utvide oppstartskjeden av tillit til operativsystemet, begrense vedvarende skadelig programvare, styrke sikkerhetspolicyer og sikre kryptering og MAC-mekanismer under oppstart.
På Android (siden 4.4) og Linux generelt, Tillit er forankret i roten av treet, som er signert og validert med en offentlig nøkkel plassert på et beskyttet sted (f.eks. på oppstartspartisjonen eller i en Secure Boot-signert UKI). Å bryte en hvilken som helst blokk vil kreve at den underliggende kryptografiske hashen brytes.
Verifisering gjøres per blokk og på forespørsel: Den ekstra latensen er minimal sammenlignet med I/O-kostnadenHvis en sjekk mislykkes, returnerer kjernen en I/O-feil, og filsystemet ser ut til å være ødelagt, noe som er forventet når dataene er upålitelige. Apper kan bestemme om de vil fortsette eller ikke basert på feiltoleransen sin.
Hvordan verifiseringstreet fungerer internt
Verifiseringstreet er bygget i lag. Lag 0 er rådataene fra enheten, delt inn i 4K-blokker; en SHA-256 (saltet) hash beregnes for hver blokk. Disse hashene settes deretter sammen for å danne lag 1. Lag 1 grupperes deretter i blokker og hashes på nytt for å danne lag 2, og så videre til alt passer inn i én enkelt blokk: den blokken, når den hashes, produserer rot-hashen.
Hvis et lag ikke fullfører en blokk nøyaktig, Den er utfylt med nuller til den når 4K for å unngå tvetydighet. Den totale størrelsen på treet avhenger av størrelsen på partisjonen som kontrolleres; i praksis er den vanligvis mindre enn 30 MB for typiske systempartisjoner.
Den generelle prosessen er: velg et tilfeldig salt, hash til 4K, beregn SHA-256 med salt per blokk, sammenkobler for å danne nivåer, fyller ut blokkgrensen med nuller og gjentar med det forrige nivået til en enkelt rot-hash er igjen. Denne rot-hashen, sammen med saltet som brukes, mater dm-verity-tabellen og signaturen.
Diskformatversjoner og algoritme
Formatet til hashblokker på disk har en versjon. Versjon 0 var den opprinnelige versjonen som ble brukt i Chromium OSSaltet tilsettes på slutten av hashprosessen, digestene lagres kontinuerlig, og resten av blokken fylles med nuller.
La Versjon 1 anbefales for nye enheterSaltet legges til hashen, og hver digest fylles ut med nuller opp til potenser av to, noe som forbedrer justering og robusthet. dm-verity-tabellen spesifiserer også algoritmen (f.eks. sha1 eller sha256), men for nåværende sikkerhet brukes sha256.
dm-verity-tabellen og viktige parametere
Måltabellen dm-verity beskriver hvor dataene er, hvor hash-treet er, og hvordan man verifisererTypiske tabellfelt:
- dev: enhet med dataene som skal verifiseres (stitype /dev/sdXN eller større:mindre).
- hash_dev: enhet med hash-treet (kan være det samme; i så fall må hash_start være utenfor det avmerkede området).
- data_blokk_størrelse: datablokkstørrelse i byte (f.eks. 4096).
- hash_block_size: hash-blokkstørrelse i byte.
- antall_datablokkerantall verifiserbare datablokker.
- hash_start_block: forskyvning (i hash_block_size-blokker) til rotblokken til treet.
- algoritme: hash-algoritme (f.eks. sha256).
- fordøye: heksadesimal koding av rotblokk-hashen (inkludert salt i henhold til formatversjonen); denne verdien er den du skal stole på.
- salt: heksadesimalt salt.
I tillegg er det valgfrie parametere veldig nyttig for å justere atferd:
- ignorer_korrupsjonRegistrerer korrupte blokker, men lar lesingen fortsette.
- omstart_ved_korrupsjon: start på nytt ved korrupsjonsdeteksjon (ikke kompatibel med ignore_corruption og krever støtte for brukerområde for å unngå løkker).
- panikk_på_korrupsjon: : forårsaker panikk når det oppdages korrupsjon (ikke kompatibel med tidligere versjoner).
- omstart_ved_feil y panikk_ved_feilsamme reaksjoner, men for I/O-feil.
- ignorer_null_blokker: sjekker ikke blokker som forventes som nuller og returnerer nuller.
- bruk_fec_fra_enhet + fec_roots + fec_blokker + fec_startAktiver Reed–Solomon (FEC) til å gjenopprette data når verifiseringen mislykkes; data-, hash- og FEC-områdene må ikke overlappe, og blokkstørrelsene må samsvare.
- sjekk_høyst_én_gangSjekker hver datablokk kun første gang den leses (reduserer overhead på bekostning av sikkerhet i live-angrep).
- root_hash_sig_key_descReferanse til en nøkkel i nøkkelringen for å validere en PKCS7-signatur for rot-hashen når tilordningen opprettes (krever riktig kjernekonfigurasjon og klarerte nøkkelringer).
- try_verify_in_taskletHvis hashene er mellomlagret og I/O-størrelsen tillater det, kontrolleres den nederste halvdelen for å redusere latens; justert med /sys/module/dm_verity/parameters/use_bh_bytes per I/O-klasse.
Signatur, metadata og tillitsforankring
For at dm-verity skal være pålitelig, Rot-hashen må være klarert og vanligvis signertI klassisk Android er en offentlig nøkkel inkludert i oppstartspartisjonen, som verifiseres eksternt av produsenten; den validerer rot-hash-signaturen og sikrer at systempartisjonen ikke har blitt endret.
Verity-metadata legger til struktur og versjonskontroll. Metadatablokken inneholder et magisk tall 0xb001b001 (byte b0 01 b0 01), versjon (for tiden 0), tabellsignaturen i PKCS1.5 (vanligvis 256 byte for RSA-2048), tabelllengden, selve tabellen og null utfylling opptil 32K.
I Android-implementeringer er verifisering avhengig av fs_mgr og fstabLegger til et hakemerke for den tilhørende oppføringen og plasserer nøkkelen i /boot/verity_key. Hvis det magiske tallet ikke er der det skal være, stopper verifiseringen for å unngå å sjekke feil ting.
Startoperasjon bekreftet
Beskyttelsen ligger i kjernen: Hvis den blir kompromittert før kjernen starter opp, beholder angriperen kontrollenDerfor validerer produsenter vanligvis strengt hvert trinn: en nøkkel som er brent inn i enheten verifiserer den første oppstartslasteren, som verifiserer den neste, appens oppstartslaster, og til slutt kjernen.
Med kjernen verifisert, dm-verity er aktivert når den verifiserte blokkenheten monteresI stedet for å hashe hele enheten (noe som ville være treg og sløse med energi), verifiseres den blokk for blokk etter hvert som den aksesseres. En feil forårsaker en I/O-feil, og tjenester og apper reagerer i henhold til toleransen sin: enten fortsetter de uten disse dataene eller krasjer fullstendig.
Fremoverrettet feilkorreksjon (FEC)
Siden Android 7.0, FEC (Reed–Solomon) er innlemmet med sammenflettingsteknikker for å redusere plass og øke muligheten til å gjenopprette skadede blokker. Dette fungerer sammen med dm-verity: hvis en sjekk mislykkes, kan delsystemet forsøke å korrigere den før den erklæres uopprettelig.
Ytelse og optimalisering
For å redusere påvirkningen: Aktiver SHA-2-akselerasjon med NEON på ARMv7 og SHA-2-utvidelser på ARMv8 fra kjernen. Juster read-ahead- og prefetch_cluster-parametere for maskinvaren din; verifisering per blokk bidrar vanligvis lite til I/O-kostnaden, men disse innstillingene utgjør en forskjell.
Komme i gang med Linux (systemd, veritysetup) og Android
På en moderne Linux med systemd, dm-verity tillater en verifisert skrivebeskyttet rot ved hjelp av veritysetup (del av cryptsetup), systemd-veritysetup.generator og systemd-veritysetup@.service. Det anbefales å inkludere sikker oppstart og en signert UKI (enhetlig kjerneavbildning), selv om de ikke er strengt tatt påkrevd.
Forberedelse og anbefalt partisjonering
Del av et funksjonelt og justert system. Reserver et volum for hash-treet (8–10 % av rotstørrelsen er vanligvis nok) og vurder å separere /home og /var hvis du trenger å skrive. Et typisk opplegg inkluderer: ESP (for bootloader), XBOOTLDR (for UKI-er), root (med eller uten kryptering), VERITY-partisjon, og eventuelt /home og /var.
Som en rot, EROFS er et veldig interessant alternativ til ext4 eller squashfsDen er skrivebeskyttet i design, med svært god ytelse på flash/SSD, lz4-komprimering som standard, og mye brukt på Android-telefoner med dm-verity.
Filer som må være skrivbare
Med root ro forventer noen programmer å skrive til /etc eller under initDu kan flytte den til /var/etc og legge til en symlink til alt som må endres (f.eks. NetworkManager-tilkoblinger i /etc/NetworkManager/system-connections). Merk at systemd-journald krever at /etc/machine-id finnes i rotkatalogen (ikke en symlink) for å unngå å ødelegge tidlige oppstarter.
For å finne ut hvilke endringer i utførelsen, bruk dracut-overlayroot: legger en tmpfs over roten, og alt som er skrevet vises i /run/overlayroot/u. Legg modulen til /usr/lib/dracut/modules.d/, inkluder overlayroot i dracut, og sett overlayroot=1 på kjernelinjen; på denne måten vil du se hva som skal migreres til /var.
Nyttige eksempler: pacman og NetworkManager
I Arch er det praktisk Flytt Pacman-databasen til /usr/lib/pacman slik at rootfs alltid speiler installerte pakker. Omdiriger deretter hurtigbufferen til /var/lib/pacman og lenke den. For å endre speillisten uten å berøre roten, flytt den til /var/etc og lenke den likevel.
Med NetworkManager, flytt systemtilkoblinger til /var/etc/NetworkManager og lenke fra /etc/NetworkManager/system-connections. Dette holder roten uforanderlig og konfigurasjonen aktiv der den skal være skrivbar.
Konstruksjon av verity og testing
Fra en live og med alt perfekt og montert i ro, lag treet og roothashen med veritysetup-formatNår den kjøres, skriver den ut rot-hash-linjen, som du kan lagre i roothash.txt. Kjør den for testing med veritysetup, åpne root-device root verity-device $(cat roothash.txt) og monter /dev/mapper/root.
Hvis du foretrekker, genererer først treet til en fil (verity.bin) og skriv den deretter til VERITY-partisjonen. Det resulterende settet er: rotavbildning, verity-tre og rot-hashen du vil feste ved oppstart.
Konfigurer kjernelinjen
Legg til disse parameterne: systemd.verity=1, roothash=contents_of_roothash.txt, systemd.verity_root_data=ROOT-PATH (f.eks. LABEL=OS), og systemd.verity_root_hash=VERITY-PATH (f.eks. LABEL=VERITY). Sett systemd.verity_root_options til restart-on-corruption eller panic-on-corruption for strenge retningslinjer.
Andre anbefalte alternativer: ro (hvis du ikke bruker EROFS/squashfs), rd.emergency=omstart y rd.shell=0 (forhindre uautoriserte skall hvis oppstart mislykkes), og nedstengning = konfidensialitet for å beskytte kjerneminne mot tilgang.
Ekstra partisjoner med Verity
Ikke bare roten: Du kan definere andre mappinger i /etc/veritytab og systemd-veritysetup@.service vil sette dem sammen ved oppstart. Husk: det er enklere å RW-montere en ikke-root-partisjon, og en root-bruker kan deaktivere Verity på disse partisjonene, slik at sikkerhetsverdien der er lavere.
Sikkerhet: Sikker oppstart, UKI og signerte moduler
dm-verity er ikke en mirakelløsning. Signer UKI-en og aktiver sikker oppstart med dine egne nøkler for å hindre at noen overstyrer kernel/initramfs/cmdline (som inkluderer root-hashen). Verktøy som sbupdate-git eller sbctl bidrar til å holde imagene signert og oppstartskjeden intakt.
Hvis du aktiverer kjernelåsing eller verifisering av modulsignatur, DKMS eller moduler utenfor treet må signeres ellers lastes de ikke. Vurder en tilpasset kjerne med signeringsstøtte for pipelinen din (se signerte kjernemoduler).
Kryptering, TPM og måling
dm-verity beskytter integritet, ikke-konfidensialitetDu kan la root være ukryptert hvis den ikke inneholder noen hemmeligheter og oppstartskjeden er beskyttet. Hvis du bruker nøkkelfiler fra root for å låse opp andre volumer, er det lurt å kryptere den.
Med TPM 2.0, systemd-cryptenroll tillater binding av nøkler til PCR-er 0, 1, 5, 7 (fastvare, alternativer, GPT, status for sikker oppstart). Legg til rd.luks.options=LUKS_UUID=tpm2-device=auto og sørg for å inkludere TPM2-støtte i initramfs. systemd-boot måler kernel.efi i PCR4, nyttig for å ugyldiggjøre nøkler hvis UKI eller cmdlinjen endres.
Oppdateringer og distribusjonsmodeller
En verifisert skrivebeskyttet rot Den oppdateres ikke med pakkebehandleren på tradisjonell måteDet ideelle er å bygge nye bilder med verktøy som Yocto-prosjektet og publiser dem. systemd har systemd-sysupdate og systemd-repart for robust nedlasting og flashing av avbildninger.
En annen strategi er A/B-skjemaDu beholder to røtter og to veriteter. Kopier den aktive roten til den inaktive roten, bruk endringene og utfør veriteten på nytt. Bytt tilbake ved neste oppstart. Hvis du bruker UKI, husk å oppdatere rot-hashen i cmd-linjen eller gjenoppbygge den signerte UKI-en.
For valgfri utholdenhet, bruk OverlayFS på den verifiserte roten med en øvre del i tmpfs eller disk. Du kan også sende systemd.volatile=overlay for midlertidig persistens. Flatpak gjør det enkelt å installere apper i /var og /home uten å berøre /.
Det finnes automatiserte pakker (f.eks. verity-squash-root i AUR) som bygger en squashfs-rot og signer roothashen med kernel og initramfs, slik at du kan velge mellom vedvarende eller kortvarig modus og bevare de nyeste rootf-filene som en sikkerhetskopi. Merk: å legge til vedvarende data til en bekreftet rotfil har smale brukstilfeller; prøv å lagre appdata på separate partisjoner.
Android: system-som-root, AVB og leverandøroverlegg
Siden Android 10, RootFS stopper å kjøre på RAM-disken og integreres med system.img. (system-as-root). Enheter som starter med Android 10 bruker alltid dette skjemaet og krever en ramdisk for dm-linear. BOARD_BUILD_SYSTEM_ROOT_IMAGE er satt til false i denne builden for å skille mellom bruk av en ramdisk og direkte aktivering av system.img.
Android 10 inneholder dynamiske partisjoner og en første-trinns init som aktiverer den logiske systempartisjonen; kjernen monterer den ikke lenger direkte. Systembaserte OTA-er krever et system-som-root-design, som er obligatorisk på Android 10-enheter.
I ingen A/B, Hold gjenoppretting atskilt fra oppstartI motsetning til A/B finnes det ingen boot_a/boot_b-sikkerhetskopi, så fjerning av gjenopprettingsmodus i ikke-A/B kan føre til at du ikke har gjenopprettingsmodus hvis en oppstartsoppdatering mislykkes.
Kjernen monterer system.img til /converity via to stier: vboot 1.0 (oppdateringer for kjernen for å analysere Android-metadata i /system og utlede dm-verity-parametere; cmdlinjen inkluderer root=/dev/dm-0, skip_initramfs og init=/init med dm=…) eller vboot 2.0/AVB, der oppstartslasteren integrerer libavb, leser hashtree-beskrivelsen (i vbmeta eller system), konstruerer parameterne og sender dem til kjernen i cmdlinjen, med FEC-støtte og flagg som restart_on_corruption.
Med system-som-rot, ikke bruk BOARD_ROOT_EXTRA_FOLDERS For enhetsspesifikke rotmapper: disse vil forsvinne når du flasher en GSI. Definer spesifikke monteringer under /mnt/vendor/ , som fs_mgr oppretter automatisk, og refererer til dem i fstab i enhetstreet.
Android tillater en leverandøroverlegg fra /product/vendor_overlay/init vil montere i /vendor underkatalogene som oppfyller SELinux-kontekstkravene og eksistensen av /vendor/ Krever CONFIG_OVERLAY_FS=yy, på eldre kjerner, override_creds=off-oppdateringen.
Typisk implementering: installerer forhåndskompilerte filer i enhet/ / /leverandøroverlegg/, legg dem til i PRODUCT_COPY_FILES med find-copy-subdir-files til $(TARGET_COPY_OUT_PRODUCT)/vendor_overlay, definer kontekster i file_contexts for etc og app (f.eks. vendor_configs_file og vendor_app_file) og tillat montering på disse kontekstene i init.te. Test med atest vfs_mgr_vendor_overlay_test i userdebug.
Feilsøking: melding om korrupsjon av dm-verity på Android
På enheter med A/B-spor, bytt spor eller Flasher vbmeta/boot uten konsistens med roothashen Dette kan utløse advarselen: dm-verity corruption, your device is untrusted. Kommandoer som fastboot flash –disable-verity –disable-verification vbmeta vbmeta.img deaktiverer verifisering, men etterlater systemet uten noen garantier for integritet.
Noen oppstartslastere støtter hurtigstart oem disable_dm_verity og det motsatte, enable_dm_verity. Det fungerer på noen modeller, men ikke på andre; og det kan kreve kernel/magisk med justerte flagg. Bruk på egen risiko: den forsvarlige fremgangsmåten er juster oppstart, vbmeta og system, signer eller regenerer treet og sørg for at den forventede rot-hashen samsvarer med den konfigurerte.
Hvis du kan fortsette å trykke på av/på-knappen etter advarselen, starter systemet, men du har ikke lenger en intakt tillitskjedeFor å fjerne meldingen uten å ofre sikkerheten, gjenopprett de originale signerte bildene eller gjenoppbygg/verifiser vbmeta med riktig hashtree, i stedet for å deaktivere verity.
i.MX- og OpenWrt-plattformer
På i.MX6 (f.eks. sabresd), konfigurer kjernen med DM_VERITY og FEC-støtte, generer treet med veritysetup, lagre rot-hashen sikkert, og send de riktige parameterne i cmd-linjen eller integrer via initramfs med systemd-veritysetup. Hvis du ikke bruker dm-crypt, trenger du ikke CAAM for verity; fokuset er på integritet.
I OpenWrt og i innebygde Linux-systemer med OpenEmbedded, Det gjøres forsøk på å integrere dm-verity og SELinux (Bootlin-jobber revidert med den hensikt å innlemme støtte). Det er en naturlig tilpasning: rutere og nettverksutstyr drar nytte av en uforanderlig, verifisert og MAC-herdet rot.
Manuell tre- og metadatakonstruksjon (detaljert visning)
cryptsetup kan generere treet for deg, men hvis du foretrekker å forstå formatet, inkluderer den kompakte tabelllinjedefinisjonen: kartleggingsnavn, dataenhet, datablokk- og hashstørrelser, bildestørrelse i blokker, hash_start-posisjon (blokkbilde + 8 hvis sammenkjedet), rot-hash og salt. Etter å ha generert de sammenkjedede lagene (fra topp til bunn, unntatt lag 0), skriver du treet til disk.
Å pakke alt, komponer dm-verity-tabellen, signer den (typisk RSA-2048) og grupper signatur+tabell i metadata med en versjonert header og et magisk tall. Deretter sammenkobler den systemavbildningen, verity-metadataene og hash-treet. I fstab markerer den fs_mgr som verify og plasserer den offentlige nøkkelen i /boot/verity_key for å validere signaturen.
Optimaliser med SHA-2-hastighetsøkninger for CPU-en din og juster read-ahead/prefetch_cluster. På ARM-maskinvare reduserer NEON SHA-2 (ARMv7) og SHA-2-utvidelser (ARMv8) verifiseringskostnadene betydelig.
Husk at i enhver utplassering Rot-hashverdien må beskyttesenten kompilert til en signert UKI, til den signerte oppstartspartisjonen eller validert av oppstartslasteren ved hjelp av AVB. Alt etter dette punktet arver den tilliten.
Med alt det ovennevnte på plass, blir dm-verity et solid fundament for uforanderlige, mobile og innebygde systemer, som støtter transaksjonsoppdateringer, konfigurasjonsoverlegg og en moderne sikkerhetsmodell som reduserer angrepsflaten og forhindrer vedvarende data uten å ofre ytelsen.
