linux-stable.git/drivers/base/cpu.c, branch v6.4.9

x86/srso: Add a Speculative RAS Overflow mitigation

2023-08-08T18:04:51+00:00

Upstream commit: fb3bd914b3ec28f5fb697ac55c4846ac2d542855

Add a mitigation for the speculative return address stack overflow
vulnerability found on AMD processors.

The mitigation works by ensuring all RET instructions speculate to
a controlled location, similar to how speculation is controlled in the
retpoline sequence.  To accomplish this, the __x86_return_thunk forces
the CPU to mispredict every function return using a 'safe return'
sequence.

To ensure the safety of this mitigation, the kernel must ensure that the
safe return sequence is itself free from attacker interference.  In Zen3
and Zen4, this is accomplished by creating a BTB alias between the
untraining function srso_untrain_ret_alias() and the safe return
function srso_safe_ret_alias() which results in evicting a potentially
poisoned BTB entry and using that safe one for all function returns.

In older Zen1 and Zen2, this is accomplished using a reinterpretation
technique similar to Retbleed one: srso_untrain_ret() and
srso_safe_ret().

Signed-off-by: Borislav Petkov (AMD) 
Signed-off-by: Greg Kroah-Hartman

x86/speculation: Add Gather Data Sampling mitigation

2023-08-08T18:04:50+00:00

commit 8974eb588283b7d44a7c91fa09fcbaf380339f3a upstream

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 
Signed-off-by: Daniel Sneddon 
Signed-off-by: Greg Kroah-Hartman

tick/nohz: Fix cpu_is_hotpluggable() by checking with nohz subsystem

2023-04-05T13:47:43+00:00

For CONFIG_NO_HZ_FULL systems, the tick_do_timer_cpu cannot be offlined.
However, cpu_is_hotpluggable() still returns true for those CPUs. This causes
torture tests that do offlining to end up trying to offline this CPU causing
test failures. Such failure happens on all architectures.

Fix the repeated error messages thrown by this (even if the hotplug errors are
harmless) by asking the opinion of the nohz subsystem on whether the CPU can be
hotplugged.

[ Apply Frederic Weisbecker feedback on refactoring tick_nohz_cpu_down(). ]

For drivers/base/ portion:
Acked-by: Greg Kroah-Hartman 
Acked-by: Frederic Weisbecker 
Cc: Frederic Weisbecker 
Cc: "Paul E. McKenney" 
Cc: Zhouyi Zhou 
Cc: Will Deacon 
Cc: Marc Zyngier 
Cc: rcu 
Cc: stable@vger.kernel.org
Fixes: 2987557f52b9 ("driver-core/cpu: Expose hotpluggability to the rest of the kernel")
Signed-off-by: Paul E. McKenney 
Signed-off-by: Joel Fernandes (Google)

driver core: cpu: don't hand-override the uevent bus_type callback.

2023-02-11T10:50:41+00:00

Instead of having to change the uevent bus_type callback by hand at
runtime, set it at build time based on the build configuration options,
making this much simpler to maintain and understand (and allow to make
the structure constant.)

Cc: "Rafael J. Wysocki" 
Link: https://lore.kernel.org/r/20230210102408.1083177-1-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman

driver core: bus: add bus_get_dev_root() function

2023-02-10T09:16:42+00:00

Instead of poking around in the struct bus_type directly for the
dev_root pointer, provide a function to return it properly reference
counted, if it is present in the bus.  This will be needed to move the
pointer out of struct bus_type in the future.

Use the function in the driver core code at the same time it is
introduced to verify that it works properly.

Cc: "Rafael J. Wysocki" 
Link: https://lore.kernel.org/r/20230209093556.19132-1-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman

driver core: make struct bus_type.uevent() take a const *

2023-01-27T12:45:52+00:00

The uevent() callback in struct bus_type should not be modifying the
device that is passed into it, so mark it as a const * and propagate the
function signature changes out into all relevant subsystems that use
this callback.

Acked-by: Rafael J. Wysocki 
Acked-by: Hans de Goede 
Link: https://lore.kernel.org/r/20230111113018.459199-16-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman

x86/bugs: Report AMD retbleed vulnerability

2022-06-27T08:33:59+00:00

Report that AMD x86 CPUs are vulnerable to the RETBleed (Arbitrary
Speculative Code Execution with Return Instructions) attack.

  [peterz: add hygon]
  [kim: invert parity; fam15h]

Co-developed-by: Kim Phillips 
Signed-off-by: Kim Phillips 
Signed-off-by: Alexandre Chartre 
Signed-off-by: Peter Zijlstra (Intel) 
Signed-off-by: Borislav Petkov 
Reviewed-by: Josh Poimboeuf 
Signed-off-by: Borislav Petkov

x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data

2022-05-21T10:16:04+00:00

Add the sysfs reporting file for Processor MMIO Stale Data
vulnerability. It exposes the vulnerability and mitigation state similar
to the existing files for the other hardware vulnerabilities.

Signed-off-by: Pawan Gupta 
Signed-off-by: Borislav Petkov

sched/isolation: Use single feature type while referring to housekeeping cpumask

2022-02-16T14:57:55+00:00

Refer to housekeeping APIs using single feature types instead of flags.
This prevents from passing multiple isolation features at once to
housekeeping interfaces, which soon won't be possible anymore as each
isolation features will have their own cpumask.

Signed-off-by: Frederic Weisbecker 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Juri Lelli 
Reviewed-by: Phil Auld 
Link: https://lore.kernel.org/r/20220207155910.527133-5-frederic@kernel.org

driver: base: Prefer unsigned int to bare use of unsigned

2021-07-21T15:30:09+00:00

Fix checkpatch warnings:
    WARNING: Prefer 'unsigned int' to bare use of 'unsigned'

Signed-off-by: Jinchao Wang 
Link: https://lore.kernel.org/r/20210628171907.63646-2-wjc@cdjrlc.com
Signed-off-by: Greg Kroah-Hartman