Jeśli martwisz się o integralność swojego systemu, dm-verity jest jednym z kluczowych elementów ekosystemu Linux do bezpiecznego rozruchu i wykrywania manipulacji pamięcią masową. Początkowo był częścią mapowania urządzeń jądra, a obecnie stanowi podstawę weryfikacji rozruchu w systemach Android, OpenWRT i dystrybucjach wymagających zwiększonego bezpieczeństwa.
Daleko jej do bycia abstrakcyjnym konceptem, dm-verity jest konfigurowany i używany za pomocą prawdziwych narzędzi, takich jak veritysetup i systemd-veritysetupSprawdza bloki w locie, korzystając z drzew haszujących, i może reagować na uszkodzenia za pomocą różnych zasad, od rejestrowania zdarzeń po ponowne uruchomienie lub awarię systemu. Przyjrzyjmy się temu bliżej, nie zostawiając żadnych niedomówień.
Czym jest dm-verity i dlaczego może Cię to zainteresować
dm-verity to cel mapowania urządzeń w jądrze, który weryfikuje integralność urządzenia blokowego podczas odczytu danychDziała poprzez obliczanie i weryfikowanie skrótów każdego bloku (zwykle 4K) na podstawie wstępnie obliczonego drzewa skrótów, zwykle przy użyciu algorytmu SHA-256.
Ta konstrukcja pozwala na Plików nie można modyfikować w trybie cichym pomiędzy restartami lub w trakcie wykonywaniaJest to klucz do rozszerzenia łańcucha zaufania rozruchowego na system operacyjny, ograniczenia trwałości złośliwego oprogramowania, wzmocnienia zasad bezpieczeństwa i zapewnienia mechanizmów szyfrowania i MAC podczas rozruchu.
Na Androidzie (od wersji 4.4) i ogólnie na Linuksie, Zaufanie jest zakotwiczone w korze drzewa, który jest podpisany i zweryfikowany kluczem publicznym znajdującym się w chronionej lokalizacji (np. na partycji rozruchowej lub w podpisanym bezpiecznym rozruchem UKI). Złamanie dowolnego bloku wymagałoby złamania podstawowego skrótu kryptograficznego.
Weryfikacja odbywa się blokowo i na żądanie: Dodatkowe opóźnienie jest minimalne w porównaniu do kosztów wejścia/wyjściaJeśli sprawdzenie się nie powiedzie, jądro zwraca błąd wejścia/wyjścia, a system plików wydaje się uszkodzony, co jest normalne, gdy dane są zawodne. Aplikacje mogą decydować o kontynuowaniu działania na podstawie swojej odporności na błędy.
Jak drzewo weryfikacyjne działa wewnętrznie
Drzewo weryfikacji zbudowane jest warstwowo. Warstwa 0 to surowe dane z urządzenia podzielone na bloki 4K; Dla każdego bloku obliczany jest skrót SHA-256 (z solą). Skróty te są następnie łączone, tworząc warstwę 1. Warstwa 1 jest następnie grupowana w bloki i ponownie haszowana, tworząc warstwę 2 i tak dalej, aż wszystko zmieści się w jednym bloku: ten blok, po haszowaniu, generuje skrót główny.
Jeżeli jakaś warstwa nie uzupełnia dokładnie bloku, Jest uzupełniany zerami, aż osiągnie 4K Aby uniknąć niejasności. Całkowity rozmiar drzewa zależy od rozmiaru sprawdzanej partycji; w praktyce zazwyczaj wynosi on mniej niż 30 MB dla typowych partycji systemowych.
Ogólny proces wygląda następująco: wybierz losową sól, zmień wartość skrótu na 4K, oblicz SHA-256 z solą na blok, łączy się, tworząc poziomy, uzupełnia granicę bloku zerami i powtarza z poprzednim poziomem, aż do uzyskania pojedynczego skrótu źródłowego. Ten skrót źródłowy, wraz z użytą solą, zasila tabelę dm-verity i sygnaturę.
Wersje formatów dysków i algorytm
Format bloków haszujących na dysku ma swoją wersję. Wersja 0 była oryginalną wersją używaną w systemie operacyjnym ChromiumSól dodawana jest pod koniec procesu haszowania, skróty są przechowywane w sposób ciągły, a reszta bloku jest uzupełniana zerami.
La Wersja 1 jest zalecana dla nowych urządzeń: Sól jest dodawana przed hashem, a każdy skrót jest uzupełniany zerami do potęgi dwójki, co poprawia dopasowanie i niezawodność. Tabela dm-verity określa również algorytm (np. sha1 lub sha256), chociaż obecnie dla bezpieczeństwa używany jest sha256.
tabela dm-verity i istotne parametry
Opis tabeli docelowej dm-verity gdzie znajdują się dane, gdzie znajduje się drzewo skrótów i jak to zweryfikowaćTypowe pola tabeli:
- dev: urządzenie z danymi, które mają zostać zweryfikowane (typ ścieżki /dev/sdXN lub nowszy:lesser).
- hash_dev: urządzenie z drzewem skrótu (może być takie samo, w takim przypadku hash_start musi znajdować się poza zakresem sprawdzania).
- rozmiar_bloku_danych: rozmiar bloku danych w bajtach (np. 4096).
- rozmiar_bloku_hashowania:rozmiar bloku skrótu w bajtach.
- liczba_bloków_danych: liczba weryfikowalnych bloków danych.
- blok startowy hasha: przesunięcie (w blokach hash_block_size) do bloku głównego drzewa.
- algorytm: algorytm skrótu (np. sha256).
- strawić: szesnastkowe kodowanie skrótu bloku głównego (wliczając sól zgodnie z wersją formatu); tej wartości można zaufać.
- sól: sól szesnastkowa.
Ponadto są parametry opcjonalne bardzo przydatne do zmiany zachowania:
- ignoruj_korupcję: Rejestruje uszkodzone bloki, ale pozwala na kontynuowanie odczytu.
- restart_w_przypadku_uszkodzenia: ponowne uruchomienie po wykryciu uszkodzenia (niezgodne z ignore_corruption i wymaga obsługi przestrzeni użytkownika w celu uniknięcia pętli).
- panika_w_konflikcie: : powoduje panikę w przypadku wykrycia uszkodzenia (niezgodne z poprzednimi wersjami).
- restart_on_error y panika_w_przypadku_błędu: takie same reakcje, ale w przypadku błędów wejścia/wyjścia.
- ignoruj_zero_bloków: nie sprawdza bloków, które są oczekiwane jako zera i zwraca zera.
- użyj_fec_z_urządzenia + fec_roots + bloki_fec + fec_start:Włącz protokół Reed-Solomon (FEC) w celu odzyskania danych w przypadku niepowodzenia weryfikacji. Obszary danych, skrótu i FEC nie mogą się na siebie nakładać, a rozmiary bloków muszą być zgodne.
- sprawdź_najpierw_najpierw: Sprawdza każdy blok danych tylko przy pierwszym odczycie (zmniejsza obciążenie kosztem bezpieczeństwa w przypadku ataków na żywo).
- opis_klucza_root_hash:Odwołanie do klucza w pęku kluczy w celu sprawdzenia podpisu PKCS7 skrótu głównego podczas tworzenia mapowania (wymaga odpowiedniej konfiguracji jądra i zaufanych pęków kluczy).
- spróbuj_zweryfikować_w_zadaniu: Jeśli skróty są buforowane i rozmiar wejścia/wyjścia na to pozwala, sprawdzana jest dolna połowa w celu zmniejszenia opóźnienia; dostosowywane za pomocą /sys/module/dm_verity/parameters/use_bh_bytes dla każdej klasy wejścia/wyjścia.
Podpis, metadane i zakotwiczenie zaufania
Aby dm-verity było niezawodne, Główny hash musi być zaufany i zazwyczaj podpisanyW klasycznej wersji Androida w partycji rozruchowej znajduje się klucz publiczny, który jest zewnętrznie weryfikowany przez producenta. Klucz ten weryfikuje podpis skrótu głównego i zapewnia, że partycja systemowa nie została zmieniona.
Metadane Verity dodają strukturę i kontrolę wersji. Blok metadanych zawiera magiczną liczbę 0xb001b001 (bajty b0 01 b0 01), wersja (obecnie 0), podpis tabeli w PKCS1.5 (zwykle 256 bajtów dla RSA-2048), długość tabeli, sama tabela i uzupełnienie zerami do 32 KB.
W implementacjach Androida weryfikacja opiera się na fs_mgr i fstab:Dodanie znacznika wyboru do odpowiedniego wpisu i umieszczenie klucza w /boot/verity_key. Jeśli magiczna liczba nie znajduje się tam, gdzie powinna, weryfikacja jest zatrzymywana, aby uniknąć sprawdzenia niewłaściwego elementu.
Rozpoczęcie operacji zweryfikowane
Ochrona znajduje się w jądrze: Jeśli nastąpi naruszenie przed uruchomieniem jądra, atakujący zachowa kontrolęDlatego producenci zazwyczaj skrupulatnie sprawdzają każdy etap: klucz wypalony w urządzeniu weryfikuje pierwszy bootloader, który weryfikuje kolejny, bootloader aplikacji, i na końcu jądro.
Po zweryfikowaniu jądra, dm-verity jest włączany podczas montowania zweryfikowanego urządzenia blokowegoZamiast hashowania całego urządzenia (co byłoby powolne i marnowałoby energię), weryfikuje się je blok po bloku podczas uzyskiwania do niego dostępu. Awaria powoduje błąd wejścia/wyjścia, a usługi i aplikacje reagują w zależności od swojej tolerancji: kontynuują działanie bez tych danych lub całkowicie się zawieszają.
Korekcja błędów do przodu (FEC)
Od wersji Androida 7.0 FEC (Reed-Solomon) jest zintegrowany z technikami przeplotu Aby zmniejszyć przestrzeń i zwiększyć możliwości odzyskiwania uszkodzonych bloków. Działa to w połączeniu z dm-verity: jeśli sprawdzenie się nie powiedzie, podsystem może spróbować je naprawić, zanim uzna je za nieodwracalne.
Wydajność i optymalizacja
Aby ograniczyć wpływ: Włącz przyspieszenie SHA-2 przez NEON na ARMv7 i rozszerzenia SHA-2 na ARMv8 Z poziomu jądra. Dostosuj parametry read-ahead i prefetch_cluster do swojego sprzętu; weryfikacja na poziomie bloku zazwyczaj nieznacznie zwiększa koszt wejścia/wyjścia, ale te ustawienia robią różnicę.
Rozpoczęcie pracy z systemami Linux (systemd, veritysetup) i Android
W nowoczesnym systemie Linux z systemem systemd, dm-verity umożliwia zweryfikowanie uprawnień root tylko do odczytu Używając veritysetup (część cryptsetup), systemd-veritysetup.generator i systemd-veritysetup@.service. Zaleca się uwzględnienie Secure Boot i podpisanego UKI (ujednoliconego obrazu jądra), choć nie są one bezwzględnie wymagane.
Przygotowanie i zalecany podział
Część funkcjonalnego i dostosowanego systemu. Zarezerwuj wolumin dla drzewa skrótów (8–10% rozmiaru katalogu głównego zazwyczaj wystarcza) i rozważ rozdzielenie /home i /var, jeśli musisz pisać. Typowy schemat obejmuje: ESP (dla bootloadera), XBOOTLDR (dla UKI), root (z szyfrowaniem lub bez), partycję VERITY oraz opcjonalnie /home i /var.
Jako korzeń, EROFS jest bardzo ciekawą alternatywą dla ext4 lub squashfs: Jest to plik przeznaczony tylko do odczytu, o bardzo dobrej wydajności na dyskach flash/SSD, domyślnie obsługuje kompresję lz4 i jest szeroko stosowany w telefonach z systemem Android z obsługą dm-verity.
Pliki, które muszą być zapisywalne
W przypadku uprawnień root niektóre programy oczekują zapisu do /etc lub podczas initMożesz przenieść go do /var/etc i utworzyć dowiązanie symboliczne do wszystkiego, co wymaga zmiany (np. połączenia NetworkManager w /etc/NetworkManager/system-connections). Pamiętaj, że systemd-journald wymaga, aby w katalogu głównym znajdował się plik /etc/machine-id (a nie dowiązanie symboliczne), aby uniknąć problemów z wczesnym uruchamianiem.
Aby dowiedzieć się, jakie zmiany zaszły w realizacji, użyj dracut-overlayroot: nakłada tmpfs na katalog główny, a wszystko, co jest zapisane, pojawia się w /run/overlayroot/u. Dodaj moduł do /usr/lib/dracut/modules.d/, dołącz overlayroot do dracut i ustaw overlayroot=1 w wierszu jądra; w ten sposób zobaczysz, co przenieść do /var.
Przydatne przykłady: pacman i NetworkManager
W Archu jest to wygodne Przenieś bazę danych Pacman do /usr/lib/pacman Aby system plików root zawsze odzwierciedlał zainstalowane pakiety. Następnie przekieruj pamięć podręczną do /var/lib/pacman i połącz ją. Aby zmienić listę mirrorów bez naruszania katalogu root, przenieś ją do /var/etc i połącz ją mimo wszystko.
Dzięki NetworkManagerowi przenieś połączenia systemowe do /var/etc/NetworkManager i link z /etc/NetworkManager/system-connections. Dzięki temu root pozostaje niezmienny, a konfiguracja jest aktualna i możliwa do zapisu.
Budowa prawdziwości i testowanie
Z poziomu live i ze wszystkim idealnym i zamontowanym w ro, utwórz drzewo i roothash z format konfiguracji verity: Po uruchomieniu drukuje wiersz Root Hash, który można zapisać w pliku roothash.txt. Uruchom go w celach testowych za pomocą veritysetup: otwórz root-device root verity-device $(cat roothash.txt) i zamontuj /dev/mapper/root.
Jeśli wolisz, najpierw generuje drzewo do pliku (verity.bin), a następnie zapisz go na partycji VERITY. Wynikowy zestaw to: obraz główny, drzewo Verity i skrót główny, który przypniesz podczas rozruchu.
Skonfiguruj linię jądra
Dodaj następujące parametry: systemd.verity=1, roothash=contents_of_roothash.txt, systemd.verity_root_data=ROOT-PATH (np. LABEL=OS) i systemd.verity_root_hash=VERITY-PATH (np. LABEL=VERITY). Ustaw systemd.verity_root_options na restart-on-corruption lub panic-on-corruption, aby uzyskać rygorystyczne zasady.
Inne polecane opcje: ro (jeśli nie używasz EROFS/squashfs), rd.emergency=reboot y rd.shell=0 (zapobiega nieautoryzowanym powłokom w przypadku niepowodzenia rozruchu) i blokada = poufność w celu ochrony pamięci jądra przed dostępem.
Dodatkowe partycje z verity
Nie tylko korzeń: Możesz zdefiniować inne mapowania w /etc/veritytab a systemd-veritysetup@.service zmontuje je podczas rozruchu. Pamiętaj: łatwiej jest zamontować partycję inną niż root, a użytkownik root może wyłączyć Verity na tych partycjach, więc wartość bezpieczeństwa jest tam niższa.
Bezpieczeństwo: Bezpieczny rozruch, UKI i podpisane moduły
dm-verity nie jest rozwiązaniem idealnym. Podpisz UKI i włącz Secure Boot przy użyciu własnych kluczy aby uniemożliwić komukolwiek nadpisanie kernel/initramfs/cmdline (w tym skrótu root). Narzędzia takie jak sbupdate-git lub sbctl pomagają zachować podpisy obrazów i integralność łańcucha rozruchowego.
Jeśli włączysz blokadę jądra lub weryfikację podpisu modułu, Moduły DKMS lub spoza drzewa muszą być podpisane lub nie załadują się. Rozważ użycie niestandardowego jądra z obsługą podpisywania dla swojego potoku (patrz podpisane moduły jądra).
Szyfrowanie, TPM i pomiar
dm-verity chroni integralność, brak poufnościMożesz pozostawić root bez szyfrowania, jeśli nie zawiera żadnych sekretów, a łańcuch rozruchowy jest chroniony. Jeśli używasz plików kluczy z roota do odblokowywania innych woluminów, dobrym pomysłem będzie ich zaszyfrowanie.
Dzięki TPM 2.0, systemd-cryptenroll umożliwia wiązanie kluczy z PCR 0,1,5,7 (oprogramowanie układowe, opcje, GPT, status bezpiecznego rozruchu). Dodaj rd.luks.options=LUKS_UUID=tpm2-device=auto i upewnij się, że obsługa TPM2 jest uwzględniona w initramfs. Systemd-boot mierzy kernel.efi w PCR4, co jest przydatne do unieważniania kluczy w przypadku zmiany UKI lub wiersza poleceń.
Aktualizacje i modele wdrażania
Zweryfikowany katalog główny tylko do odczytu Nie jest aktualizowany w tradycyjny sposób za pomocą menedżera pakietów. Najlepiej jest tworzyć nowe obrazy za pomocą narzędzi takich jak projekt Yocto i je opublikować. Systemd posiada narzędzia systemd-sysupdate i systemd-repart umożliwiające sprawne pobieranie i flashowanie obrazów.
Inna strategia to Schemat A/B: Zachowujecie dwa rooty i dwie weryfikacje. Kopiujecie aktywny root do nieaktywnego roota, stosujecie zmiany i ponawiacie weryfikację. Przełączacie się ponownie przy następnym uruchomieniu. Jeśli korzystacie z UKI, pamiętajcie o aktualizacji skrótu roota w wierszu poleceń lub o odbudowaniu podpisanego UKI.
W celu opcjonalnego zachowania, użyj OverlayFS na zweryfikowanym rootze z górną wartością w tmpfs lub disk. Możesz również przekazać systemd.volatile=overlay w celu tymczasowego utrwalenia. Flatpak ułatwia instalację aplikacji w /var i /home bez dotykania /.
Istnieją zautomatyzowane pakiety (np. verity-squash-root w AUR), które budują katalog główny squashfs i podpisz roothash za pomocą jądra i initramfs, umożliwiając wybór między trybem trwałym a efemerycznym i zachowując najnowszy system plików rootfs jako kopię zapasową. Uwaga: dodanie trwałości do zweryfikowanego systemu root ma wąskie zastosowanie; spróbuj zachować dane aplikacji na osobnych partycjach.
Android: system jako root, AVB i nakładki dostawcy
Od wersji Androida 10 RootFS przestaje działać na dysku RAM i integruje się z systemem.img. (system-as-root). Urządzenia uruchamiane z Androidem 10 zawsze korzystają z tego schematu i wymagają dysku RAM dla dm-linear. W tej kompilacji parametr BOARD_BUILD_SYSTEM_ROOT_IMAGE jest ustawiony na false, aby odróżnić użycie dysku RAM od bezpośredniej aktywacji pliku system.img.
Android 10 zawiera partycje dynamiczne i inicjalizacja pierwszego etapu który aktywuje logiczną partycję systemową; jądro nie montuje jej już bezpośrednio. OTA tylko dla systemu wymagają konfiguracji „system jako root”, która jest obowiązkowa na urządzeniach z Androidem 10.
W żadnym A/B, oddziel odzyskiwanie od rozruchuW przeciwieństwie do trybu A/B nie ma kopii zapasowej boot_a/boot_b, więc usunięcie funkcji recovery w trybie innym niż A/B może spowodować brak trybu recovery w przypadku niepowodzenia aktualizacji rozruchu.
Jądro montuje system.img w /converity dwoma ścieżkami: vboot 1.0 (łatki dla jądra umożliwiające analizę metadanych Androida w /system i wyprowadzenie parametrów dm-verity; wiersz poleceń zawiera root=/dev/dm-0, skip_initramfs i init=/init z dm=…) lub vboot 2.0/AVB, gdzie bootloader integruje libavb, odczytuje deskryptor hashtree (z vbmeta lub system), konstruuje parametry i przekazuje je do jądra w wierszu poleceń, ze wsparciem FEC i flagami takimi jak restart_on_corruption.
Z systemem jako root, nie używaj BOARD_ROOT_EXTRA_FOLDERS W przypadku folderów głównych specyficznych dla urządzenia: znikną one po flashowaniu GSI. Zdefiniuj konkretne miejsca montowania w /mnt/vendor/. , które fs_mgr tworzy automatycznie i odwołuj się do nich w pliku fstab drzewa urządzeń.
Android pozwala na nakładka dostawcy z /product/vendor_overlay/:init zamontuje w /vendor podkatalogi, które spełniają wymagania kontekstu SELinux i istnienie /vendor/ Wymaga CONFIG_OVERLAY_FS=yy, w starszych jądrach łatki override_creds=off.
Typowa implementacja: instaluje wstępnie skompilowane pliki w urządzeniu/ / /nakładka_dostawcy/, dodaj je do PRODUCT_COPY_FILES za pomocą find-copy-subdir-files do $(TARGET_COPY_OUT_PRODUCT)/vendor_overlay, zdefiniuj konteksty w file_contexts dla etc i app (np. vendor_configs_file i vendor_app_file) i zezwól na montowanie tych kontekstów w init.te. Przetestuj za pomocą atest vfs_mgr_vendor_overlay_test w userdebug.
Rozwiązywanie problemów: komunikat o uszkodzeniu dm-verity na Androidzie
W urządzeniach ze slotami A/B zmień sloty lub Flashowanie vbmeta/boot bez spójności z roothashem Może to spowodować wyświetlenie ostrzeżenia: uszkodzenie dm-verity, Twoje urządzenie nie jest zaufane. Polecenia takie jak fastboot flash –disable-verity –disable-verification vbmeta vbmeta.img wyłączają weryfikację, ale pozostawiają system bez gwarancji integralności.
Niektóre bootloadery obsługują fastboot oem disable_dm_verity i jego przeciwieństwo, enable_dm_verity. Działa na niektórych modelach, ale nie na innych; i może wymagać kernela/magisk z dostosowanymi flagami. Używaj na własne ryzyko: rozsądnie jest… wyrównaj boot, vbmeta i system, podpisz lub zregeneruj drzewo i upewnij się, że oczekiwany skrót główny jest zgodny ze skonfigurowanym.
Jeżeli po ostrzeżeniu nadal będziesz mógł naciskać przycisk zasilania, system uruchomi się, ale nie masz już nienaruszonego łańcucha zaufaniaAby usunąć wiadomość bez utraty bezpieczeństwa, przywróć oryginalne podpisane obrazy lub przebuduj/zweryfikuj vbmeta przy użyciu poprawnego drzewa skrótów, zamiast wyłączać verity.
Platformy i.MX i OpenWrt
Na i.MX6 (np. sabresd), skonfiguruj jądro z obsługą DM_VERITY i FEC, wygeneruj drzewo za pomocą veritysetup, bezpiecznie zapisz skrót główny i przekaż odpowiednie parametry w wierszu polecenia lub zintegruj za pomocą initramfs z systemd-veritysetup. Jeśli nie używasz dm-crypt, nie potrzebujesz CAAM dla verity; nacisk kładziony jest na integralność.
W OpenWrt i w systemy Linux z systemem OpenEmbedded, Podejmowane są wysiłki mające na celu integrację dm-verity i SELinux (Zadania Bootlina zostały poprawione z myślą o uwzględnieniu obsługi). To naturalne dopasowanie: routery i sprzęt sieciowy korzystają z niezmiennego, zweryfikowanego i zabezpieczonego adresem MAC roota.
Ręczna konstrukcja drzewa i metadanych (widok szczegółowy)
cryptsetup może wygenerować drzewo za Ciebie, ale jeśli wolisz zrozumieć format, definicja wiersza tabeli kompaktowej obejmuje: nazwa mapowania, urządzenie danych, rozmiary bloków danych i skrótów, rozmiar obrazu w blokach, pozycja startowa hash_ (obraz bloku + 8 w przypadku połączenia), skrót główny i sól. Po wygenerowaniu połączonych warstw (od góry do dołu, z wyłączeniem warstwy 0), zapisujesz drzewo na dysku.
Aby spakować wszystko, utwórz tabelę dm-verity, podpisz ją (typowo RSA-2048) i zgrupuj podpis+tabelę w metadanych z wersjonowanym nagłówkiem i numerem magicznym. Następnie łączy obraz systemu, metadane Verity i drzewo skrótów. W pliku fstab oznacza fs_mgr jako weryfikowalny i umieszcza klucz publiczny w /boot/verity_key w celu weryfikacji podpisu.
Zoptymalizuj za pomocą Przyspieszenie SHA-2 dla Twojego procesora i dostosuj read-ahead/prefetch_cluster. Na sprzęcie ARM, rozszerzenia NEON SHA-2 (ARMv7) i SHA-2 (ARMv8) znacznie zmniejszają obciążenie związane z weryfikacją.
Pamiętaj, że przy każdym wdrożeniu wartość skrótu głównego musi być chroniona: niezależnie od tego, czy skompilowano je do podpisanego UKI, do podpisanej partycji rozruchowej, czy zweryfikowano przez bootloader za pomocą AVB. Wszystko po tym punkcie dziedziczy to zaufanie.
Mając wszystko powyższe na miejscu, dm-verity staje się solidny fundament dla niezmiennych, mobilnych i wbudowanych systemów, obsługując aktualizacje transakcyjne, nakładki konfiguracyjne i nowoczesny model zabezpieczeń, który zmniejsza powierzchnię ataku i zapobiega jego utrwalaniu bez obniżania wydajności.
