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

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

 



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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux