Nếu bạn lo ngại về tính toàn vẹn của hệ thống của mình, dm-verity là một trong những thành phần quan trọng của hệ sinh thái Linux để khởi động an toàn và phát hiện hành vi xâm phạm bộ nhớ. Nó bắt nguồn từ một phần của trình ánh xạ thiết bị của hạt nhân và hiện là cơ sở cho việc khởi động được xác minh trong Android, OpenWrt và các bản phân phối đang tìm kiếm bảo mật nâng cao.
Không phải là một khái niệm trừu tượng, dm-verity được cấu hình và sử dụng với các công cụ thực tế như veritysetup và systemd-veritysetupNó xác thực các khối ngay lập tức bằng cây băm và có thể phản ứng với lỗi bằng các chính sách từ ghi lại sự kiện đến khởi động lại hoặc làm sập hệ thống. Hãy cùng xem xét kỹ hơn, không bỏ sót bất kỳ chi tiết nào.
Dm-verity là gì và tại sao bạn có thể quan tâm
dm-verity là mục tiêu ánh xạ thiết bị trong hạt nhân xác minh tính toàn vẹn của thiết bị khối khi dữ liệu được đọcNó hoạt động bằng cách tính toán và xác minh giá trị băm của mỗi khối (thường là 4K) so với cây băm được tính toán trước, thường sử dụng SHA-256.
Thiết kế này cho phép Không thể tự động sửa đổi các tập tin giữa các lần khởi động lại hoặc trong quá trình thực thiĐiều quan trọng là mở rộng chuỗi khởi động tin cậy cho hệ điều hành, hạn chế sự tồn tại của phần mềm độc hại, tăng cường chính sách bảo mật và đảm bảo mã hóa và cơ chế MAC trong quá trình khởi động.
Trên Android (từ phiên bản 4.4) và Linux nói chung, Niềm tin được neo vào băm gốc của cây, được ký và xác thực bằng khóa công khai nằm ở vị trí được bảo vệ (ví dụ: trên phân vùng khởi động hoặc trong UKI được Secure Boot ký). Việc phá vỡ bất kỳ khối nào cũng sẽ yêu cầu phá vỡ hàm băm mật mã cơ bản.
Xác minh được thực hiện theo khối và theo yêu cầu: Độ trễ bổ sung là tối thiểu so với chi phí I/ONếu kiểm tra không thành công, kernel sẽ trả về lỗi I/O và hệ thống tệp sẽ bị lỗi, điều này là bình thường khi dữ liệu không đáng tin cậy. Ứng dụng có thể quyết định tiếp tục hay không dựa trên khả năng chịu lỗi của chúng.
Cây xác minh hoạt động như thế nào bên trong
Cây xác minh được xây dựng theo từng lớp. Lớp 0 là dữ liệu thô từ thiết bị, được chia thành các khối 4K; một hàm băm SHA-256 (đã được mã hóa) được tính toán cho mỗi khối. Các hàm băm này sau đó được nối lại để tạo thành lớp 1. Lớp 1 sau đó được nhóm thành các khối và được băm lại để tạo thành lớp 2, và cứ tiếp tục như vậy cho đến khi tất cả được gói gọn trong một khối duy nhất: khối đó, khi được băm, sẽ tạo ra hàm băm gốc.
Nếu bất kỳ lớp nào không hoàn thành chính xác một khối, Nó được đệm bằng số không cho đến khi đạt tới 4K để tránh nhầm lẫn. Tổng kích thước của cây phụ thuộc vào kích thước của phân vùng đang được kiểm tra; trên thực tế, kích thước này thường nhỏ hơn 30 MB đối với các phân vùng hệ thống thông thường.
Quy trình chung là: chọn một muối ngẫu nhiên, băm thành 4K, tính toán SHA-256 với muối trên mỗi khối, nối tiếp nhau để tạo thành các cấp độ, thêm số 0 vào ranh giới khối và lặp lại với cấp độ trước đó cho đến khi chỉ còn lại một băm gốc. Băm gốc đó, cùng với salt được sử dụng, sẽ đưa vào bảng dm-verity và chữ ký.
Phiên bản định dạng đĩa và thuật toán
Định dạng của khối băm trên đĩa có một phiên bản. Phiên bản 0 là phiên bản gốc được sử dụng trong Chromium OS: Muối được thêm vào cuối quá trình băm, các bản tóm tắt được lưu trữ liên tục và phần còn lại của khối được đệm bằng số không.
La Phiên bản 1 được khuyến nghị cho các thiết bị mới: Muối được thêm vào hàm băm, và mỗi bản tóm tắt được đệm bằng các số không lên đến lũy thừa của hai, cải thiện tính đồng bộ và độ tin cậy. Bảng dm-verity cũng chỉ định thuật toán (ví dụ: sha1 hoặc sha256), mặc dù vì lý do bảo mật hiện tại, sha256 được sử dụng.
bảng dm-verity và các tham số cần thiết
Bảng mục tiêu dm-verity mô tả dữ liệu ở đâu, cây băm ở đâu và cách xác minhCác trường bảng điển hình:
- dev: thiết bị có dữ liệu cần xác minh (loại đường dẫn /dev/sdXN hoặc lớn hơn:nhỏ hơn).
- hash_dev: thiết bị có cây băm (có thể giống nhau; nếu vậy, hash_start phải nằm ngoài phạm vi đã kiểm tra).
- kích thước khối dữ liệu: kích thước khối dữ liệu tính bằng byte (ví dụ: 4096).
- kích thước khối băm: kích thước khối băm tính bằng byte.
- số_khối_dữ_liệu: số lượng khối dữ liệu có thể xác minh.
- khối_bắt_đầu_băm: độ lệch (tính theo khối hash_block_size) tới khối gốc của cây.
- thuật toán: thuật toán băm (ví dụ: sha256).
- tiêu: mã hóa thập lục phân của hàm băm khối gốc (bao gồm cả muối theo phiên bản định dạng); giá trị này là giá trị đáng tin cậy.
- muối: muối thập lục phân.
Ngoài ra, còn có các tham số tùy chọn rất hữu ích để điều chỉnh hành vi:
- bỏ qua_tham_trá: Ghi lại các khối bị hỏng nhưng vẫn cho phép tiếp tục đọc.
- khởi động lại khi bị hỏng: khởi động lại khi phát hiện lỗi (không tương thích với ignore_corruption và yêu cầu hỗ trợ không gian người dùng để tránh vòng lặp).
- hoảng loạn vì tham nhũng: : gây ra sự hoảng loạn khi phát hiện lỗi (không tương thích với các phiên bản trước).
- khởi động lại_on_error y hoảng loạn vì lỗi: phản ứng tương tự nhưng có lỗi I/O.
- bỏ qua_không_khối: không kiểm tra các khối được mong đợi là số không và trả về số không.
- use_fec_from_device + fec_roots + khối fec + fec_start: Cho phép Reed–Solomon (FEC) khôi phục dữ liệu khi xác minh không thành công; vùng dữ liệu, băm và FEC không được chồng lấn và kích thước khối phải khớp nhau.
- kiểm tra tối đa một lần: Chỉ kiểm tra từng khối dữ liệu khi đọc lần đầu (giảm chi phí nhưng vẫn đảm bảo an ninh trong các cuộc tấn công trực tiếp).
- root_hash_sig_key_desc: Tham chiếu đến khóa trong vòng khóa để xác thực chữ ký PKCS7 của hàm băm gốc khi tạo ánh xạ (yêu cầu cấu hình hạt nhân phù hợp và vòng khóa đáng tin cậy).
- thử_xác_minh_trong_tasklet: Nếu các băm được lưu trong bộ nhớ đệm và kích thước I/O cho phép, hãy kiểm tra nửa dưới để giảm độ trễ; điều chỉnh với /sys/module/dm_verity/parameters/use_bh_bytes cho mỗi lớp I/O.
Chữ ký, siêu dữ liệu và neo tin cậy
Để dm-verity đáng tin cậy, Băm gốc phải đáng tin cậy và thường được kýTrong Android cổ điển, khóa công khai được bao gồm trong phân vùng khởi động, được nhà sản xuất xác minh bên ngoài; khóa này xác thực chữ ký băm gốc và đảm bảo rằng phân vùng hệ thống không bị thay đổi.
Siêu dữ liệu Verity bổ sung cấu trúc và kiểm soát phiên bản. Khối siêu dữ liệu bao gồm một số ma thuật 0xb001b001 (byte b0 01 b0 01), phiên bản (hiện tại là 0), chữ ký bảng trong PKCS1.5 (thường là 256 byte đối với RSA-2048), độ dài bảng, bản thân bảng và phần đệm bằng 0 lên đến 32K.
Trong các triển khai Android, xác minh dựa vào fs_mgr và fstab: Thêm dấu kiểm vào mục tương ứng và đặt khóa vào /boot/verity_key. Nếu số ma thuật không nằm đúng vị trí, quá trình xác minh sẽ dừng lại để tránh chọn sai.
Bắt đầu hoạt động đã được xác minh
Sự bảo vệ nằm ở hạt nhân: Nếu bị xâm phạm trước khi hạt nhân khởi động, kẻ tấn công vẫn giữ quyền kiểm soátĐó là lý do tại sao các nhà sản xuất thường xác thực nghiêm ngặt từng giai đoạn: một khóa được ghi vào thiết bị sẽ xác minh bộ nạp khởi động đầu tiên, bộ nạp khởi động này sẽ xác minh bộ nạp khởi động tiếp theo là bộ nạp khởi động ứng dụng và cuối cùng là hạt nhân.
Với hạt nhân đã được xác minh, dm-verity được bật khi gắn thiết bị khối đã xác minhThay vì băm toàn bộ thiết bị (điều này sẽ chậm và lãng phí năng lượng), thiết bị sẽ được xác minh từng khối khi được truy cập. Lỗi I/O sẽ gây ra lỗi I/O, và các dịch vụ và ứng dụng sẽ phản ứng theo mức độ chịu đựng của chúng: hoặc tiếp tục mà không có dữ liệu đó hoặc bị sập hoàn toàn.
Sửa lỗi chuyển tiếp (FEC)
Kể từ Android 7.0, FEC (Reed–Solomon) được kết hợp với các kỹ thuật xen kẽ để giảm dung lượng và tăng khả năng phục hồi các khối bị hỏng. Tính năng này hoạt động kết hợp với dm-verity: nếu kiểm tra không thành công, hệ thống con có thể thử sửa lỗi trước khi tuyên bố không thể phục hồi.
Hiệu suất và tối ưu hóa
Để giảm tác động: Cho phép tăng tốc SHA-2 bằng NEON trên ARMv7 và phần mở rộng SHA-2 trên ARMv8 từ kernel. Điều chỉnh các tham số read-ahead và prefetch_cluster cho phần cứng của bạn; xác minh theo từng khối thường không làm tăng nhiều chi phí I/O, nhưng những thiết lập này tạo nên sự khác biệt.
Bắt đầu với Linux (systemd, veritysetup) và Android
Trên một Linux hiện đại với systemd, dm-verity cho phép một root chỉ đọc được xác minh sử dụng veritysetup (một phần của cryptsetup), systemd-veritysetup.generator và systemd-veritysetup@.service. Khuyến nghị nên bao gồm Secure Boot và UKI (hình ảnh hạt nhân hợp nhất) đã ký, mặc dù chúng không bắt buộc.
Chuẩn bị và phân vùng được đề xuất
Một phần của hệ thống chức năng và được điều chỉnh. Dành riêng một khối lượng cho cây băm (8–10% kích thước thư mục gốc thường là đủ) và cân nhắc tách /home và /var nếu bạn cần ghi. Một sơ đồ điển hình bao gồm: ESP (cho bộ nạp khởi động), XBOOTLDR (cho UKI), root (có hoặc không mã hóa), phân vùng VERITY, và tùy chọn /home và /var.
Là một gốc rễ, EROFS là một sự thay thế rất thú vị cho ext4 hoặc squashfs: Theo thiết kế, nó chỉ đọc, có hiệu suất rất tốt trên flash/SSD, nén lz4 theo mặc định và được sử dụng rộng rãi trên điện thoại Android với dm-verity.
Các tập tin phải có khả năng ghi
Với root ro, một số chương trình mong đợi ghi vào /etc hoặc trong quá trình initBạn có thể di chuyển nó đến /var/etc và tạo liên kết tượng trưng cho bất kỳ thay đổi nào (ví dụ: kết nối NetworkManager trong /etc/NetworkManager/system-connections). Lưu ý rằng systemd-journald yêu cầu /etc/machine-id phải tồn tại trong thư mục gốc (không phải liên kết tượng trưng) để tránh làm gián đoạn quá trình khởi động ban đầu.
Để tìm hiểu những thay đổi trong quá trình thực hiện, sử dụng dracut-overlayroot: phủ một tmpfs lên thư mục gốc, và mọi thứ được viết sẽ xuất hiện trong /run/overlayroot/u. Thêm mô-đun vào /usr/lib/dracut/modules.d/, bao gồm overlayroot trong dracut và đặt overlayroot=1 trên dòng kernel; bằng cách này, bạn sẽ thấy những gì cần di chuyển đến /var.
Ví dụ hữu ích: pacman và NetworkManager
Trong Arch, nó rất tiện lợi Di chuyển cơ sở dữ liệu Pacman đến /usr/lib/pacman để rootfs luôn phản chiếu các gói đã cài đặt. Sau đó, chuyển hướng bộ nhớ đệm đến /var/lib/pacman và liên kết. Để thay đổi danh sách phản chiếu mà không cần chạm vào root, hãy di chuyển nó đến /var/etc và liên kết nó.
Với NetworkManager, di chuyển các kết nối hệ thống đến /var/etc/NetworkManager và liên kết từ /etc/NetworkManager/system-connections. Điều này giữ cho root không thể thay đổi và cấu hình luôn ở trạng thái có thể ghi.
Xây dựng sự chân thực và thử nghiệm
Từ một live và với mọi thứ hoàn hảo và được gắn kết trong ro, tạo cây và roothash với định dạng veritysetup: Khi chạy, nó sẽ in ra dòng Root Hash, bạn có thể lưu vào roothash.txt. Chạy thử nghiệm với lệnh veritysetup, open root-device root verity-device $(cat roothash.txt) và mount /dev/mapper/root.
Nếu bạn thích, đầu tiên tạo cây vào một tệp (verity.bin) rồi ghi vào phân vùng VERITY. Tập hợp kết quả là: ảnh gốc, cây verity và băm gốc mà bạn sẽ ghim khi khởi động.
Cấu hình dòng hạt nhân
Thêm các tham số sau: systemd.verity=1, roothash=contents_of_roothash.txt, systemd.verity_root_data=ROOT-PATH (ví dụ: LABEL=OS) và systemd.verity_root_hash=VERITY-PATH (ví dụ: LABEL=VERITY). Đặt systemd.verity_root_options thành khởi động lại khi bị hỏng hoặc báo động khi bị hỏng cho các chính sách nghiêm ngặt.
Các lựa chọn được đề xuất khác: ro (nếu bạn không sử dụng EROFS/squashfs), rd.emergency=khởi động lại y rd.shell=0 (ngăn chặn các shell trái phép nếu khởi động không thành công) và khóa chặt = bảo mật để bảo vệ bộ nhớ hạt nhân khỏi bị truy cập.
Phân vùng bổ sung với verity
Không chỉ là gốc rễ: Bạn có thể xác định các ánh xạ khác trong /etc/veritytab và systemd-veritysetup@.service sẽ tự động lắp ráp chúng khi khởi động. Lưu ý: việc mount RW một phân vùng không phải root sẽ dễ dàng hơn, và người dùng root có thể vô hiệu hóa Verity trên các phân vùng đó, do đó giá trị bảo mật ở đó sẽ thấp hơn.
Bảo mật: Secure Boot, UKI và các mô-đun đã ký
dm-verity không phải là giải pháp hoàn hảo. Đăng ký UKI và kích hoạt Secure Boot bằng khóa của riêng bạn để ngăn chặn bất kỳ ai ghi đè kernel/initramfs/cmdline (bao gồm cả mã băm gốc). Các công cụ như sbupdate-git hoặc sbctl giúp giữ nguyên chữ ký của ảnh và chuỗi khởi động.
Nếu bạn kích hoạt khóa hạt nhân hoặc xác minh chữ ký mô-đun, Các mô-đun DKMS hoặc ngoài cây phải được ký nếu không chúng sẽ không tải được. Hãy cân nhắc sử dụng kernel tùy chỉnh có hỗ trợ ký cho pipeline của bạn (xem mô-đun kernel đã ký).
Mã hóa, TPM và đo lường
dm-verity bảo vệ tính toàn vẹn, không bảo mậtBạn có thể để root không được mã hóa nếu nó không chứa bất kỳ bí mật nào và chuỗi khởi động được bảo vệ. Nếu bạn sử dụng tệp khóa từ root để mở khóa các ổ đĩa khác, thì tốt nhất là nên mã hóa nó.
Với TPM 2.0, systemd-cryptenroll cho phép liên kết các khóa với PCR 0,1,5,7 (phần mềm, tùy chọn, GPT, trạng thái khởi động an toàn). Thêm rd.luks.options=LUKS_UUID=tpm2-device=auto và đảm bảo hỗ trợ TPM2 trong initramfs. systemd-boot đo kernel.efi trong PCR4, hữu ích để vô hiệu hóa các khóa nếu UKI hoặc dòng lệnh của nó thay đổi.
Cập nhật và mô hình triển khai
Một root chỉ đọc đã được xác minh Nó không được cập nhật bằng trình quản lý gói theo cách truyền thống. Lý tưởng nhất là xây dựng hình ảnh mới bằng các công cụ như dự án Yocto và xuất bản chúng. systemd có systemd-sysupdate và systemd-repart để tải xuống và cài đặt hình ảnh mạnh mẽ.
Một chiến lược khác là Sơ đồ A/B: Bạn giữ lại hai root và hai verity. Sao chép root đang hoạt động sang root không hoạt động, áp dụng các thay đổi và làm lại verity. Chuyển lại trạng thái ban đầu ở lần khởi động tiếp theo. Nếu bạn đang sử dụng UKI, hãy nhớ cập nhật băm root trong dòng lệnh cmd hoặc xây dựng lại UKI đã ký.
Đối với sự kiên trì tùy chọn, sử dụng OverlayFS trên root đã được xác minh với upper trong tmpfs hoặc disk. Bạn cũng có thể truyền systemd.volatile=overlay để duy trì tạm thời. Flatpak giúp dễ dàng cài đặt ứng dụng trong /var và /home mà không cần chạm vào /.
Có các gói tự động (ví dụ: verity-squash-root trong AUR) xây dựng một root squashfs và ký roothash bằng kernel và initramfs, cho phép bạn chọn giữa chế độ lưu trữ liên tục hoặc tạm thời và lưu trữ rootfs mới nhất làm bản sao lưu. Lưu ý: việc thêm tính năng lưu trữ liên tục vào root đã xác minh có phạm vi sử dụng hạn chế; hãy thử lưu trữ dữ liệu ứng dụng trên các phân vùng riêng biệt.
Android: hệ thống dưới dạng root, AVB và lớp phủ nhà cung cấp
Kể từ Android 10, RootFS ngừng chạy trên đĩa RAM và tích hợp với system.img. (system-as-root). Các thiết bị khởi chạy Android 10 luôn sử dụng sơ đồ này và yêu cầu phải có ramdisk cho dm-linear. BOARD_BUILD_SYSTEM_ROOT_IMAGE được đặt thành false trong bản dựng này để phân biệt giữa việc sử dụng ramdisk và kích hoạt trực tiếp system.img.
Android 10 tích hợp phân vùng động và khởi tạo giai đoạn đầu điều này kích hoạt phân vùng hệ thống logic; hạt nhân không còn gắn kết trực tiếp phân vùng này nữa. Các OTA chỉ dành cho hệ thống yêu cầu thiết kế hệ thống dưới dạng root, bắt buộc trên các thiết bị Android 10.
Không có A/B, giữ quá trình phục hồi tách biệt với quá trình khởi độngKhông giống như A/B, không có bản sao lưu boot_a/boot_b, do đó việc xóa chế độ phục hồi trong chế độ không phải A/B có thể khiến bạn không có chế độ phục hồi nếu bản cập nhật khởi động không thành công.
Hạt nhân gắn system.img vào /converity thông qua hai đường dẫn: vboot 1.0 (bản vá cho hạt nhân để phân tích siêu dữ liệu Android trong /system và lấy các tham số dm-verity; lệnh bao gồm root=/dev/dm-0, skip_initramfs và init=/init với dm=…) hoặc vboot 2.0/AVB, trong đó bộ nạp khởi động tích hợp libavb, đọc mô tả hashtree (trong vbmeta hoặc hệ thống), xây dựng các tham số và truyền chúng tới hạt nhân trong cmdline, với hỗ trợ FEC và các cờ như restart_on_corruption.
Với hệ thống như root, không sử dụng BOARD_ROOT_EXTRA_FOLDERS đối với các thư mục gốc dành riêng cho thiết bị: những thư mục này sẽ biến mất khi flash GSI. Xác định các mount cụ thể trong /mnt/vendor/ , được fs_mgr tự động tạo ra và tham chiếu đến chúng trong fstab của cây thiết bị.
Android cho phép một lớp phủ nhà cung cấp từ /product/vendor_overlay/: init sẽ gắn kết trong /vendor các thư mục con đáp ứng các yêu cầu ngữ cảnh SELinux và sự tồn tại của /vendor/ . Yêu cầu CONFIG_OVERLAY_FS=yy, trên các kernel cũ hơn, bản vá override_creds=off.
Triển khai điển hình: cài đặt các tập tin được biên dịch trước trong thiết bị/ / /vendor_overlay/, thêm chúng vào PRODUCT_COPY_FILES với find-copy-subdir-files vào $(TARGET_COPY_OUT_PRODUCT)/vendor_overlay, định nghĩa ngữ cảnh trong file_contexts cho etc và app (ví dụ: vendor_configs_file và vendor_app_file) và cho phép mounton trên các ngữ cảnh đó trong init.te. Kiểm tra bằng atest vfs_mgr_vendor_overlay_test trong userdebug.
Khắc phục sự cố: thông báo lỗi dm-verity trên Android
Trên các thiết bị có khe cắm A/B, hãy thay đổi khe cắm hoặc Đang flash vbmeta/boot mà không có sự nhất quán của roothash Điều này có thể kích hoạt cảnh báo: dm-verity corruption, thiết bị của bạn không đáng tin cậy. Các lệnh như fastboot flash –disable-verity –disable-verification vbmeta vbmeta.img sẽ vô hiệu hóa xác minh, nhưng không đảm bảo tính toàn vẹn của hệ thống.
Một số bộ nạp khởi động hỗ trợ fastboot oem vô hiệu hóa_dm_verity và đối lập của nó, enable_dm_verity. Nó hoạt động trên một số mô hình, nhưng không hoạt động trên các mô hình khác; và nó có thể yêu cầu kernel/magisk với các cờ đã được điều chỉnh. Sử dụng với rủi ro của riêng bạn: hành động thận trọng là căn chỉnh boot, vbmeta và hệ thống, ký hoặc tạo lại cây và đảm bảo rằng băm gốc dự kiến khớp với băm đã cấu hình.
Nếu sau khi cảnh báo bạn có thể tiếp tục nhấn nguồn, hệ thống sẽ khởi động, nhưng bạn không còn có một chuỗi tin cậy nguyên vẹn nữaĐể xóa tin nhắn mà không ảnh hưởng đến bảo mật, hãy khôi phục hình ảnh đã ký gốc hoặc xây dựng lại/xác minh vbmeta bằng hashtree chính xác, thay vì vô hiệu hóa verity.
Nền tảng i.MX và OpenWrt
Trên i.MX6 (ví dụ: sabresd), cấu hình hạt nhân với hỗ trợ DM_VERITY và FEC, tạo cây với veritysetup, lưu trữ băm gốc một cách an toàn và truyền các tham số thích hợp vào dòng lệnh cmd hoặc tích hợp qua initramfs với systemd-veritysetup. Nếu bạn không sử dụng dm-crypt, bạn không cần CAAM cho verity; trọng tâm là tính toàn vẹn.
Trong OpenWrt và trong hệ thống Linux nhúng với OpenEmbedded, Có những nỗ lực để tích hợp dm-verity và SELinux (Các tác vụ Bootlin được sửa đổi với mục đích tích hợp hỗ trợ). Đây là sự phù hợp tự nhiên: bộ định tuyến và thiết bị mạng được hưởng lợi từ root không thể thay đổi, đã được xác minh và được bảo vệ bằng MAC.
Xây dựng cây thủ công và siêu dữ liệu (xem chi tiết)
cryptsetup có thể tạo cây cho bạn, nhưng nếu bạn muốn hiểu định dạng, định nghĩa dòng bảng nhỏ gọn bao gồm: tên ánh xạ, thiết bị dữ liệu, khối dữ liệu và kích thước băm, kích thước hình ảnh theo khối, vị trí hash_start (ảnh khối + 8 nếu nối), băm gốc và salt. Sau khi tạo các lớp nối (từ trên xuống dưới, không bao gồm lớp 0), bạn ghi cây vào đĩa.
Để đóng gói mọi thứ, soạn thảo bảng dm-verity, ký tên vào đó (điển hình là RSA-2048) và nhóm chữ ký + bảng trong siêu dữ liệu với tiêu đề được đánh số phiên bản và số ma thuật. Sau đó, nó nối ảnh hệ thống, siêu dữ liệu verity và cây băm. Trong fstab, nó đánh dấu fs_mgr là verify và đặt khóa công khai vào /boot/verity_key để xác thực chữ ký.
Tối ưu hóa với Tăng tốc SHA-2 cho CPU của bạn và điều chỉnh read-ahead/prefetch_cluster. Trên phần cứng ARM, NEON SHA-2 (ARMv7) và các phần mở rộng SHA-2 (ARMv8) giúp giảm đáng kể chi phí xác minh.
Trong bất kỳ lần triển khai nào, hãy nhớ rằng giá trị băm gốc phải được bảo vệ: cho dù được biên dịch thành UKI đã ký, vào phân vùng khởi động đã ký hay được xác thực bởi trình khởi động bằng AVB. Mọi thứ sau đó đều được kế thừa sự tin cậy đó.
Với tất cả những điều trên, dm-verity trở thành nền tảng vững chắc cho các hệ thống nhúng, di động và bất biến, hỗ trợ cập nhật giao dịch, lớp phủ cấu hình và mô hình bảo mật hiện đại giúp giảm bề mặt tấn công và ngăn chặn sự tồn tại dai dẳng mà không ảnh hưởng đến hiệu suất.
