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: <994d42e4c4fb74899474a87766d7583507f13a73.camel@intel.com>
Date: Tue, 7 May 2024 14:45:52 +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 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. It is just an indicator of if the IBT
feature is usable. 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.