linux-kernel - Re: [PATCH] [v2] x86/fpu: Delay instruction pointer fixup until after warning

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] [day] [month] [year] [list]

Message-ID: <83f82177-8349-427e-b670-ef0a9ff94c9e@intel.com>
Date: Thu, 26 Jun 2025 21:04:09 +0900
From: "Chang S. Bae" <chang.seok.bae@...el.com>
To: Dave Hansen <dave.hansen@...ux.intel.com>, <linux-kernel@...r.kernel.org>
CC: <x86@...nel.org>, <tglx@...utronix.de>, <bp@...en8.de>,
	<mingo@...nel.org>, <chao.gao@...el.com>, Alison Schofield
	<alison.schofield@...el.com>, Eric Biggers <ebiggers@...gle.com>, "Rik van
 Riel" <riel@...hat.com>, <stable@...r.kernel.org>
Subject: Re: [PATCH] [v2] x86/fpu: Delay instruction pointer fixup until after
 warning

On 6/25/2025 6:01 AM, Dave Hansen wrote:
> 
> Right now, if XRSTOR fails a console message like this is be printed:
> 
> 	Bad FPU state detected at restore_fpregs_from_fpstate+0x9a/0x170, reinitializing FPU registers.
> 
> However, the text location (...+0x9a in this case) is the instruction
> *AFTER* the XRSTOR. The highlighted instruction in the "Code:" dump
> also points one instruction late.
> 
> The reason is that the "fixup" moves RIP up to pass the bad XRSTOR and
> keep on running after returning from the #GP handler. But it does this
> fixup before warning.
> 
> The resulting warning output is nonsensical because it looks like the
> non-FPU-related instruction is #GP'ing.
> 
> Do not fix up RIP until after printing the warning. Do this by using> the more generic and standard ex_handler_default().

Indeed, the fix looks obvious and correct.

Also, the trick you previously shared for reproducing the fault is very 
useful for testing cases like this.

I would be happy to provide my tag:
Reviewed-by: Chang S. Bae <chang.seok.bae@...el.com>

Thanks,
Chang