linux-kernel - Re: [PATCH v10 24/27] KVM: x86: Enable CET virtualization for VMX and advertise to userspace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 6 May 2024 16:33:17 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Rick P Edgecombe <rick.p.edgecombe@...el.com>
Cc: Weijiang Yang <weijiang.yang@...el.com>, Chao Gao <chao.gao@...el.com>, 
	Dave Hansen <dave.hansen@...el.com>, "x86@...nel.org" <x86@...nel.org>, 
	"peterz@...radead.org" <peterz@...radead.org>, "john.allen@....com" <john.allen@....com>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "mlevitsk@...hat.com" <mlevitsk@...hat.com>, 
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pbonzini@...hat.com" <pbonzini@...hat.com>
Subject: Re: [PATCH v10 24/27] KVM: x86: Enable CET virtualization for VMX and
 advertise to userspace

On Mon, May 06, 2024, Rick P Edgecombe wrote:
> On Mon, 2024-05-06 at 17:19 +0800, Yang, Weijiang wrote:
> > On 5/2/2024 7:15 AM, Sean Christopherson wrote:
> > > On Sun, Feb 18, 2024, Yang Weijiang wrote:
> > > > @@ -696,6 +697,20 @@ 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);
> > > > +       /*
> > > > +        * Don't use boot_cpu_has() to check availability of IBT because
> > > > the
> > > > +        * feature bit is cleared in boot_cpu_data when ibt=off is applied
> > > > +        * in host cmdline.
> > > I'm not convinced this is a good reason to diverge from the host kernel. 
> > > E.g.  PCID and many other features honor the host setup, I don't see what
> > > makes IBT special.
> > 
> > This is mostly based on our user experience and the hypothesis for cloud
> > computing: When we evolve host kernels, we constantly encounter issues when
> > kernel IBT is on, so we have to disable kernel IBT by adding ibt=off. But
> > we need to test the CET features in VM, if we just simply refer to host
> > boot cpuid data, then IBT cannot be enabled in VM which makes CET features
> > incomplete in guest.
> > 
> > I guess in cloud computing, it could run into similar dilemma. In this
> > case, the tenant cannot benefit the feature just because of host SW
> > problem. I know currently KVM except LA57 always honors host feature
> > configurations, but in CET case, there could be divergence wrt honoring
> > host configuration as long as there's no quirk for the feature.
> > 
> > But I think the issue is still open for discussion...
> 
> I think the back and forth I remembered was actually around SGX IBT, but I did
> find this thread:
> https://lore.kernel.org/lkml/20231128085025.GA3818@noisy.programming.kicks-ass.net/
> 
> Disabling kernel IBT enforcement without disabling KVM IBT seems worthwhile. But
> the solution is to not to not honor host support. It is to have kernel IBT not
> clear the feature flag and instead clear something else. This can be done
> independently of the KVM series.

Hmm, I don't disagree, but I'm not sure it makes sense to wait on that discussion
to exempt IBT from the "it must be supported in the host" rule.  I suspect that
tweaking the handling X86_FEATURE_IBT of will open a much larger can of worms,
as overhauling feature flag handling is very much on the x86 maintainers todo
list.

IMO, the odds of there being a hardware bug that necessitates hard disabling IBT
are lower than the odds of KVM support for CET landing well before the feature
stuff is sorted out.