Re: [PATCH v6 08/42] x86/sev-es: initialize sev_status/features within #VC handler

[Michael Roth]

On Thu, Oct 21, 2021 at 04:51:06PM +0200, Borislav Petkov wrote:
> On Wed, Oct 20, 2021 at 11:10:23AM -0500, Michael Roth wrote:
> > The CPUID calls in snp_cpuid_init() weren't added specifically to induce
> > the #VC-based SEV MSR read, they were added only because I thought the
> > gist of your earlier suggestions were to do more validation against the
> > CPUID table advertised by EFI
> 
> Well, if EFI is providing us with the CPUID table, who verified it? The
> attestation process? Is it signed with the AMD platform key?

For CPUID table pages, the only thing that's assured/attested to by firmware
is that:

 1) it is present at the expected guest physical address (that address
    is generally baked into the EFI firmware, which *is* attested to)
 2) its contents have been validated by the PSP against the current host
    CPUID capabilities as defined by the AMD PPR (Publication #55898),
    Section 2.1.5.3, "CPUID Policy Enforcement"
 3) it is encrypted with the guest key
 4) it is in a validated state at launch

The actual contents of the CPUID table are *not* attested to, so in theory
it can still be manipulated by a malicious hypervisor as part of the initial
SNP_LAUNCH_UPDATE firmware commands that provides the initial plain-text
encoding of the CPUID table that is provided to the PSP via
SNP_LAUNCH_UPDATE. It's also not signed in any way (apparently there were
some security reasons for that decision, though I don't know the full
details).

[A guest owner can still validate their CPUID values against known good
ones as part of their attestation flow, but that is not part of the
attestation report as reported by SNP firmware. (So long as there is some
care taken to ensure the source of the CPUID values visible to
userspace/guest attestion process are the same as what was used by the boot
stack: i.e. EFI/bootloader/kernel all use the CPUID page at that same
initial address, or in cases where a copy is used, that copy is placed in
encrypted/private/validated guest memory so it can't be tampered with during
boot.]

So, while it's more difficult to do, and the scope of influence is reduced,
there are still some games that can be played to mess with boot via
manipulation of the initial CPUID table values, so long as they are within
the constraints set by the CPUID enforcement policy defined in the PPR.

Unfortunately, the presence of the SEV/SEV-ES/SEV-SNP bits in 0x8000001F,
EAX, are not enforced by PSP. The only thing enforced there is that the
hypervisor cannot advertise bits that aren't supported by hardware. So
no matter how much the boot stack is trusted, the CPUID table does not
inherit that trust, and even values that we *know* should be true should be
verified rather than assumed.

But I think there are a couple approaches for verifying this is an SNP
guest that are robust against this sort of scenario. You've touched on
some of them in your other replies, so I'll respond there.

> 
> Because if we can verify the firmware is ok, then we can trust the CPUID
> page, right?
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpeople.kernel.org%2Ftglx%2Fnotes-about-netiquette&data=04%7C01%7CMichael.Roth%40amd.com%7C155dd6f54f3e4de017a908d994a236a5%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637704246794699901%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=U%2BS%2B%2F8%2BX8zLvPQGWvsOb7o6sKBz1MOZqU%2BVLKHiwugY%3D&reserved=0