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

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:

quoted

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&data=04%7C01%7Cmichael.roth%40amd.com%7C72940826a93b49882ffa08d9993b5390%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637709302358641670%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BoUx7zP3RA57CwGG2q5IkUkrYQZiOL9ZoLxvIVTq%2BDY%3D&reserved=0