linux-kernel - Re: [PATCH v2] x86,acpi: Limit "Dummy wait" workaround to older AMD and Intel processors

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: <YzGWHMIsD7RBhEP+@hirez.programming.kicks-ass.net>
Date:   Mon, 26 Sep 2022 14:07:56 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     K Prateek Nayak <kprateek.nayak@....com>
Cc:     linux-kernel@...r.kernel.org, rafael@...nel.org, lenb@...nel.org,
        linux-acpi@...r.kernel.org, linux-pm@...r.kernel.org,
        dave.hansen@...ux.intel.com, bp@...en8.de, tglx@...utronix.de,
        andi@...as.de, puwen@...on.cn, mario.limonciello@....com,
        rui.zhang@...el.com, gpiccoli@...lia.com,
        daniel.lezcano@...aro.org, ananth.narayan@....com,
        gautham.shenoy@....com, Calvin Ong <calvin.ong@....com>,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        stable@...r.kernel.org
Subject: Re: [PATCH v2] x86,acpi: Limit "Dummy wait" workaround to older AMD
 and Intel processors

On Fri, Sep 23, 2022 at 09:08:01PM +0530, K Prateek Nayak wrote:
> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> index ef4775c6db01..fcd3617ed315 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -460,5 +460,6 @@
>  #define X86_BUG_MMIO_UNKNOWN		X86_BUG(26) /* CPU is too old and its MMIO Stale Data status is unknown */
>  #define X86_BUG_RETBLEED		X86_BUG(27) /* CPU is affected by RETBleed */
>  #define X86_BUG_EIBRS_PBRSB		X86_BUG(28) /* EIBRS is vulnerable to Post Barrier RSB Predictions */
> +#define X86_BUG_STPCLK			X86_BUG(29) /* STPCLK# signal does not get asserted in time during IOPORT based C-state entry */
>  
>  #endif /* _ASM_X86_CPUFEATURES_H */
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index 48276c0e479d..8cb5887a53a3 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -988,6 +988,18 @@ static void init_amd(struct cpuinfo_x86 *c)
>  	if (!cpu_has(c, X86_FEATURE_XENPV))
>  		set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
>  
> +	/*
> +	 * CPUs based on the Zen microarchitecture (Fam 17h onward) can
> +	 * guarantee that STPCLK# signal is asserted in time after the
> +	 * P_LVL2 read to freeze execution after an IOPORT based C-state
> +	 * entry. Among the older AMD processors, there has been at least
> +	 * one report of an AMD Athlon processor on a VIA chipset
> +	 * (circa 2006) having this issue. Mark all these older AMD
> +	 * processor families as being affected.
> +	 */
> +	if (c->x86 < 0x17)
> +		set_cpu_bug(c, X86_BUG_STPCLK);
> +
>  	/*
>  	 * Turn on the Instructions Retired free counter on machines not
>  	 * susceptible to erratum #1054 "Instructions Retired Performance
> diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
> index 2d7ea5480ec3..96fe1320c238 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -696,6 +696,18 @@ static void init_intel(struct cpuinfo_x86 *c)
>  		((c->x86_model == INTEL_FAM6_ATOM_GOLDMONT)))
>  		set_cpu_bug(c, X86_BUG_MONITOR);
>  
> +	/*
> +	 * Intel chipsets prior to Nehalem used the ACPI processor_idle
> +	 * driver for C-state management. Some of these processors that
> +	 * used IOPORT based C-states could not guarantee that STPCLK#
> +	 * signal gets asserted in time after P_LVL2 read to freeze
> +	 * execution properly. Since a clear cut-off point is not known
> +	 * as to when this bug was solved, mark all the chipsets as
> +	 * being affected. Only the ones that use IOPORT based C-state
> +	 * transitions via the acpi_idle driver will be impacted.
> +	 */
> +	set_cpu_bug(c, X86_BUG_STPCLK);
> +
>  #ifdef CONFIG_X86_64
>  	if (c->x86 == 15)
>  		c->x86_cache_alignment = c->x86_clflush_size * 2;

Quiz time:

  #define X86_VENDOR_INTEL       0
  #define X86_VENDOR_CYRIX       1
  #define X86_VENDOR_AMD         2
  #define X86_VENDOR_UMC         3
  #define X86_VENDOR_CENTAUR     5
  #define X86_VENDOR_TRANSMETA   7
  #define X86_VENDOR_NSC         8
  #define X86_VENDOR_HYGON       9
  #define X86_VENDOR_ZHAOXIN     10
  #define X86_VENDOR_VORTEX      11
  #define X86_VENDOR_NUM         12
  #define X86_VENDOR_UNKNOWN     0xff

For how many of the above have you changed behaviour?

Not to mention that this is the gazillion-th time AMD has failed to
change HYGON in lock-step. That's Zen too -- deal with it.