Sebuah host dapat perlu menyimpan executable, paket, model, atau data yang diperbarui secara independen pada filesystem writable sambil tetap mendeteksi perubahan isi file setelah artefak diterima. Hash userspace satu kali dapat mengidentifikasi byte pada satu saat, tetapi tidak membuat read berikutnya bergantung pada pengukuran tersebut. File dapat dibuka kembali, halaman dapat dikeluarkan dari cache lalu dimuat ulang, dan storage di bawah page cache dapat mengembalikan data yang berbeda.
Linux fs-verity memindahkan pemeriksaan integritas ini ke jalur read filesystem untuk setiap file. Setelah verity diaktifkan, file menjadi read-only dan datanya dikaitkan dengan Merkle tree. Read diperiksa terhadap tree tersebut, dan userspace dapat mengambil digest ringkas yang merepresentasikan file terlindungi. Mekanisme ini menyediakan enforcement integritas untuk data file; penentuan digest mana yang dipercaya tetap merupakan persoalan autentikasi terpisah.
Aktivasi verity mengubah data mutable menjadi objek terukur
FS_IOC_ENABLE_VERITY mengaktifkan fitur pada regular file di filesystem yang mendukung fs-verity. Operasi ini membangun dan menyimpan metadata verity, termasuk Merkle tree dan descriptor. Setelah aktivasi berhasil, file tidak dapat dibuka untuk penulisan atau di-truncate.
Transisi ini sengaja bersifat satu arah untuk file tersebut. Filesystem tidak menyediakan operasi normal yang menonaktifkan verity lalu mengembalikan inode yang sama menjadi data mutable. Pembaruan isi karena itu memerlukan objek file lain, diikuti aktivasi verity baru dan digest baru.
Properti tersebut memberi sistem deployment batas yang jelas. Byte tetap mutable saat artefak dirakit. Setelah artefak mencapai state yang diterima, aktivasi verity membekukan datanya dan membuat read berikutnya tunduk pada verifikasi. Atomic replacement atau mekanisme publikasi lain kemudian dapat memindahkan objek baru yang telah disiapkan ke layanan tanpa memperlakukan file yang sudah aktif verity sebagai target pembaruan in-place.
Jaminan read-only ini lebih sempit daripada immutability inode secara penuh. Metadata di luar data file yang diukur masih dapat berubah jika aturan filesystem mengizinkannya. Dokumentasi Linux secara khusus menyatakan bahwa ownership, mode, timestamp, dan extended attribute tidak termasuk dalam pengukuran data yang dilindungi. Klaim keamanan berbasis fs-verity karena itu harus menetapkan isi file sebagai objek terlindungi, bukan menganggap setiap atribut inode terkunci secara kriptografis.
Merkle tree membuat verifikasi mengikuti data yang diakses
Hash konvensional sebelum penggunaan memerlukan pembacaan seluruh file sebelum verifier dapat membandingkan digest. fs-verity menyimpan Merkle tree atas data file. Root tree dimasukkan ke digest file fs-verity bersama informasi descriptor.
Ketika sebuah blok data dibaca, filesystem memverifikasinya melalui jalur Merkle-tree yang relevan. Ini memungkinkan pemeriksaan integritas pada halaman yang benar-benar diakses tanpa memaksa setiap consumer melakukan hash terhadap seluruh file sebelum digunakan. Verifikasi juga bukan sekadar peristiwa saat penerimaan: data yang dimuat ke memori kemudian tetap tunduk pada pemeriksaan verity filesystem.
Korupsi yang terdeteksi pada jalur read() dilaporkan sebagai EIO. Untuk akses melalui memory mapping, kegagalan verifikasi dapat muncul sebagai SIGBUS. Aplikasi yang mengonsumsi file verity melalui mmap() karena itu memerlukan model operasional yang memperhitungkan kegagalan integritas setelah mapping dibuat.
Tree tersebut tidak menyembunyikan data dan tidak menyediakan confidentiality. Siapa pun yang memiliki izin read biasa dapat membaca plaintext file. Properti keamanannya adalah deteksi data yang tidak lagi cocok dengan pengukuran yang telah diaktifkan.
Digest adalah nilai identitas, bukan keputusan kepercayaan
Userspace dapat memperoleh digest file yang sedang di-enforce melalui FS_IOC_MEASURE_VERITY. Pengambilan digest ini tidak memerlukan hashing seluruh file pada saat permintaan karena filesystem sudah memelihara metadata verity.
Digest dapat berfungsi sebagai identitas konten dalam kebijakan otorisasi atau deployment. Launcher dapat menerima hanya digest yang tercantum dalam metadata rilis bertanda tangan. Sistem audit dapat mencatat digest file sebelum eksekusi. Integrity Measurement Architecture atau policy engine lain juga dapat memakai pengukuran verity sebagai input bagi keputusan kepercayaan yang lebih luas.
fs-verity sendiri tidak menetapkan pihak yang menyetujui sebuah digest. Jika penyerang dapat mengganti expected digest sekaligus file yang dirujuk oleh kebijakan lemah, pemeriksaan verity yang berhasil hanya membuktikan konsistensi dengan penggantian milik penyerang. Autentikasi harus mengikat digest ke trust root atau state kebijakan yang tidak dapat ditulis ulang oleh penyerang dengan otoritas yang sama.
Linux juga mendukung verifikasi signature bawaan opsional ketika kernel dikonfigurasi untuk fitur tersebut. Fasilitas itu memverifikasi signature PKCS#7 yang terkait dengan digest fs-verity terhadap certificate pada kernel keyring khusus. Ini merupakan salah satu rancangan autentikasi, bukan properti intrinsik setiap file verity. Verifikasi signature di userspace dan framework kebijakan dapat membentuk trust boundary yang berbeda.
Identitas path tetap terpisah dari identitas konten
Digest verity mendeskripsikan konten terlindungi, bukan pathname permanen. File yang sudah aktif verity masih dapat di-rename, diberi link, atau dihapus sesuai permission filesystem normal. File lain kemudian dapat menempati pathname yang sama.
Pemisahan ini penting ketika komponen privileged memeriksa sebuah path lalu mengharapkan konten yang sama tetap berada di sana. Verity mencegah data inode terlindungi ditulis ulang, tetapi tidak membuat directory entry immutable. Akuisisi stabil tetap memerlukan praktik pembukaan file yang tahan race, dan kebijakan yang peduli pada konten harus mengukur atau mengautentikasi objek file yang benar-benar diperoleh.
Hard link menunjukkan pemisahan yang sama. Beberapa nama dapat merujuk ke inode verity yang sama dan karena itu ke data terlindungi yang sama. Sebaliknya, penggantian pathname dapat mengarahkan open berikutnya ke inode berbeda dengan digest berbeda.
Mekanisme ini karena itu paling kuat ketika identitas konten dan kebijakan namespace diperlakukan sebagai kontrol terpisah. Permission directory mengatur objek mana yang dirujuk sebuah nama; fs-verity mengatur apakah read dari objek yang telah diaktifkan cocok dengan pengukuran data yang tersimpan.
Verifikasi bergantung pada dukungan filesystem dan kernel
fs-verity adalah support layer yang diimplementasikan filesystem yang berpartisipasi, bukan properti universal setiap mount Linux. Dokumentasi kernel saat ini mencantumkan ext4, f2fs, dan btrfs sebagai filesystem yang didukung. Kernel juga harus dibangun dengan dukungan verity yang relevan, dan prasyarat khusus filesystem dapat berlaku.
Deployment tidak dapat menyimpulkan proteksi verity dari nama file, lokasi mount, atau konvensi aplikasi. Sistem harus berhasil mengaktifkan fitur dan, ketika keputusan keamanan bergantung padanya, mengonfirmasi atau mengukur state verity yang dihasilkan.
Direct I/O tidak dipakai untuk melewati verifikasi. Linux mendokumentasikan bahwa permintaan direct I/O pada file verity beralih ke buffered I/O. DAX tidak kompatibel dengan verity karena akses langsung ke persistent memory akan melewati jalur read terverifikasi yang normal.
Batasan ini merupakan properti implementasi Linux fs-verity. Properti tersebut tidak dapat digeneralisasi menjadi jaminan bagi format Merkle tree lain atau library integritas userspace yang tidak terkait.
Enkripsi dan integritas melindungi representasi yang berbeda
Sebuah filesystem dapat mendukung enkripsi dan verity pada file yang sama. Dalam rancangan ext4 yang didokumentasikan, pengukuran verity mencakup plaintext, bukan ciphertext. Hal ini menjaga digest konten tetap bermakna tanpa bergantung pada detail enkripsi per file.
Komposisi itu memisahkan dua properti. Enkripsi filesystem mengendalikan paparan isi file saat key tidak tersedia. Verity mendeteksi data yang gagal cocok dengan pengukuran plaintext yang diterima. Tidak satu pun menggantikan properti lainnya.
Urutan tersebut juga memengaruhi pernyataan trust. Read verity yang valid berarti plaintext yang diberikan melalui filesystem cocok dengan digest aktif. Hal itu tidak menyatakan bahwa storage device tidak pernah melihat ciphertext, bahwa encryption key dilindungi oleh hardware boundary tertentu, atau bahwa metadata di sekelilingnya diautentikasi.
Batas keamanan berakhir pada data file yang diverifikasi
fs-verity paling presisi ketika dipakai sebagai primitive integritas konten, bukan sistem trust file yang lengkap. Aktivasi irreversibelnya menghapus mutasi data in-place, Merkle tree mengikat read berikutnya ke pengukuran yang sudah ditetapkan, dan digest memberi kode kebijakan identitas ringkas untuk konten terlindungi.
Keputusan lain tetap berada di luar primitive tersebut: digest mana yang diotorisasi, pathname mana yang boleh menunjuk objek, perubahan metadata mana yang dapat diterima, dan filesystem mana yang mendukung semantik yang dibutuhkan. Menjaga batas tersebut tetap eksplisit mencegah pemeriksaan verity yang berhasil diperluas menjadi klaim mengenai provenance, stabilitas namespace, confidentiality, atau immutability inode secara penuh yang tidak disediakan mekanisme ini.