* Borislav Petkov (bp@alien8.de) wrote:

On Wed, Oct 20, 2021 at 11:10:23AM -0500, Michael Roth wrote:

quoted

At which point we then switch to using the CPUID table? But at that
point all the previous CPUID checks, both SEV-related/non-SEV-related,
are now possibly not consistent with what's in the CPUID table. Do we
then revalidate?

Well, that's a tough question. That's basically the same question as,
does Linux support heterogeneous cores and can it handle hardware
features which get enabled after boot. The perfect example is, late
microcode loading which changes CPUID bits and adds new functionality.

And the answer to that is, well, hard. You need to decide this on a
case-by-case basis.

I can imagine a malicious hypervisor trying to return different cpuid
answers to different threads or even the same thread at different times.

But isn't it that the SNP CPUID page will be parsed early enough anyway
so that kernel proper will see only SNP CPUID info and init properly
using that?

quoted

Even a non-malicious hypervisor might provide inconsistent values
between the two sources due to bugs, or SNP validation suppressing
certain feature bits that hypervisor otherwise exposes, etc.

There's also migration, lemme point to a very recent example:

https://lore.kernel.org/r/20211021104744.24126-1-jane.malalane@citrix.com (local)

Ewww.

which is exactly what you say - a non-malicious HV taking care of its
migration pool. So how do you handle that?

Well, the spec (AMD 56860 SEV spec) says:

  'If firmware encounters a CPUID function that is in the standard or extended ranges, then the
firmware performs a check to ensure that the provided output would not lead to an insecure guest
state'

so I take that 'firmware' to be the PSP; that wording doesn't say that
it checks that the CPUID is identical, just that it 'would not lead to
an insecure guest' - so a hypervisor could hide any 'no longer affected
by' flag for all the CPUs in it's migration pool and the firmware
shouldn't complain; so it should be OK to pessimise.

Dave

quoted

Now all the code after sme_enable() can potentially take unexpected
execution paths, where post-sme_enable() code makes assumptions about
pre-sme_enable() checks that may no longer hold true.

So as I said above, if you parse SNP CPUID page early enough, you don't
have to worry about feature rediscovery. Early enough means, before
identify_boot_cpu().

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK