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: <12ccd0d3-e9a8-47b6-9564-7146d0a79f3a@intel.com>
Date: Wed, 22 May 2024 17:03:48 +0800
From: "Yang, Weijiang" <weijiang.yang@...el.com>
To: Dave Hansen <dave.hansen@...el.com>
CC: Sean Christopherson <seanjc@...gle.com>, Thomas Gleixner
	<tglx@...utronix.de>, <rick.p.edgecombe@...el.com>, <pbonzini@...hat.com>,
	<x86@...nel.org>, <kvm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<peterz@...radead.org>, <chao.gao@...el.com>, <mlevitsk@...hat.com>,
	<john.allen@....com>
Subject: Re: [PATCH v10 24/27] KVM: x86: Enable CET virtualization for VMX and
 advertise to userspace

On 5/21/2024 1:15 AM, Dave Hansen wrote:
> On 5/20/24 10:09, Sean Christopherson wrote:
>>> IIUC, this series tries to tie IBT to SHSTK feature, i.e., IBT cannot be
>>> exposed as an independent feature to guest without exposing SHSTK at the same
>>> time. If it is, then below patch is not needed anymore:
>>> https://lore.kernel.org/all/20240219074733.122080-3-weijiang.yang@intel.com/
>> That's a question for the x86 maintainers.  Specifically, do they want to allow
>> enabling XFEATURE_CET_USER even if userspace shadow stack support is disabled.
> I like the sound of "below patch is not needed anymore".
>
> Unless removing the patch causes permanent issues or results in
> something that's not functional, I say: jettison it with glee. If it's
> that important, it can be considered on its own merits separately.
I guess the existing dependency there is due to the fact that only user SHSTK is landed and there's
possibly no such kind of odd bare metal platform.

Side topic:  would it be reasonable to enforce IBT dependency on XFEATURE_CET_USER when *user* IBT
enabling patches are landing in kernel? Then guest kernel can play with user IBT alone if VMM
userspace just wants to enable IBT for guest. Or when SHSTK is disabled for whatever reason.