linux.git/arch/x86/kernel/cpu/cpu.h, branch v6.9

x86/cpu: Use common topology code for HYGON

2024-02-15T21:07:38+00:00

Switch it over to use the consolidated topology evaluation and remove the
temporary safe guards which are not longer needed.

No functional change intended.

Signed-off-by: Thomas Gleixner 
Tested-by: Juergen Gross 
Tested-by: Sohil Mehta 
Tested-by: Michael Kelley 
Tested-by: Zhang Rui 
Tested-by: Wang Wendy 
Tested-by: K Prateek Nayak 
Link: https://lore.kernel.org/r/20240212153625.207750409@linutronix.de

x86/cpu: Provide an AMD/HYGON specific topology parser

2024-02-15T21:07:37+00:00

AMD/HYGON uses various methods for topology evaluation:

  - Leaf 0x80000008 and 0x8000001e based with an optional leaf 0xb,
    which is the preferred variant for modern CPUs.

    Leaf 0xb will be superseded by leaf 0x80000026 soon, which is just
    another variant of the Intel 0x1f leaf for whatever reasons.
    
  - Subleaf 0x80000008 and NODEID_MSR base

  - Legacy fallback

That code is following the principle of random bits and pieces all over the
place which results in multiple evaluations and impenetrable code flows in
the same way as the Intel parsing did.

Provide a sane implementation by clearly separating the three variants and
bringing them in the proper preference order in one place.

This provides the parsing for both AMD and HYGON because there is no point
in having a separate HYGON parser which only differs by 3 lines of
code. Any further divergence between AMD and HYGON can be handled in
different functions, while still sharing the existing parsers.

Signed-off-by: Thomas Gleixner 
Tested-by: Juergen Gross 
Tested-by: Sohil Mehta 
Tested-by: Michael Kelley 
Tested-by: Zhang Rui 
Tested-by: Wang Wendy 
Tested-by: K Prateek Nayak 
Link: https://lore.kernel.org/r/20240212153625.020038641@linutronix.de

x86/cpu: Use common topology code for Intel

2024-02-15T21:07:37+00:00

Intel CPUs use either topology leaf 0xb/0x1f evaluation or the legacy
SMP/HT evaluation based on CPUID leaf 0x1/0x4.

Move it over to the consolidated topology code and remove the random
topology hacks which are sprinkled into the Intel and the common code.

No functional change intended.

Signed-off-by: Thomas Gleixner 
Tested-by: Juergen Gross 
Tested-by: Sohil Mehta 
Tested-by: Michael Kelley 
Tested-by: Zhang Rui 
Tested-by: Wang Wendy 
Tested-by: K Prateek Nayak 
Link: https://lore.kernel.org/r/20240212153624.893644349@linutronix.de

x86/cpu: Provide cpu_init/parse_topology()

2024-02-15T21:07:36+00:00

Topology evaluation is a complete disaster and impenetrable mess. It's
scattered all over the place with some vendor implementations doing early
evaluation and some not. The most horrific part is the permanent
overwriting of smt_max_siblings and __max_die_per_package, instead of
establishing them once on the boot CPU and validating the result on the
APs.

The goals are:

  - One topology evaluation entry point

  - Proper sharing of pointlessly duplicated code

  - Proper structuring of the evaluation logic and preferences.

  - Evaluating important system wide information only once on the boot CPU

  - Making the 0xb/0x1f leaf parsing less convoluted and actually fixing
    the short comings of leaf 0x1f evaluation.

Start to consolidate the topology evaluation code by providing the entry
points for the early boot CPU evaluation and for the final parsing on the
boot CPU and the APs.

Move the trivial pieces into that new code:

   - The initialization of cpuinfo_x86::topo

   - The evaluation of CPUID leaf 1, which presets topo::initial_apicid

   - topo_apicid is set to topo::initial_apicid when invoked from early
     boot. When invoked for the final evaluation on the boot CPU it reads
     the actual APIC ID, which makes apic_get_initial_apicid() obsolete
     once everything is converted over.

Provide a temporary helper function topo_converted() which shields off the
not yet converted CPU vendors from invoking code which would break them.
This shielding covers all vendor CPUs which support SMP, but not the
historical pure UP ones as they only need the topology info init and
eventually the initial APIC initialization.

Provide two new members in cpuinfo_x86::topo to store the maximum number of
SMT siblings and the number of dies per package and add them to the debugfs
readout. These two members will be used to populate this information on the
boot CPU and to validate the APs against it.

Signed-off-by: Thomas Gleixner 
Tested-by: Juergen Gross 
Tested-by: Sohil Mehta 
Tested-by: Michael Kelley 
Tested-by: Peter Zijlstra (Intel) 
Tested-by: Zhang Rui 
Tested-by: Wang Wendy 
Tested-by: K Prateek Nayak 
Acked-by: Peter Zijlstra (Intel) 
Link: https://lore.kernel.org/r/20240212153624.581436579@linutronix.de

x86/cpu: Move cpu_l[l2]c_id into topology info

2023-10-10T12:38:18+00:00

The topology IDs which identify the LLC and L2 domains clearly belong to
the per CPU topology information.

Move them into cpuinfo_x86::cpuinfo_topo and get rid of the extra per CPU
data and the related exports.

This also paves the way to do proper topology evaluation during early boot
because it removes the only per CPU dependency for that.

No functional change.

Signed-off-by: Thomas Gleixner 
Tested-by: Juergen Gross 
Tested-by: Sohil Mehta 
Tested-by: Michael Kelley 
Tested-by: Peter Zijlstra (Intel) 
Tested-by: Zhang Rui 
Reviewed-by: Arjan van de Ven 
Acked-by: Peter Zijlstra (Intel) 
Link: https://lore.kernel.org/r/20230814085112.803864641@linutronix.de

x86/speculation: Add Gather Data Sampling mitigation

2023-07-19T23:45:37+00:00

Gather Data Sampling (GDS) is a hardware vulnerability which allows
unprivileged speculative access to data which was previously stored in
vector registers.

Intel processors that support AVX2 and AVX512 have gather instructions
that fetch non-contiguous data elements from memory. On vulnerable
hardware, when a gather instruction is transiently executed and
encounters a fault, stale data from architectural or internal vector
registers may get transiently stored to the destination vector
register allowing an attacker to infer the stale data using typical
side channel techniques like cache timing attacks.

This mitigation is different from many earlier ones for two reasons.
First, it is enabled by default and a bit must be set to *DISABLE* it.
This is the opposite of normal mitigation polarity. This means GDS can
be mitigated simply by updating microcode and leaving the new control
bit alone.

Second, GDS has a "lock" bit. This lock bit is there because the
mitigation affects the hardware security features KeyLocker and SGX.
It needs to be enabled and *STAY* enabled for these features to be
mitigated against GDS.

The mitigation is enabled in the microcode by default. Disable it by
setting gather_data_sampling=off or by disabling all mitigations with
mitigations=off. The mitigation status can be checked by reading:

    /sys/devices/system/cpu/vulnerabilities/gather_data_sampling

Signed-off-by: Daniel Sneddon 
Signed-off-by: Dave Hansen 
Acked-by: Josh Poimboeuf

x86/cpu: Switch to arch_cpu_finalize_init()

2023-06-16T08:15:59+00:00

check_bugs() is a dumping ground for finalizing the CPU bringup. Only parts of
it has to do with actual CPU bugs.

Split it apart into arch_cpu_finalize_init() and cpu_select_mitigations().

Fixup the bogus 32bit comments while at it.

No functional change.

Signed-off-by: Thomas Gleixner 
Reviewed-by: Borislav Petkov (AMD) 
Link: https://lore.kernel.org/r/20230613224545.019583869@linutronix.de

x86/CPU/AMD: Make sure EFER[AIBRSE] is set

2023-03-16T10:50:00+00:00

The AutoIBRS bit gets set only on the BSP as part of determining which
mitigation to enable on AMD. Setting on the APs relies on the
circumstance that the APs get booted through the trampoline and EFER
- the MSR which contains that bit - gets replicated on every AP from the
BSP.

However, this can change in the future and considering the security
implications of this bit not being set on every CPU, make sure it is set
by verifying EFER later in the boot process and on every AP.

Reported-by: Josh Poimboeuf 
Signed-off-by: Borislav Petkov (AMD) 
Acked-by: Dave Hansen 
Link: https://lore.kernel.org/r/20230224185257.o3mcmloei5zqu7wa@treble

x86/cpu: Remove redundant extern x86_read_arch_cap_msr()

2023-01-10T11:40:24+00:00

The prototype for the x86_read_arch_cap_msr() function has moved to
arch/x86/include/asm/cpu.h - kill the redundant definition in arch/x86/kernel/cpu.h
and include the header.

Signed-off-by: Ashok Raj 
Signed-off-by: Ingo Molnar 
Reviewed-by: Daniel Sneddon 
Link: https://lore.kernel.org/r/20221128172451.792595-1-ashok.raj@intel.com

x86/cpu/amd: Add Spectral Chicken

2022-06-27T08:34:00+00:00

Zen2 uarchs have an undocumented, unnamed, MSR that contains a chicken
bit for some speculation behaviour. It needs setting.

Note: very belatedly AMD released naming; it's now officially called
      MSR_AMD64_DE_CFG2 and MSR_AMD64_DE_CFG2_SUPPRESS_NOBR_PRED_BIT
      but shall remain the SPECTRAL CHICKEN.

Suggested-by: Andrew Cooper 
Signed-off-by: Peter Zijlstra (Intel) 
Signed-off-by: Borislav Petkov 
Reviewed-by: Josh Poimboeuf 
Signed-off-by: Borislav Petkov