You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Security: Disk encryption disableable via kernel cmdline, not measured in RTMR #618
Note: This issue documents a vulnerability that was originally reported privately as the repository security advisory GHSA-jwpv-vw5q-rj47 by @pbeza.
Root Cause
The kernel command line parameter dstack.storage_encrypted=false (controlled by the host operator) disables LUKS2 disk encryption for CVM persistent storage. The storage_encrypted state is NOT emitted as a runtime event and is NOT extended into RTMR3. Remote attestation verifiers cannot detect whether encryption has been disabled.
Attack Path
Malicious host operator sets dstack.storage_encrypted=false in the VM kernel command line
CVM boots without disk encryption — persistent storage is in plaintext
Host operator can directly read CVM disk contents (keyshares, triples, presignatures, P2P keys)
Remote attestation verification passes because RTMR3 does not include storage_encrypted state
MPC verifier cannot distinguish between encrypted and unencrypted CVM deployments
Impact
Host operator can read all CVM persistent storage in plaintext without detection by remote attestation. For MPC nodes, this exposes keyshares, triples, presignatures, and P2P keys.
Suggested Fix
Emit storage_encrypted as a runtime event extended into RTMR3:
The MPC verifier should then check the RTMR3 event log for this event and reject CVMs where encryption is disabled.
Note: This finding was reported automatically as part of an AI/Claude-driven internal audit by the NEAR One MPC team. It has not been manually verified by a human to confirm whether it constitutes an actual security issue.
Maintainer response (copied from private security advisory GHSA-jwpv-vw5q-rj47):
Thank you for the report!
Here is our analysis:
1. The kernel command line IS measured — in RTMR2, not RTMR3
The advisory states that storage_encrypted is "NOT extended into RTMR3" and therefore not detectable by remote attestation. While it's true that there is no RTMR3 runtime event for storage_encrypted, the advisory overlooks that the entire kernel command line is measured into RTMR2 by the Linux EFI stub.
In TDX, PCR 9 maps to RTMR[2]. The Linux EFI stub measures the full kernel cmdline (as UTF-16LE) into PCR 9 before the kernel proper starts executing. The dstack-mr tool pre-computes the expected RTMR2 value from the known cmdline:
Adding dstack.storage_encrypted=false to the cmdline changes the cmdline string, which changes RTMR2, which changes mr_aggregated. A remote verifier comparing against expected measurements will detect this immediately.
2. Standard deployments don't include storage_encrypted in the cmdline at all
In the standard dstack image build (mkimage.sh), the kernel cmdline is:
There is no dstack.storage_encrypted parameter. The code in parse_dstack_options() defaults to storage_encrypted: true. The VMM constructs the QEMU command from metadata.json — there is no mechanism for an operator to inject extra cmdline args through the VMM API.
If a host operator bypasses the VMM and manually modifies the QEMU -append argument, the changed cmdline is measured into RTMR2, making it detectable.
Summary
Claim
Reality
storage_encrypted not measured in RTMR
Measured in RTMR2 as part of the kernel cmdline
Verifiers cannot detect disabled encryption
RTMR2 change is reflected for the changes
Host operator can disable encryption silently
Changing cmdline changes RTMR2; bypassing VMM also changes measurements
Activity
kvinwang commentedon Mar 27, 2026
Maintainer response (copied from private security advisory GHSA-jwpv-vw5q-rj47):
Thank you for the report!
Here is our analysis:
1. The kernel command line IS measured — in RTMR2, not RTMR3
The advisory states that
storage_encryptedis "NOT extended into RTMR3" and therefore not detectable by remote attestation. While it's true that there is no RTMR3 runtime event forstorage_encrypted, the advisory overlooks that the entire kernel command line is measured into RTMR2 by the Linux EFI stub.In TDX, PCR 9 maps to RTMR[2]. The Linux EFI stub measures the full kernel cmdline (as UTF-16LE) into PCR 9 before the kernel proper starts executing. The
dstack-mrtool pre-computes the expected RTMR2 value from the known cmdline:Adding
dstack.storage_encrypted=falseto the cmdline changes the cmdline string, which changes RTMR2, which changesmr_aggregated. A remote verifier comparing against expected measurements will detect this immediately.2. Standard deployments don't include
storage_encryptedin the cmdline at allIn the standard dstack image build (
mkimage.sh), the kernel cmdline is:There is no
dstack.storage_encryptedparameter. The code inparse_dstack_options()defaults tostorage_encrypted: true. The VMM constructs the QEMU command frommetadata.json— there is no mechanism for an operator to inject extra cmdline args through the VMM API.If a host operator bypasses the VMM and manually modifies the QEMU
-appendargument, the changed cmdline is measured into RTMR2, making it detectable.Summary
storage_encryptednot measured in RTMRfeat(dstack-util): measure whether the data disk was encrypted