On Tue, Jul 02, 2024 at 11:07:18AM +0800, Xiaoyao Li wrote:
On 5/30/2024 7:16 PM, Pankaj Gupta wrote:
From: Michael Roth <michael.roth@amd.com>
SEV-SNP firmware allows a special guest page to be populated with a
table of guest CPUID values so that they can be validated through
firmware before being loaded into encrypted guest memory where they can
be used in place of hypervisor-provided values[1].
As part of SEV-SNP guest initialization, use this interface to validate
the CPUID entries reported by KVM_GET_CPUID2 prior to initial guest
start and populate the CPUID page reserved by OVMF with the resulting
encrypted data.
How is KVM CPUIDs (leaf 0x40000001) validated?
I suppose not all KVM_FEATURE_XXX are supported for SNP guest. And SNP
firmware doesn't validate such CPUID range. So how does them get validated?
This rules for CPUID enforcement are documented in the PPR for each AMD
CPU model in Chapter 2, section "CPUID Policy Enforcement". For the
situation you mentioned, it's stated there that:
The PSP enforces the following policy:
- If the CPUID function is not in the standard range (Fn00000000 through
Fn0000FFFF) or the extended range
(Fn8000_0000 through Fn8000_FFFF), the function output check is
UnChecked.
- If the CPUID function is in the standard or extended range and the
function is not listed in SEV-SNP CPUID
Policy table, then the output check is Strict and required to be 0. Note
that if the CPUID function does not depend
on ECX and/or XCR0, then the PSP policy ignores those inputs,
respectively.
- Otherwise, the check is defined according to the values listed in
SEV-SNP CPUID Policy table.
So there are specific ranges that are checked, mainly ones where there
is potential for guests to misbehave if they are being lied to. But
hypervisor-ranges are paravirtual in a sense so there's no assumptions
being made about what the underlying hardware is doing, so the checks
are needed as much in those cases.