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

Michael Roth
2021-10-27T15:14:22Z

On Wed, Oct 27, 2021 at 01:17:11PM +0200, Borislav Petkov wrote:
> On Mon, Oct 25, 2021 at 11:35:18AM -0500, Michael Roth wrote:
> > As counter-intuitive as it sounds, it actually doesn't buy us if the CPUID
> > table is part of the PSP attestation report, since:
>
> Thanks for taking the time to explain in detail - I think I know now
> what's going on, and David explained some additional stuff to me
> yesterday.
>
> So, to cut to the chase:
>
> - yeah, ok, I guess guest owner attestation is what should happen.
>
> - as to the boot detection, I think you should do in sme_enable(), in
> pseudo:
>
> bool snp_guest_detected;
>
> if (CPUID page address) {
> read SEV_STATUS;
>
> snp_guest_detected = SEV_STATUS & MSR_AMD64_SEV_SNP_ENABLED;
> }
>
> /* old SME/SEV detection path */
> read 0x8000_001F_EAX and look at bits SME and SEV, yadda yadda.
>
> if (snp_guest_detected && (!SME || !SEV))
> /*
> * HV is lying to me, do something there, dunno what. I guess we can
> * continue booting unencrypted so that the guest owner knows that
> * detection has failed and maybe the HV didn't want us to force SNP.
> * This way, attestation will fail and the user will know why.
> * Or something like that.
> */
>
>
> /* normal feature detection continues. */
>
> How does that sound?

That seems promising. I've been testing a similar approach in conjunction with
moving sme_enable() to after the initial #VC handler is set up and things seem
to work out pretty nicely.

boot/compressed is a little less straightforward since the sme_enable()
equivalent is set_sev_encryption_mask() which sets sev_status and is written
in assembly, whereas the SNP-specific bits we're adding relies on C code
that handles stuff like scanning EFI config table are in C, so probably
worthwhile to see if everything can be redone in C. But then there's
get_sev_encryption_bit(), which needs to be in assembly since it needs
to be called from 32-bit entry path as well, but that doesn't actually
rely on anything set by set_sev_encryption_mask(), so it seems like it
should be okay to split set_sev_encryption_mask() out into a separate C
routine.

Will work on implementing/testing that approach, but if you or Joerg are
aware of any showstoppers there just let me know.

Thanks!

-Mike

>
> --
> Regards/Gruss,
> Boris.
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpeople.kernel.org%2Ftglx%2Fnotes-about-netiquette&amp;data=04%7C01%7Cmichael.roth%40amd.com%7C72940826a93b49882ffa08d9993b5390%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637709302358641670%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=%2BoUx7zP3RA57CwGG2q5IkUkrYQZiOL9ZoLxvIVTq%2BDY%3D&amp;reserved=0