Skip to content

docs: say which filesystem detects a modified block - #1153

Merged
h4x3rotab merged 1 commit into
nextfrom
ext4-encryption-auth-limitation
Aug 28, 2026
Merged

docs: say which filesystem detects a modified block#1153
h4x3rotab merged 1 commit into
nextfrom
ext4-encryption-auth-limitation

Conversation

@h4x3rotab

@h4x3rotab h4x3rotab commented Aug 27, 2026

Copy link
Copy Markdown
Contributor

The CVM data disk is a LUKS2 volume using aes-xts-plain64, and validate_luks2_headers in dstack-util/src/system_setup.rs rejects a segment that sets dm-integrity. There is no authentication tag, so detecting a modified block is left to the filesystem. ZFS is created with checksum=blake3 inside 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.md said switching to ext4 "may forgo strong integrity protection". That states our uncertainty, not the system's behavior.
  • The storage_fs row in cvm-boundaries.md described 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.

@h4x3rotab
h4x3rotab force-pushed the ext4-encryption-auth-limitation branch from d09e8d3 to 6cf8c25 Compare August 28, 2026 00:18
@h4x3rotab h4x3rotab changed the title docs: note that ext4 storage has no tamper detection docs: state what the encrypted data disk does not protect Aug 28, 2026
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
h4x3rotab force-pushed the ext4-encryption-auth-limitation branch from 6cf8c25 to 5b62954 Compare August 28, 2026 00:20
@h4x3rotab h4x3rotab changed the title docs: state what the encrypted data disk does not protect docs: say which filesystem detects a modified block Aug 28, 2026
@h4x3rotab
h4x3rotab enabled auto-merge (squash) August 28, 2026 00:27
@h4x3rotab
h4x3rotab merged commit 8c6064b into next Aug 28, 2026
17 checks passed
@h4x3rotab
h4x3rotab deleted the ext4-encryption-auth-limitation branch August 28, 2026 00:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant