Linux filesystems can store a Merkle tree with a file so the kernel detects changes to file contents during reads. The feature, fs-verity, presents a useful property for packaged applications, signed binaries, and immutable release artifacts on a writable filesystem. The kernel can return EIO for a modified page and raise SIGBUS for a mapped page that no longer matches the tree.
That integrity check answers whether the file content matches the tree that was enabled for the file. It does not answer whether the tree came from an approved publisher. A signer can create a valid fs-verity digest for malware just as easily as for a trusted package. The deployment needs a signature policy and a protected trust anchor before the digest provides publisher identity.
How the kernel check works
Userspace enables fs-verity through an ioctl. The filesystem builds a Merkle tree and persists it in a filesystem-specific location. The file becomes read-only in the sense that its contents cannot be changed while fs-verity remains enabled. The kernel verifies pages as they are read rather than scanning the entire file during every open.
The documentation describes three ways to authenticate a verity file. Trusted userspace can read the digest with FS_IOC_MEASURE_VERITY and verify a detached signature. The kernel can verify a signed digest stored with the file when built-in signature support is enabled. A combined design can use trusted userspace and kernel verification. Each approach needs a policy for certificate enrollment, revocation, and which files must have verity enabled.
The built-in signature mechanism uses certificates in the .fs-verity kernel keyring. A signature is verified when the file is opened. The kernel option fs.verity.require_signatures changes the requirement for signatures across fs-verity files. The mechanism does not, by itself, require that an installed application have fs-verity enabled. A policy layer such as an LSM or a package-management check must close that gap.
Treat the signing key as production infrastructure
A signing key for release files should not live on a build worker with broad network access. Keep it in a controlled signing service or a hardware-backed keystore. Sign a digest that has already been produced from the reviewed package, and record the package identity, version, hash, signer, and build provenance. The client should verify the certificate chain, the leaf key's intended use, the signature, and the file digest before accepting the result.
Certificate rotation needs a plan that does not silently widen trust. Publish the new signer or root with an overlap period, distribute updates through an authenticated channel, and keep the old verifier available only for the documented transition window. An emergency revocation path should be tested. A key that is trusted for both release artifacts and general server authentication creates unrelated blast radius, so separate signer roles where the platform permits it.
The build system should also reject unexpected file changes between signing and packaging. Hash the exact artifact, keep the signature with it, and verify the signature after transfer to the target system. Do not let an unsigned file acquire a trusted digest because a build script enabled fs-verity after replacing the original content.
Do not turn one primitive into a complete boot policy
fs-verity protects file content, not the filesystem metadata, the kernel, the boot chain, or the process that decides to open the file. The kernel documentation positions it alongside other integrity mechanisms rather than as a replacement for all of them. Read-only block-level verification, measured boot, and mandatory access policies solve different parts of the problem.
An application that must execute only approved code needs a policy that says which signer is acceptable for which path. The policy should cover interpreter files, shared libraries, plugins, and scheduled jobs. A signature on the main binary is not enough if the binary loads an unsigned plugin from a user-writable directory.
Test the failure modes with the actual storage stack. Modify one block of a verity file and attempt to read it. Test a mapped page. Replace the file with a different package that has its own valid tree, then verify that the signer policy rejects it. Remove the trusted certificate and confirm that the application fails closed rather than falling back to an unsigned path.
Alert on verification failures and on unexpected attempts to enable or disable verity. Log the file identity and signer result, not the file contents. Keep a recovery path for damaged storage that does not teach operators to disable verification permanently.
fs-verity is valuable when a writable system still needs strong detection of content changes. The security decision remains the same as with any signature system: identify the trusted signer, control the key, determine which files require verification, and prove that the enforcement path cannot be skipped.