linux-kernel - Re: [PATCH v8 04/26] x86/fpu/xstate: Introduce XFEATURE_MASK_KERNEL

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: <41602aa2e8f6e8813f58eca42bf9ece53d236978.camel@intel.com>
Date: Thu, 4 Jan 2024 22:26:12 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "Hansen, Dave" <dave.hansen@...el.com>, "Yang, Weijiang"
	<weijiang.yang@...el.com>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
	"seanjc@...gle.com" <seanjc@...gle.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "mlevitsk@...hat.com" <mlevitsk@...hat.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>
CC: "peterz@...radead.org" <peterz@...radead.org>, "Gao, Chao"
	<chao.gao@...el.com>, "john.allen@....com" <john.allen@....com>
Subject: Re: [PATCH v8 04/26] x86/fpu/xstate: Introduce
 XFEATURE_MASK_KERNEL_DYNAMIC xfeature set

On Wed, 2024-01-03 at 00:25 +0200, Maxim Levitsky wrote:
> I still think that we should consider adding XFEATURE_MASK_CET_KERNEL
> to
> XFEATURE_MASK_INDEPENDENT or at least have a good conversation on why
> this doesn't make sense,
> but I also don't intend to fight over this, as long as the code
> works.

Hi,

Using XFEATURE_MASK_INDEPENDENT would be pretty close to what we
initially discussed when this series resumed:
https://lore.kernel.org/lkml/20230803042732.88515-10-weijiang.yang@intel.com/

Except that it used manual MSR operations instead of xsaves. But the
gist is the same I think - the state is managed manually by KVM.

A XFEATURE_MASK_INDEPENDENT solution seems reasonable to me. I kind of
liked the that the MSR version didn't complicate the overly complex FPU
code. But there was an idea to give XFEATURE_MASK_KERNEL_DYNAMIC a try,
to see if it turned out easy. I think it turned out "ok" complexity
wise. So it doesn't make it clear win one way or the other for me.

I guess it might be slightly more efficient as in this patch because it
gets to use the lazy FPU stuff. It won't need to save/restore if the
exit is handled within KVM, or the kernel switches to a kernel thread
and back. I think that tilts it in favor of
XFEATURE_MASK_KERNEL_DYNAMIC.

Rick