linux-kernel - Re: [patch V3 34/66] x86/fpu: Get rid of the FNSAVE optimization

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]

Date:   Tue, 22 Jun 2021 12:36:58 +0200
From:   Borislav Petkov <bp@...e.de>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Fenghua Yu <fenghua.yu@...el.com>,
        Tony Luck <tony.luck@...el.com>,
        Yu-cheng Yu <yu-cheng.yu@...el.com>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Kan Liang <kan.liang@...ux.intel.com>
Subject: Re: [patch V3 34/66] x86/fpu: Get rid of the FNSAVE optimization

On Fri, Jun 18, 2021 at 04:18:57PM +0200, Thomas Gleixner wrote:
> The FNSAVE support requires conditionals in quite some call paths because
> FNSAVE reinitialized the FPU hardware. If the save has to preserve the FPU

reinitializes

> register state then the caller has to conditionally restore it from memory
> when FNSAVE is in use.
> 
> This also requires a conditional in context switch because the restore
> avoidance optimization cannot work with FNSAVE. As this only affects 20+
> years old CPUs there is really no reason to keep this optimization
> effective for FNSAVE. It's about time to not optimize for antiques anymore.
> 
> Just unconditionally FRSTOR the save content to the registers and clean up
> the conditionals all over the place.
> 
> Suggested-by: Dave Hansen <dave.hansen@...ux.intel.com>
> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> ---
> V3: New patch
> ---
>  arch/x86/include/asm/fpu/internal.h |   17 +++++++----
>  arch/x86/kernel/fpu/core.c          |   54 +++++++++++++++---------------------
>  2 files changed, 34 insertions(+), 37 deletions(-)
> 
> --- a/arch/x86/include/asm/fpu/internal.h
> +++ b/arch/x86/include/asm/fpu/internal.h
> @@ -375,7 +375,7 @@ static inline int os_xrstor_safe(struct
>  	return err;
>  }
>  
> -extern int save_fpregs_to_fpstate(struct fpu *fpu);
> +extern void save_fpregs_to_fpstate(struct fpu *fpu);

You can move that stray forward declaration up, to the others.

...

> --- a/arch/x86/kernel/fpu/core.c
> +++ b/arch/x86/kernel/fpu/core.c
> @@ -83,16 +83,20 @@ bool irq_fpu_usable(void)
>  EXPORT_SYMBOL(irq_fpu_usable);
>  
>  /*
> - * These must be called with preempt disabled. Returns
> - * 'true' if the FPU state is still intact and we can
> - * keep registers active.
> + * Save the FPU register state in fpu->state. The register state is
> + * preserved.
>   *
> - * The legacy FNSAVE instruction cleared all FPU state
> - * unconditionally, so registers are essentially destroyed.
> - * Modern FPU state can be kept in registers, if there are
> - * no pending FP exceptions.
> + * Must be called with fpregs_lock() held.
> + *
> + * The legacy FNSAVE instruction clears all FPU state unconditionally, so
> + * register state has to be reloaded. That might be a pointless exercise
> + * when the FPU is going to be used by another task right after that. But
> + * this only affect 20+ years old 32bit systems and avoids conditionals all

affects

> + * over the place.
> + *
> + * FXSAVE and all XSAVE variants preserve the FPU register state.
>   */
> -int save_fpregs_to_fpstate(struct fpu *fpu)
> +void save_fpregs_to_fpstate(struct fpu *fpu)

With that addressed:

Reviewed-by: Borislav Petkov <bp@...e.de>

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg