On Fri, Jul 01, 2022, Borislav Petkov wrote: > On Thu, Jun 16, 2022 at 04:41:05PM +0000, Sean Christopherson wrote: > > > I worry that another use of cc_platform_has() could creep in at some point > > > and cause the same issue. Not sure how bad it would be, performance-wise, to > > > remove the jump table optimization for arch/x86/coco/core.c. > > Is there a gcc switch for that? I believe -fno-jump-tables will do the trick. That also reminds me exactly why CONFIG_RETPOLINE=y isn't broken, jump tables are disabled when retpolines are enabled[*]. [*] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952 > > One thought would be to initialize "vendor" to a bogus value, disallow calls to > > cc_set_vendor() until after the kernel as gotten to a safe point, and then WARN > > (or panic?) if cc_platform_has() is called before "vendor" is explicitly set. > > New calls can still get in, but they'll be much easier to detect and less likely > > to escape initial testing. > > The invalid vendor thing makes sense but I don't think it'll help in > this case. > > We set vendor in sme_enable() which comes before the > > __startup_64 -> sme_postprocess_startup > > path you're hitting. Right, but that's easily solved, no? E.g. diff --git a/arch/x86/mm/mem_encrypt_amd.c b/arch/x86/mm/mem_encrypt_amd.c index e8f7953fda83..ed3118f5bf62 100644 --- a/arch/x86/mm/mem_encrypt_amd.c +++ b/arch/x86/mm/mem_encrypt_amd.c @@ -487,6 +487,8 @@ void __init sme_early_init(void) if (!sme_me_mask) return; + cc_set_vendor(CC_VENDOR_AMD); + early_pmd_flags = __sme_set(early_pmd_flags); __supported_pte_mask = __sme_set(__supported_pte_mask); diff --git a/arch/x86/mm/mem_encrypt_identity.c b/arch/x86/mm/mem_encrypt_identity.c index f415498d3175..6b1c60032400 100644 --- a/arch/x86/mm/mem_encrypt_identity.c +++ b/arch/x86/mm/mem_encrypt_identity.c @@ -611,7 +611,6 @@ void __init sme_enable(struct boot_params *bp) out: if (sme_me_mask) { physical_mask &= ~sme_me_mask; - cc_set_vendor(CC_VENDOR_AMD); cc_set_mask(sme_me_mask); } } And disallow cc_set_vendor() before x86_64_start_kernel(), then fix any fallout. > We could do only the aspect of checking whether it hasn't been set yet > and warn then, in order to make the usage more robust... > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette
