A host may need to keep independently updated executables, packages, models, or data on a writable filesystem while still detecting modification of file contents after an artifact has been accepted. A one-time userspace hash can identify the bytes at one moment, but it does not make later reads depend on that measurement. The file may be opened again, pages may be evicted and reloaded, and storage below the page cache may return different data.
Linux fs-verity moves this integrity check into the filesystem read path for individual files. Once verity is enabled, the file becomes read-only and its data is associated with a Merkle tree. Reads are checked against that tree, and userspace can retrieve a compact digest representing the protected file. The mechanism supplies integrity enforcement for file data; deciding which digest is trusted remains a separate authentication problem.
Enabling verity turns mutable data into a measured object
FS_IOC_ENABLE_VERITY enables the feature on a regular file in a filesystem that supports fs-verity. The operation constructs and persists verity metadata, including a Merkle tree and descriptor. After successful enablement, the file cannot be opened for writing or truncated.
This transition is intentionally one-way for the file. The filesystem does not expose a normal operation that disables verity and returns the same inode to mutable data. Content updates therefore require a different file object, followed by a new verity enablement and a new digest.
That property gives deployment systems a useful boundary. Bytes are mutable while an artifact is being assembled. After the artifact reaches its accepted state, enabling verity freezes its data and makes future reads subject to verification. Atomic replacement or another publication mechanism can then move a newly prepared object into service without treating an enabled file as an in-place update target.
The read-only guarantee is narrower than complete inode immutability. Metadata outside the measured file data can still change where filesystem rules permit it. Linux documentation specifically notes that ownership, mode, timestamps, and extended attributes are not part of the protected data measurement. A security claim based on fs-verity must therefore identify file contents as the protected object rather than treating every inode attribute as cryptographically fixed.
The Merkle tree makes verification proportional to accessed data
A conventional pre-use hash requires reading the complete file before the verifier can compare its digest. fs-verity instead stores a Merkle tree over file data. The root is incorporated into the fs-verity file digest together with descriptor information.
When a data block is read, the filesystem verifies it through the relevant Merkle-tree path. This permits integrity checking for pages that are actually accessed without forcing every consumer to hash the entire file before use. It also means verification is not merely an admission-time event: data brought into memory later remains subject to the filesystem’s verity checks.
Corruption detected during a read() path is reported as EIO. For memory-mapped access, a verification failure can surface as SIGBUS. Applications that consume verity files through mmap() therefore need an operational model that accounts for integrity failure after the mapping itself has been established.
The tree does not hide data and does not provide confidentiality. Anyone with ordinary read permission can read the plaintext file. The security property is detection of data that no longer matches the enabled measurement.
A digest is an identity value, not a trust decision
Userspace can obtain the enforced file digest with FS_IOC_MEASURE_VERITY. Retrieving this digest does not require hashing the entire file at request time because the filesystem already maintains the verity metadata.
The digest can serve as a content identity in an authorization or deployment policy. A launcher might accept only digests present in signed release metadata. An audit system might record the digest of a file before execution. Integrity Measurement Architecture or another policy engine can also use verity measurements as input to a broader trust decision.
fs-verity alone does not establish who approved a digest. If an attacker can replace both an expected digest and the file referenced by a weak policy, successful verity checks only prove consistency with the attacker’s replacement. Authentication must bind the digest to a trust root or policy state that the attacker cannot rewrite under the same authority.
Linux also supports optional built-in signature verification when the kernel is configured for it. That facility verifies a PKCS#7 signature associated with the fs-verity digest against certificates in the dedicated kernel keyring. It is one possible authentication design, not an intrinsic property of every verity file. Userspace signature verification and policy frameworks can provide different trust boundaries.
Path identity remains separate from content identity
A verity digest describes protected content, not a permanent pathname. An enabled file can still be renamed, linked, or deleted subject to normal filesystem permissions. Another file can later occupy the same pathname.
This distinction matters when a privileged component checks a path and later expects the same content to remain there. Verity prevents the protected inode’s data from being rewritten, but it does not make a directory entry immutable. Stable acquisition still requires normal race-resistant file-opening practices, and a policy that cares about content should measure or authenticate the file object actually acquired.
Hard links create the same separation. Multiple names may refer to the same verity inode and therefore the same protected data. Conversely, pathname replacement can direct a later open to a different inode with a different digest.
The mechanism is therefore strongest when content identity and namespace policy are treated as separate controls. Directory permissions govern which object a name resolves to; fs-verity governs whether reads from an enabled object match its recorded data measurement.
Verification depends on filesystem and kernel support
fs-verity is a support layer implemented by participating filesystems rather than a universal property of every Linux mount. Current kernel documentation lists ext4, f2fs, and btrfs among supported filesystems. The kernel must also be built with the relevant verity support, and filesystem-specific prerequisites can apply.
A deployment cannot infer verity protection from a filename, mount location, or application convention. It must successfully enable the feature and, where the security decision depends on it, confirm or measure the resulting verity state.
Direct I/O is not used to bypass verification. Linux documents that direct I/O requests on verity files fall back to buffered I/O. DAX is incompatible with verity because direct access to persistent memory would bypass the normal verified read path.
These constraints are implementation properties of Linux fs-verity. They should not be generalized into guarantees for unrelated Merkle-tree formats or userspace integrity libraries.
Encryption and integrity protect different representations
A filesystem can support encryption and verity on the same file. In the documented ext4 design, the verity measurement covers plaintext rather than ciphertext. This keeps the content digest meaningful independently of per-file encryption details.
That composition separates two properties. Filesystem encryption controls exposure of file contents when the key is unavailable. Verity detects data that fails to match the accepted plaintext measurement. Neither property substitutes for the other.
The order also affects the trust statement. A valid verity read means the plaintext delivered through the filesystem matches the enabled digest. It does not assert that the storage device never observed ciphertext, that the encryption key is protected by a particular hardware boundary, or that surrounding metadata is authenticated.
The security boundary ends at verified file data
fs-verity is most precise when used as a content-integrity primitive rather than a complete file-trust system. Its irreversible enablement removes in-place data mutation, its Merkle tree ties later reads to an established measurement, and its digest gives policy code a compact identity for the protected content.
The remaining decisions stay outside that primitive: which digest is authorized, which pathname may name the object, which metadata changes are acceptable, and which filesystem supports the required semantics. Keeping those boundaries explicit prevents a successful verity check from being stretched into claims about provenance, namespace stability, confidentiality, or complete inode immutability that the mechanism does not provide.