linux-kernel - Re: [PATCH] x86/fpu: Delay instruction pointer fixup until after 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aFMYsfwyALoi_X_x@aschofie-mobl2.lan>
Date: Wed, 18 Jun 2025 12:51:13 -0700
From: Alison Schofield <alison.schofield@...el.com>
To: Dave Hansen <dave.hansen@...ux.intel.com>
CC: <linux-kernel@...r.kernel.org>, <x86@...nel.org>, <tglx@...utronix.de>,
	<bp@...en8.de>, <mingo@...nel.org>, "Chang S. Bae"
	<chang.seok.bae@...el.com>, Eric Biggers <ebiggers@...gle.com>, Rik van Riel
	<riel@...hat.com>, <stable@...r.kernel.org>
Subject: Re: [PATCH] x86/fpu: Delay instruction pointer fixup until after
 after warning

On Wed, Jun 18, 2025 at 12:33:13PM -0700, Dave Hansen wrote:
> 
> From: Dave Hansen <dave.hansen@...ux.intel.com>

In the subject line: s/after after/after

> 
> 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
> e non-FPU-related instruction is #GP'ing.

s/e/the

> 
> Do not fix up RIP until after printing the warning.

How was this found and how is the change verified?
ie. do we have a mechanism for hitting this path easily?

With the grammar cleanups,
Acked-by: Alison Schofield <alison.schofield@...el.com>


> 
> Signed-off-by: Dave Hansen <dave.hansen@...ux.intel.com>
> Fixes: d5c8028b4788 ("x86/fpu: Reinitialize FPU registers if restoring FPU state fails")
> Cc: stable@...r.kernel.org
> Cc: Eric Biggers <ebiggers@...gle.com>
> Cc: Rik van Riel <riel@...hat.com>
> Cc: Borislav Petkov <bp@...en8.de>
> Cc: Chang S. Bae <chang.seok.bae@...el.com>
> ---
> 
>  b/arch/x86/mm/extable.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff -puN arch/x86/mm/extable.c~fixup-fpu-gp-ip-later arch/x86/mm/extable.c
> --- a/arch/x86/mm/extable.c~fixup-fpu-gp-ip-later	2025-06-18 12:21:30.231719499 -0700
> +++ b/arch/x86/mm/extable.c	2025-06-18 12:25:53.979954060 -0700
> @@ -122,11 +122,11 @@ static bool ex_handler_sgx(const struct
>  static bool ex_handler_fprestore(const struct exception_table_entry *fixup,
>  				 struct pt_regs *regs)
>  {
> -	regs->ip = ex_fixup_addr(fixup);
> -
>  	WARN_ONCE(1, "Bad FPU state detected at %pB, reinitializing FPU registers.",
>  		  (void *)instruction_pointer(regs));
>  
> +	regs->ip = ex_fixup_addr(fixup);
> +
>  	fpu_reset_from_exception_fixup();
>  	return true;
>  }
> _