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: <8a6c88c7457f9677449b0be3835c7844b34b4e8a.camel@intel.com>
Date: Mon, 6 May 2024 23:53:19 +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>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "peterz@...radead.org" <peterz@...radead.org>,
	"john.allen@....com" <john.allen@....com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "Yang, Weijiang" <weijiang.yang@...el.com>,
	"mlevitsk@...hat.com" <mlevitsk@...hat.com>, "kvm@...r.kernel.org"
	<kvm@...r.kernel.org>
Subject: Re: [PATCH v10 24/27] KVM: x86: Enable CET virtualization for VMX and
 advertise to userspace

On Mon, 2024-05-06 at 16:33 -0700, Sean Christopherson wrote:
> 
> 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.

I see a few reasons to tie to the host cpu feature:
1. Disabling it because of some HW concern. I agree with your assessment on the
chances.
2. Having the cpu feature be disabled by some kernel parameter, and having KVM
try to use it without the necessary FPU or other host support. It could cause
lots of problems, guest->host DOS, etc.
3. Confusion for the user about which CPU features are actually in use on the
system. There is a fair chance for compatibility issues to show up with CET.
Today there is clearcpuid. If a user was having issues with CET and just wanted
to turn it off, they might use clearcpuid or something else to just disable CET.
Then boot a VM and find it was still enabled. For shadow stack there is also
nousershstk.

So, my two cents, it's just all easier to reason about for everyone if you tie
it to host cpu features.

I don't immediately see what trouble will be in giving kernel IBT a disable
parameter that doesn't touch X86_FEATURE_IBT at some point in the future. Sorry
if I'm missing the point. So like, ibt=off disables all IBT including kernel
IBT, kernel_ibt=off disables kernel IBT enforcement via a global bool.