Re: [PATCH v4 20/31] i386/sev: Add support for SNP CPUID validation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/4/2024 8:34 AM, Michael Roth wrote:
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@xxxxxxx>

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.

I'm a little confused. Per your reference above, hypervisor-ranges is unchecked because it's not in the standard range nor the extended range.

And your last sentence said "so the checks are needed as much in those cases". So how does hypervisor-ranges get checked?

-Mike


[1] SEV SNP Firmware ABI Specification, Rev. 0.8, 8.13.2.6







[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux