From 5b62954459446da63926cd8db70acbfc009c477f Mon Sep 17 00:00:00 2001 From: Hang Yin Date: Fri, 28 Aug 2026 00:20:10 +0000 Subject: [PATCH] docs: say which filesystem detects a modified block 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 --- docs/security/cvm-boundaries.md | 2 +- docs/security/security-model.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/security/cvm-boundaries.md b/docs/security/cvm-boundaries.md index 867578d9f..5f58c0162 100644 --- a/docs/security/cvm-boundaries.md +++ b/docs/security/cvm-boundaries.md @@ -42,7 +42,7 @@ This is the main configuration file for the application in JSON format: | secure_time | 0.5.0 | boolean | Whether secure time is enabled | | pre_launch_script | 0.4.0 | string | Prelaunch bash script that runs before `docker compose up`. It runs *after* dockerd, so containers restored by a Docker restart policy can already be running when it executes. Do not build security gates on it — see [security-best-practices.md](./security-best-practices.md#security-semantics-must-not-depend-on-pre_launch_script-running-first). | | init_script | 0.5.5 (string), 0.6.0 (string[]) | string or string[] | Up to 5 Bash scripts executed in order prior to dockerd startup, so they always complete before any container starts, on every boot; a string is treated as a one-element array. Multiple scripts require string `manifest_version: "3"` so older guests fail closed. MrConfigV3 binds the hashes only for manifest v3. | -| storage_fs | 0.5.5 | string | Filesystem type for the data disk of the CVM. Supported values: "zfs", "ext4". default to "zfs". **ZFS:** Ensures filesystem integrity with built-in data protection features. **ext4:** Provides better performance for database applications with lower overhead and faster I/O operations, but no strong integrity protection. | +| storage_fs | 0.5.5 | string | Filesystem type for the data disk of the CVM. Supported values: "zfs", "ext4". default to "zfs". **ZFS:** Checksums every block, so a modified block fails the read. **ext4:** Lower overhead and faster I/O for database workloads; checksums metadata but not file data, so a modified block is not detected. | | swap_size | 0.5.5 | string/integer | The linux swap size. default to 0. Can be in byte or human-readable format (e.g., "1G", "256M"). | | key_provider | 0.5.6 | string | Key provider type. Supported values: "none", "kms", "local", "tpm". GCP vTPM and AWS EC2 NitroTPM are part of their platform trust models. The Dstack platform can use VMM-managed swtpm for seal/unseal and restart persistence, but it offers no protection against the host and is intentionally not accepted by remote verifiers. | diff --git a/docs/security/security-model.md b/docs/security/security-model.md index 03e48be76..5a0491867 100644 --- a/docs/security/security-model.md +++ b/docs/security/security-model.md @@ -24,7 +24,7 @@ dstack protects the execution environment, not your application code. Bugs in yo Infrastructure operators can still deny service. They can shut down your workload, throttle resources, or block network access. If availability matters, plan for redundancy across providers. -**Persistent-storage freshness, integrity, and availability.** Disk encryption protects the confidentiality of data at rest. The default ZFS storage filesystem also provides integrity checking; switching the storage filesystem to ext4 may forgo strong integrity protection. Neither filesystem proves that an attached disk represents the latest application state. An infrastructure operator can withhold, delete, replace, or restore an earlier valid encrypted disk image. Applications that require rollback-resistant state must anchor a monotonic version or state commitment in an external trusted service, ledger, or equivalent freshness mechanism. +**Persistent-storage freshness, integrity, and availability.** Disk encryption protects the confidentiality of data at rest, not its integrity: the LUKS2 volume carries no authentication tag, so detecting a modified block is left to the filesystem. The default ZFS checksums every block and fails the read; with `storage_fs` set to ext4, file data is not checksummed and a modified block reaches the application. Neither filesystem proves that an attached disk represents the latest application state. An infrastructure operator can withhold, delete, replace, or restore an earlier valid encrypted disk image. Applications that require rollback-resistant state must anchor a monotonic version or state commitment in an external trusted service, ledger, or equivalent freshness mechanism. ## Security Guarantees