Security: VMM no_tee flag allows launching VMs without TDX protection #614

Note: This issue documents a vulnerability that was originally reported privately as the repository security advisory GHSA-25qw-5f44-vf8w by @pbeza.

Root Cause

The VMM supports a no_tee=true configuration flag that launches QEMU without the confidential-guest-support=tdx option. When this flag is set, the VM runs as a regular (non-confidential) VM — the host has full access to guest memory. The guest OS has no mechanism to detect that it's running without TDX hardware protection.

Attack Path

1. Malicious host operator sets no_tee=true in the VMM configuration
2. VM launches without TDX confidential computing protection
3. Host operator reads guest memory directly (no hardware isolation)
4. All keyshares, triples, presignatures, and P2P keys in memory are exposed
5. Guest OS and MPC node have no way to detect the absence of TDX
6. Note: TDX attestation would fail since no TDX hardware is present, but if the KMS has quote_enabled=false (F12003), keys are still provisioned

Impact

Complete loss of confidentiality. Without TDX, the host has unrestricted access to all guest memory. This defeats the entire purpose of running MPC nodes in TEEs.

Suggested Fix

1. Gate no_tee behind a compile-time feature flag that is never enabled in production builds
2. Inside the guest, verify TDX is active by checking X86_FEATURE_TDX_GUEST CPU feature at application startup
3. The MPC node should call CPUID to confirm TDX guest mode before processing any key material

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.