docs: say which filesystem detects a modified block - #1153
Merged
Conversation
h4x3rotab
force-pushed
the
ext4-encryption-auth-limitation
branch
from
August 28, 2026 00:18
d09e8d3 to
6cf8c25
Compare
The LUKS2 volume carries no authentication tag, so detecting a modified block is left to the filesystem. ZFS checksums every block and fails the read. ext4 checksums metadata but not file data, so the modified block reaches the application. The security model said ext4 "may forgo strong integrity protection", which describes our uncertainty rather than the system's behavior. The storage_fs row described ZFS as having "built-in data protection features", which says nothing a reader can act on. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
h4x3rotab
force-pushed
the
ext4-encryption-auth-limitation
branch
from
August 28, 2026 00:20
6cf8c25 to
5b62954
Compare
h4x3rotab
enabled auto-merge (squash)
August 28, 2026 00:27
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The CVM data disk is a LUKS2 volume using
aes-xts-plain64, andvalidate_luks2_headersindstack-util/src/system_setup.rsrejects a segment that sets dm-integrity. There is no authentication tag, so detecting a modified block is left to the filesystem. ZFS is created withchecksum=blake3inside the encrypted volume and fails the read. ext4 checksums metadata but not file data, so the modified block reaches the application.Two rows in the security docs did not say this:
security-model.mdsaid switching to ext4 "may forgo strong integrity protection". That states our uncertainty, not the system's behavior.storage_fsrow incvm-boundaries.mddescribed ZFS as having "built-in data protection features", which a reader cannot act on.Phala Cloud exposes the same choice. Matching change in Phala-Network/phala-docs#169.