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: <ZjpD2BaO5SXPUEj0@google.com>
Date: Tue, 7 May 2024 08:08:26 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Rick P Edgecombe <rick.p.edgecombe@...el.com>
Cc: 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>, "pbonzini@...hat.com" <pbonzini@...hat.com>, 
	"mlevitsk@...hat.com" <mlevitsk@...hat.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>, 
	Weijiang Yang <weijiang.yang@...el.com>
Subject: Re: [PATCH v10 24/27] KVM: x86: Enable CET virtualization for VMX and
 advertise to userspace

On Tue, May 07, 2024, Rick P Edgecombe wrote:
> On Tue, 2024-05-07 at 07:21 -0700, Sean Christopherson wrote:
> > 
> > Keeping X86_FEATURE_IBT set will result in "ibt" being reported in
> > /proc/cpuinfo,
> > i.e. will mislead userspace into thinking IBT is supported and fully enabled
> > by
> > the kernel.  For a security feature, that's a pretty big issue.
> 
> Since the beginning, if you don't configure kernel IBT in Kconfig but the HW
> supports it, "ibt" will appear in /proc/cpuinfo. It never was a reliable
> indicator of kernel IBT enforcement.

Ah, good to know.

> 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?

> 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?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ