On Tue, Oct 31, 2023, Maxim Levitsky wrote: > On Thu, 2023-09-14 at 02:33 -0400, Yang Weijiang wrote: > > @@ -685,6 +686,13 @@ void kvm_set_cpu_caps(void) > > kvm_cpu_cap_set(X86_FEATURE_INTEL_STIBP); > > if (boot_cpu_has(X86_FEATURE_AMD_SSBD)) > > kvm_cpu_cap_set(X86_FEATURE_SPEC_CTRL_SSBD); > > + /* > > + * The feature bit in boot_cpu_data.x86_capability could have been > > + * cleared due to ibt=off cmdline option, then add it back if CPU > > + * supports IBT. > > + */ > > + if (cpuid_edx(7) & F(IBT)) > > + kvm_cpu_cap_set(X86_FEATURE_IBT); > > The usual policy is that when the host doesn't support a feature, then the guest > should not support it either. On the other hand, for this particular feature, > it is probably safe to use it. Just a point for a discussion. Agreed, this needs extra justification. It's "safe" in theory, but if the admin disabled IBT because of a ucode bug, then all bets are off. I'm guessing this was added because of the virtualization hole? I.e. if KVM allows CR4.CET=1 for shadow stacks, then KVM can't (easily?) prevent the guest from also using IBT.
