CVE-2023-31347

What it actually does

Due to improper input validation in Secure_TSC, SEV firmware allows a high-privileged attacker to cause a guest VM to observe an incorrect TSC value when Secure TSC is enabled, resulting in loss of guest integrity.

Why it matters to the business

Virtualized workloads relying on AMD SEV for memory encryption and integrity may experience subtle tampering that undermines trust in guest execution, increasing risk for cloud providers and enterprises running sensitive workloads in confidential VMs.

How an attack unfolds

An attacker with hypervisor or host-level privileges identifies a guest with Secure TSC enabled, then leverages the Secure_TSC code bug to supply crafted TSC data that the guest observes as valid but incorrect, allowing manipulation of time-dependent operations and potential integrity violations without triggering standard SEV protections.

How to fix it

Apply the latest SEV firmware updates from the platform vendor that address the Secure_TSC validation issue; until available, evaluate disabling Secure TSC where integrity requirements allow or isolate affected workloads.

How to confirm the fix worked

Confirm firmware versions on SEV-enabled hosts match vendor-supplied fixed releases; test guest TSC behavior under Secure TSC mode before and after update to verify correct counter observation.

Typical attack path

1. Obtain high-privileged access to the hypervisor or SEV-enabled host
2. Locate or create a target guest VM configured with Secure TSC
3. Trigger the Secure_TSC flaw to inject incorrect TSC observations into the guest
4. Exploit resulting timing discrepancies to undermine guest integrity checks or time-sensitive security mechanisms

How to detect it

Review hypervisor and SEV firmware logs for unexpected TSC-related events or guest integrity warnings; correlate with privileged access attempts on hosts running Secure TSC-enabled guests.

What your security team should do

• Inventory all AMD SEV-enabled hosts and identify workloads using Secure TSC
• Prioritize firmware updates on systems hosting high-value confidential VMs
• Monitor vendor security bulletins for SEV firmware releases addressing this issue
• Consider compensating controls such as additional guest-level time synchronization validation until patched