On Wed, Oct 20, 2021 at 11:10:23AM -0500, Michael Roth wrote: > 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. 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? > 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@xxxxxxxxxx which is exactly what you say - a non-malicious HV taking care of its migration pool. So how do you handle that? > 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
