linux-kernel - Re: [PATCH 1/5] x86/asm: Clarify static_cpu

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: <20190401080623.GC11158@hirez.programming.kicks-ass.net>
Date:   Mon, 1 Apr 2019 10:06:23 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Borislav Petkov <bp@...en8.de>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Nadav Amit <nadav.amit@...il.com>,
        Andy Lutomirski <luto@...capital.net>, x86@...nel.org
Subject: Re: [PATCH 1/5] x86/asm: Clarify static_cpu_has()'s intended use

On Sat, Mar 30, 2019 at 12:20:18PM +0100, Borislav Petkov wrote:
> From: Borislav Petkov <bp@...e.de>
> 
> Clarify when one should use static_cpu_has() and when one should use
> boot_cpu_has().
> 
> Requested-by: Nadav Amit <nadav.amit@...il.com>
> Signed-off-by: Borislav Petkov <bp@...e.de>
> Cc: x86@...nel.org
> ---
>  arch/x86/include/asm/cpufeature.h | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
> index 30cf12c81db3..1d337c51f7e6 100644
> --- a/arch/x86/include/asm/cpufeature.h
> +++ b/arch/x86/include/asm/cpufeature.h
> @@ -156,9 +156,12 @@ extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
>  #else
>  
>  /*
> - * Static testing of CPU features.  Used the same as boot_cpu_has().
> - * These will statically patch the target code for additional
> - * performance.
> + * Static testing of CPU features. Used the same as boot_cpu_has(). It
> + * statically patches the target code for additional performance. Use
> + * static_cpu_has() only in fast paths, where every cycle counts. Which
> + * means that the boot_cpu_has() variant is already fast enough for the
> + * majority of cases and you should stick to using it as it is generally
> + * only two instructions: a RIP-relative MOV and a TEST.
>   */
>  static __always_inline bool _static_cpu_has(u16 bit)
>  {

Should we introduce cpu_has() ?

I'm sure it boot_cpu_has() is an awesome name, but in like 99.9% of the
cases we don't give a crap about which actual CPU has the feature set. We
also don't actually support asymmetric cpu features anyway.