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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ