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: <ZkY7PblLmWdFYeSa@google.com>
Date: Thu, 16 May 2024 09:58:37 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Weijiang Yang <weijiang.yang@...el.com>, 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 Thu, May 16, 2024, Dave Hansen wrote:
> On 5/16/24 07:39, Sean Christopherson wrote:
> >> We synced the issue internally, and got conclusion that KVM should honor host
> >> IBT config.  In this case IBT bit in boot_cpu_data should be honored.  With
> >> this policy, it can avoid CPUID confusion to guest side due to host ibt=off
> >> config.
> > What was the reasoning?  CPUID confusion is a weak justification, e.g. it's not
> > like the guest has visibility into the host kernel, and raw CPUID will still show
> > IBT support in the host.
> 
> I'm basically arguing for the path of least resistance (at least to start).
> 
> We should just do what takes the least amount of code for now that
> results in mostly sane behavior, then debate about making it perfect later.
> 
> In other words, let's say the place we'd *IDEALLY* end up is that guests
> can have any random FPU state which is disconnected from the host.  But
> the reality, for now, is that the host needs to have XFEATURE_CET_USER
> set in order to pass it into the guest and that means keeping
> X86_FEATURE_SHSTK set.
> 
> If you want guest XFEATURE_CET_USER, you must have host
> X86_FEATURE_SHSTK ... for now.

Ah, because fpu__init_system_xstate() will clear XFEATURE_CET_USER via the
X86_FEATURE_SHSTK connection in xsave_cpuid_features. 

Please put something to that effect in the changelog.  "this literally won't work
(without more changes)" is very different than us making a largely arbitrary
decision.