linux-kernel - Re: [PATCH v8 0/6] Introduce CET supervisor state support

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: <0d9d3317-ad0f-4080-9b24-230b76006d91@intel.com>
Date: Tue, 3 Jun 2025 11:32:52 -0700
From: "Chang S. Bae" <chang.seok.bae@...el.com>
To: Chao Gao <chao.gao@...el.com>
CC: Dave Hansen <dave.hansen@...el.com>, Sean Christopherson
	<seanjc@...gle.com>, <x86@...nel.org>, <linux-kernel@...r.kernel.org>,
	<kvm@...r.kernel.org>, <tglx@...utronix.de>, <pbonzini@...hat.com>,
	<peterz@...radead.org>, <rick.p.edgecombe@...el.com>,
	<weijiang.yang@...el.com>, <john.allen@....com>, <bp@...en8.de>,
	<xin3.li@...el.com>, Dave Hansen <dave.hansen@...ux.intel.com>, Eric Biggers
	<ebiggers@...gle.com>, "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar
	<mingo@...hat.com>, Kees Cook <kees@...nel.org>, Maxim Levitsky
	<mlevitsk@...hat.com>, Mitchell Levy <levymitchell0@...il.com>, "Nikolay
 Borisov" <nik.borisov@...e.com>, Oleg Nesterov <oleg@...hat.com>, Sohil Mehta
	<sohil.mehta@...el.com>, Stanislav Spassov <stanspas@...zon.de>, "Vignesh
 Balasubramanian" <vigbalas@....com>
Subject: Re: [PATCH v8 0/6] Introduce CET supervisor state support

On 6/2/2025 11:22 PM, Chao Gao wrote:
> 
> Aside from the splat, task #2 could execute AMX instructions without
> requesting permissions, but its AMX state would be discarded during the
> next FPU switch, as RFBM[18] is cleared when executing XSAVES. And, in the

Right, AMX instructions can be executed when XFD is disarmed. But in 
this case, it's inside a signal handler. On sigreturn, XTILE_DATA will 
be reloaded with the init state, since fpstate::user_xfeatures[18] is zero.

> "flipped" scenario you mentioned, task #2 might receive an extra #NM, after
> which its fpstate would be re-allocated (although the size won't increase
> further).

Yes.

> So, for well-behaved tasks that never use AMX, there is no impact; tasks
> that use AMX may receive extra #NM. There won't be any unexpected #PF,
> memory corruption, or kernel panic.

A signal handler is expected to stay within the bounds of 
async-signal-safe functions, so using AMX in that context is highly 
unlikely in practice. While the issue has existed, its real-world impact 
appears quite minimal in my view.

Thanks,
Chang