On Thu, Oct 21, 2021 at 03:41:49PM -0500, Michael Roth wrote:
> 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,
Why?
> 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).
So this sounds like an unnecessary complication. I'm sure there are
reasons to do it this way but my simple thinking would simply want the
CPUID page to be read-only and signed so that the guest can trust it
unconditionally.
> [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.]
This sounds like the good practices advice to guest owners would be,
"Hey, I just booted your SNP guest but for full trust, you should go and
verify the CPUID page's contents."
"And if I were you, I wouldn't want to run any verification of CPUID
pages' contents on the same guest because it itself hasn't been verified
yet."
It all sounds weird.
> 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.
Yah, I guess the kernel can do good enough verification and then the
full thing needs to be done by the guest owner and in *some* userspace
- not necessarily on the currently booted, unverified guest - but
somewhere, where you have maximal flexibility.
IMHO.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
