Linux x86/sev - Secure TSC frequency calculation (TSC_FACTOR): Secure TSC is how an SEV-SNP guest gets a timebase

Impact

Secure TSC is how an SEV-SNP guest gets a timebase it can trust rather than one the host can manipulate. The guest's frequency calculation ignored TSC_FACTOR and so drifted from the real mean TSC frequency. A confidential guest whose clock is wrong makes wrong decisions about timeouts, certificate validity and rate limiting - and clock manipulation is a known lever for defeating the very side-channel defences that confidential computing depends on.

Who can reach it

Affects SEV-SNP guests using Secure TSC. Not an active attack so much as a broken trusted-time guarantee that a host-side adversary can lean on.

What to do

Fixed in the **guest** kernel, not the host - the hardening lives in the SEV-ES/SNP guest's #VC handler and interrupt entry code. That inverts the usual rollout: you can patch every hypervisor you own and still be exposed, because the protection has to be in the tenant's own VM image. As an operator your job is to ship updated confidential-guest images (or tell tenants which minimum kernel to run) and, where you can, enforce it as an admission requirement. Each guest picks the fix up on its next boot; no host reboot, no firmware update. The fix is in the guest's x86/sev code, so confidential-VM images need updating; host patching alone does not deliver it.

References