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]

Message-ID: <7af72cd4720d67dc2a2a5457dcda675a46aba83e.camel@intel.com>
Date: Tue, 7 May 2024 15:33:28 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "seanjc@...gle.com" <seanjc@...gle.com>
CC: "Gao, Chao" <chao.gao@...el.com>, "Hansen, Dave" <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>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>, "mlevitsk@...hat.com"
	<mlevitsk@...hat.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "Yang,
 Weijiang" <weijiang.yang@...el.com>
Subject: Re: [PATCH v10 24/27] KVM: x86: Enable CET virtualization for VMX and
 advertise to userspace

On Tue, 2024-05-07 at 08:08 -0700, Sean Christopherson wrote:
> > It is just an indicator of if the IBT feature is usable.
> 
> Does ibt=off make IBT unusable for userspace?  Huh.  Looking at the #CP
> handler,
> I take it userspace support for IBT hasn't landed yet?

Sadly it remains an small internal dev branch that was preempted by the enormous
TDX ramp. It's my #1 thing I want to get back to when time reappears. Despite
being an old feature at this point, there is contingent of HW CFI fans that
still want to see it, including on the gcc/glibc and distro side. So I still
have hope.

> 
> > I think tying kernel IBT enforcement to the CPU feature is wrong. But if you
> > disable the HW feature, it makes sense that the enforcement would be
> > disabled.
> > 
> > CET is something that requires a fair amount of SW enablement. SW needs to
> > do
> > things in special ways or things will go wrong. So whether IBT is in use and
> > whether it is supported by the HW are useful to maintain as separate
> > concepts.
> > 
> > > 
> > > To fudge around that, we could add a synthetic feature flag to let the
> > > kernel tell KVM whether or not it's safe to virtualize IBT, but I don't
> > > see
> > > what value that adds over KVM checking raw host CPUID.
> > 
> > A synthetic feature flag for kernel IBT seems reasonable to me. It's what I
> > suggested on that thread I linked earlier. But Peterz was advocating for a
> > bool.
> > How enforcement would be exposed, would just be dmesg I guess. Having a new
> > feature flag still makes sense to me. Maybe he could be convinced.
> 
> If there's a need for IBT and KERNEL_IBT, I agree a synthetic flag makes
> sense.
> But as above, it's not clear to me why both are needed, at least for KVM's
> sake.
> Is the need more apparent when userspace IBT support comes along?

Isn't KVM CET kind of a second user though? It doesn't depends on CR4.CET like
the rest, but the same host FPU support. Let me try to ping peterz re the
synthetic flag.

For shadow stack we also have user_shstk. This was done because of the expected
introduction of the CET_SSS bit (the shadow stack fracturing busy thing bit). It
can be treated something like a supervisor shadow stack support bit. So for
guests, you might have user shadow stack support and not supervisor. At least
that was the idea.