What Read-Verified AI Appliance Storage Has Actually Checked

Follow a requested block to the trusted root

The Linux 6.18 documentation describes dm-verity as a read-only block-device target that checks integrity with cryptographic hashes. It describes a mechanism, rather than establishing that any particular AI appliance uses it. An appliance claim needs to identify the active mapping through which the relevant data is accessed.

For a requested data block, the verifier calculates a digest and compares it with the expected digest in the hash tree. Hashes of tree blocks connect that expectation upward to the trusted root. Authenticating this path lets the verifier check requested data without first reading the entire data image. The root is the endpoint of this authentication chain; its trust must come from outside the data and tree being checked.

Coverage belongs to the configured mapping and its data-block population. A mapping for a system image does not automatically cover a separate writable dataset volume. Read-only means writes are unavailable through this target. The underlying device can still suffer corruption or modification through another path, and integrity checking does not itself encrypt the stored data.

References: [KV]

VER4: two valid reads while B2 is already changed

VER4 is a fictional appliance with an active, correctly configured dm-verity mapping over four 4096-byte data blocks, B0 through B3. Its correct expected hash tree is authenticated to a fixed, trusted root R, and the mapping identity is established. R is a symbolic label, not an invented digest value.

B0, B1 and B3 contain the expected data. B2 has already changed on the underlying data device, while the expected tree and root remain unchanged. No relevant data block is already cached: the stipulated fresh reads actually reach the mapping. Correct bytes served from another cache or memory layer fall outside this example.

Assume default rejecting behavior. Exclude ignore_corruption, ignore_zero_blocks, check_at_most_once, forward error correction, restart and panic variants, and any other bypass. These premises define the example; they are not a recommendation to configure an appliance. No kernel execution or device test is being reported.

The appliance first reads only B0 and B1. Both verify successfully against R. Exactly 8192 of the mapping's 16384 data bytes have now been read and checked. B2 and B3 remain unread. The mapping can report V even though B2 is already corrupt: every check performed so far has succeeded.

These totals count only the four stipulated data blocks. Hash-tree bytes are outside the data-byte total. The one-half coverage fraction describes this example's read population; it supplies no performance measurement or probability of security.

References: [KV]

The first fresh B2 read exposes the difference

A hash-tree block can contain expected digests for several data blocks. Authenticating a tree block containing B2's expected digest establishes that expectation under R. It does not calculate a digest of B2's unread data. This is why reading the tree needed for B0 cannot establish that all neighboring data blocks are intact.

Now independently request a fresh read of B2. Under VER4's premises, its changed data cannot verify through the unchanged expected tree to R, so the read fails. The earlier V described the checks at that earlier point. It did not promise that this later request would succeed. Linux 6.18 defines C as the status when a check has failed.

The failed verification establishes a disagreement with the authenticated expectation under the stated conditions. It does not identify a failed drive, an accidental write or malicious interference as the cause. The earlier successful B0 and B1 checks remain evidence about those reads.

References: [KV]

A matching replacement root needs its own authorization

Suppose a supplier replaces the data image and its tree, then supplies a new root R2 that matches the replacement. The replacement can be internally consistent. That consistency leaves a different question open: why is R2 authorized for this appliance and the intended image?

R2 cannot establish its authority merely by agreeing with the data supplied alongside it. The buyer needs an authenticated basis for selecting the applicable root and identifying the mapping it governs. Otherwise, the comparison has changed both the offered content and its expected value without establishing permission to make that change.

Linux 6.18 explicitly places authentication outside the end of the hash chain. It also documents root-signature validation during mapping creation, subject to kernel configuration and trusted-keyring conditions. A supplier claiming signed-root enforcement therefore needs evidence of the actual enforcement and applicable trust context. A generic dm-verity label supplies neither.

References: [KV]

An authorized image can still be the wrong release

Now suppose an older image and its corresponding root remain authorized. Reads of that image can verify correctly. Those results establish agreement with the older authenticated expectation; they do not establish that the appliance contains the release the buyer requires.

The evidence must therefore connect the selected root and image identity to the required release. If the requirement is to prevent return to an older image, the applicable version and authorization policy must address that requirement separately. Hash-tree consistency alone supplies no rule that withdraws an older root's authority or requires the newest image.

This distinction also helps interpret an update. A changed root can be expected for a changed image, but its authorization and release applicability still need to be established. A root difference by itself resolves neither question.

References: [KV]

Read successful I/O under the actual verification policy

VER4 deliberately fixes its behavior. Actual supplier evidence needs the policy of the identified appliance. Linux 6.18 documents options that change how a read or corruption event should be interpreted.

With ignore_corruption, corruption is logged while reads are allowed to proceed. With check_at_most_once, data blocks are verified only on their first read from the data device; a later read need not provide a new verification of the current underlying bytes. With ignore_zero_blocks, blocks expected to contain zeroes return zeroes without verifying the underlying blocks.

Forward error correction can recover corrupted data; the recovered data must still pass the corresponding cryptographic check. Successful delivery can therefore follow verified recovery, rather than prove that no corruption was encountered. Restart and panic options change the system response to detected corruption or I/O errors.

These distinctions explain why the statement that every corrupt read fails cannot be transferred from VER4 to every dm-verity deployment. Establish the actual read and failure behavior before interpreting a supplier's successful I/O or status record.

References: [KV]

Decide which claim the supplier's evidence supports

A return saying only that the appliance is verity-enabled and shows V leaves the relevant mapping, root authorization, release and read coverage unresolved. The V status is a summary of checks performed so far, rather than a count of distinct blocks examined.

For VER4, a precise documentary statement would identify the four-block mapping, establish R's authorization and release applicability, describe the default failure policy, and identify the successful fresh reads of B0 and B1. That would support a useful, limited conclusion: those 8192 data bytes agreed with their authenticated expectations during those reads. It would leave B2 and B3's data unread at that point.

If the purchased claim concerns the complete mapped image, a separate record must support that complete coverage and identify the image and observation scope. Repeated reads of B0 and B1 cannot fill B2 and B3's coverage gap. Keep the decision tied to what the return demonstrates instead of promoting a valid-so-far status into a whole-image result.

The related Secure Boot and measured boot guide addresses startup authorization and appraisal. The S3 integrity guide addresses object and checksum comparisons. The confidential-computing guide addresses protected execution and attestation. Follow those guides when the claim extends into those decisions; a dm-verity read result cannot supply their separate evidence.

References: [KV]

Connect a separately needed physical installation

If the customer-selected appliance also needs physical installation, Leviathan's Rack-and-Stack Installation service can scope agreed equipment mounting, IT cabling, labels and physical installation records. Those records can connect installed equipment identities to the appointed platform team's references.

Use the related service and physical-project inquiry for that surrounding work. Share a nonconfidential equipment outline, site, released rack and cable plans, and requested physical handoff to discuss scope and availability. Storage-image authorization, dm-verity configuration and software acceptance remain with the appointed platform or security providers.

References: [L1]