fs-verity thực chiến: Bảo vệ tính toàn vẹn file chỉ-đọc trên Linux

Checksum lưu cạnh một file chỉ phát hiện thay đổi khi có tiến trình chủ động băm lại toàn bộ file. fs-verity đưa việc kiểm tra vào filesystem: sau khi bật, nội dung file trở thành bất biến, được liên kết với một Merkle tree và từng block đọc vào page cache phải vượt qua kiểm tra toàn vẹn.

Bài viết này triển khai fs-verity cho artifact, model AI, binary và dữ liệu lớn nằm trên filesystem vẫn ghi được. Nội dung dựa trên tài liệu fs-verity của Linux kernel và fsverity-utils. Trọng tâm là ranh giới bảo mật, quy trình phát hành nguyên tử, trust digest và vận hành production.

1. fs-verity thực sự bảo vệ điều gì?

Khi bật verity cho một regular file, filesystem xây Merkle tree từ nội dung và lưu metadata theo cách riêng của filesystem. File trở thành chỉ-đọc. Với các lần đọc sau, kể cả read(), pread() và mmap(), kernel xác minh block cần dùng với đường dẫn hash tới root; dữ liệu sai lệch không được trả cho ứng dụng.

Digest đo bằng fs-verity nhận diện nội dung đang được kernel thực thi kiểm tra, nhưng không giống checksum SHA-256 truyền thống của toàn file. Nó bao gồm cấu trúc descriptor/Merkle tree theo format fs-verity. Vì vậy không so sánh trực tiếp output fsverity measure với sha256sum.

2. Integrity chưa tự động là authenticity

Nếu chỉ chạy fsverity enable, hệ thống phát hiện hỏng dữ liệu ngẫu nhiên. Một attacker có quyền thay cả file và bật verity lại có thể tạo digest mới hoàn toàn hợp lệ. Muốn chống sửa độc hại, consumer phải so digest đo được với giá trị đến từ nguồn tin cậy, hoặc áp dụng cơ chế chữ ký và policy enforcement phù hợp.

Trust anchor có thể là manifest phát hành được ký, metadata trong control plane, trusted userspace loader, IMA appraisal hoặc một thiết kế chữ ký khác. Kernel documentation lưu ý built-in PKCS#7 signature không phải lựa chọn duy nhất và có giới hạn; đừng bật chỉ vì muốn có nhãn “signed”.

3. Khác dm-verity, IMA và checksum thông thường

fs-verity không thay thế dm-verity. Dùng dm-verity cho root/image bất biến; dùng fs-verity khi từng artifact cần cập nhật độc lập trên một volume read-write.

4. Kiểm tra điều kiện kernel và filesystem

Kernel cần CONFIG_FS_VERITY, filesystem phải hỗ trợ và feature tương ứng phải bật. Tài liệu kernel hiện liệt kê ext4, f2fs và btrfs; phiên bản kernel, công cụ filesystem và distribution quyết định khả năng thực tế.

grep FS_VERITY /boot/config-$(uname -r)
findmnt -no SOURCE,FSTYPE,OPTIONS /srv/artifacts
fsverity --version

# Với ext4: thay thiết bị bằng kết quả đã xác minh từ findmnt
sudo tune2fs -l /dev/mapper/data | grep 'Filesystem features'

ext4 mới có thể được tạo với mkfs.ext4 -O verity. Bật feature trên volume hiện hữu là thay đổi filesystem: backup, xác minh chính xác device, đọc tài liệu e2fsprogs của distribution và thực hiện trong maintenance workflow đã thử nghiệm. Không sao chép một lệnh tune2fs vào production khi volume hoặc khả năng rollback chưa rõ.

5. Luồng thử nghiệm tối thiểu

sudo apt install fsverity

cp release/model-v42.bin /srv/artifacts/.model-v42.bin.staging
sync
fsverity digest /srv/artifacts/.model-v42.bin.staging
sudo fsverity enable /srv/artifacts/.model-v42.bin.staging
sudo fsverity measure /srv/artifacts/.model-v42.bin.staging

digest tính digest dự kiến trong userspace; enable yêu cầu file ổn định và không có writable file descriptor/mapping; measure lấy digest mà kernel đang thực thi. Ghi lại algorithm cùng digest, không chỉ chuỗi hex trần.

Sau khi enable thành công, không thể sửa nội dung hoặc tắt verity trên inode đó. Đây là one-way transition. Có thể xóa hoặc thay tên nếu quyền thư mục cho phép, nên “file bất biến” không đồng nghĩa pathname không thể bị thay thế.

6. Quy trình publish artifact nguyên tử

1. Tải artifact vào file staging cùng filesystem với đích.
2. Kiểm tra kích thước, checksum từ pipeline và chữ ký/attestation trước khi enable.
3. fsync file khi durability là yêu cầu; đóng mọi writer.
4. Bật fs-verity và đo lại digest.
5. So digest với manifest tin cậy bằng phép so sánh chính xác.
6. Đổi tên staging sang tên versioned bằng atomic rename trên cùng filesystem.
7. Cập nhật symlink hoặc metadata “current” riêng, rồi health-check consumer.

sudo mv /srv/artifacts/.model-v42.bin.staging \
  /srv/artifacts/model-v42.bin

sudo ln -sfn model-v42.bin /srv/artifacts/model-current.next
sudo mv -Tf /srv/artifacts/model-current.next \
  /srv/artifacts/model-current

Không ghi đè một file verity để cập nhật. Tạo inode/version mới, xác minh xong rồi chuyển pointer. Giữ version cũ trong cửa sổ rollback thay vì cố “undo” verity.

7. Thiết kế manifest và trust

{
  "name": "model-v42.bin",
  "size": 734003200,
  "fsverity_algorithm": "sha256",
  "fsverity_digest": "<hex digest from approved pipeline>",
  "release": "42",
  "created_at": "2026-10-05T09:00:00Z"
}

Manifest phải được xác thực độc lập: chữ ký release, kho metadata có kiểm soát hoặc channel đã được tin cậy. Nếu artifact và manifest nằm cùng thư mục, cùng quyền ghi và không có chữ ký, attacker có thể thay cả hai.

Consumer đáng tin nên đo digest ngay trước khi mở hoặc trước khi chấp nhận version, kiểm tra tên/size/version theo policy, rồi sử dụng file descriptor đã mở để giảm khoảng trống time-of-check/time-of-use. Pathname có thể bị đổi giữa hai lần lookup dù nội dung của inode verity không đổi.

8. Quyền file và thư mục vẫn rất quan trọng

fs-verity bảo vệ data blocks của file, không tự bảo vệ tên file, owner, mode, mọi xattr, symlink bên cạnh hay directory entry. Hãy hạn chế quyền ghi thư mục phát hành, tách identity deploy khỏi identity chạy ứng dụng và không cho service tự thay pointer “current”.

Root hoặc một actor có quyền mount/storage mạnh vẫn có thể xóa, thay thế hay gây từ chối dịch vụ. fs-verity biến sửa thầm nội dung thành lỗi có thể phát hiện; nó không tạo availability, access control hoặc sandbox.

9. Khi dữ liệu bị hỏng

Verification diễn ra khi block được đọc. File có thể measure thành công nhưng một block chưa đọc đã hỏng; lỗi chỉ xuất hiện khi workload chạm block đó. Ứng dụng phải xử lý lỗi I/O rõ ràng, không retry vô hạn hoặc dùng dữ liệu một phần.

journalctl -k --since today | grep -i verity
fsverity measure /srv/artifacts/model-v42.bin

# Scrub ở tầng filesystem/storage nếu nền tảng hỗ trợ
# Đọc tuần tự toàn file trong job kiểm tra có kiểm soát để chạm mọi block

Phản ứng an toàn thường là cô lập artifact, chuyển consumer về version đã biết tốt, lưu log thiết bị/filesystem và phục hồi từ nguồn tin cậy. Không “sửa” một vài byte trong inode đã bật verity.

10. Backup, restore và copy

Một bản sao nội dung có thể có checksum truyền thống giống nhau nhưng không mặc nhiên giữ trạng thái/metadata fs-verity. Khả năng preserve phụ thuộc công cụ, filesystem và định dạng backup. Quy trình restore nên coi file là artifact mới: phục hồi vào staging, xác minh checksum/chữ ký, enable verity, measure rồi so manifest.

Test restore phải chạy trên filesystem đích thật. Đừng chỉ test tar/rsync trả lại số byte đúng; hãy xác nhận fsverity measure, consumer policy và hành vi sau reboot/remount.

11. Chi phí và capacity planning

Enable phải đọc file và xây Merkle tree nên tốn I/O, CPU và thêm metadata storage. Với file lớn, thực hiện trong staging trước khi đưa vào đường phục vụ. Read-time verification thường theo các block thực sự được page-in, nhưng vẫn có chi phí hash và đọc hash blocks.

Benchmark workload thật: cold cache, warm cache, mmap ngẫu nhiên, startup đồng thời và storage chậm. Theo dõi thời gian enable, latency đọc, page faults, I/O, CPU và số lỗi integrity. Không suy ra overhead production từ một lần cat file nhỏ.

12. Kiểm thử và rollout

Không phá raw block của volume production để “thử corruption”. Dự án kernel khuyến nghị xfstests cho kiểm thử filesystem; lab riêng hoặc image disposable mới là nơi fault injection. Trong application test, có thể mô phỏng lỗi đọc và digest mismatch để xác nhận fail-closed, rollback và alert.

Rollout theo tầng: một artifact không quan trọng, một nhóm host canary, rồi mở rộng. Kiểm tra kernel/filesystem support, boot path, backup agent, scanner, deployment tool và container bind mount. Một công cụ cố ghi metadata hoặc thay file tại chỗ có thể thất bại sau khi verity được bật.

Checklist production

• Use case là file chỉ-đọc cập nhật theo version, không phải dữ liệu mutable.
• Kernel, filesystem, feature flag và fsverity-utils đã được xác minh trên host thật.
• Artifact được tạo trong staging, mọi writer đóng trước khi enable.
• Digest fs-verity được so với manifest có trust độc lập.
• Cập nhật bằng inode mới và atomic rename/pointer switch; version cũ được giữ để rollback.
• Quyền thư mục ngăn service hoặc actor ngoài quy trình thay pathname.
• Ứng dụng fail-closed khi đọc lỗi hoặc digest không khớp.
• Backup/restore đã test việc enable lại và measure trên filesystem đích.
• Canary đo latency, CPU, I/O và lỗi kernel trước khi rollout rộng.
• Runbook phân biệt corruption, thay thế file, mất file và lỗi storage.

Kết luận

fs-verity phù hợp khi artifact lớn cần sống trên filesystem ghi được nhưng nội dung của từng version phải bất biến và được kiểm tra khi đọc. Merkle tree giải quyết verification hiệu quả; nó không tự giải quyết trust. Một triển khai production hoàn chỉnh cần digest được xác thực, directory permissions, publish bằng inode mới, rollback theo version, restore test và consumer fail-closed. Đặt đúng ranh giới đó, fs-verity trở thành lớp integrity mạnh thay vì một checkbox dễ tạo cảm giác an toàn giả.