Documentation/admin-guide/hw-vuln/srso.rst

Source file repositories/reference/linux-study-clean/Documentation/admin-guide/hw-vuln/srso.rst

File Facts

System
Linux kernel
Corpus path
Documentation/admin-guide/hw-vuln/srso.rst
Extension
.rst
Size
8629 bytes
Lines
243
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. SPDX-License-Identifier: GPL-2.0

Speculative Return Stack Overflow (SRSO)
========================================

This is a mitigation for the speculative return stack overflow (SRSO)
vulnerability found on AMD processors. The mechanism is by now the well
known scenario of poisoning CPU functional units - the Branch Target
Buffer (BTB) and Return Address Predictor (RAP) in this case - and then
tricking the elevated privilege domain (the kernel) into leaking
sensitive data.

AMD CPUs predict RET instructions using a Return Address Predictor (aka
Return Address Stack/Return Stack Buffer). In some cases, a non-architectural
CALL instruction (i.e., an instruction predicted to be a CALL but is
not actually a CALL) can create an entry in the RAP which may be used
to predict the target of a subsequent RET instruction.

The specific circumstances that lead to this varies by microarchitecture
but the concern is that an attacker can mis-train the CPU BTB to predict
non-architectural CALL instructions in kernel space and use this to
control the speculative target of a subsequent kernel RET, potentially
leading to information disclosure via a speculative side-channel.

The issue is tracked under CVE-2023-20569.

Affected processors
-------------------

AMD Zen, generations 1-4. That is, all families 0x17 and 0x19. Older
processors have not been investigated.

System information and options
------------------------------

First of all, it is required that the latest microcode be loaded for
mitigations to be effective.

The sysfs file showing SRSO mitigation status is:

  /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow

The possible values in this file are:

 * 'Not affected':

   The processor is not vulnerable

* 'Vulnerable':

   The processor is vulnerable and no mitigations have been applied.

 * 'Vulnerable: No microcode':

   The processor is vulnerable, no microcode extending IBPB
   functionality to address the vulnerability has been applied.

 * 'Vulnerable: Safe RET, no microcode':

   The "Safe RET" mitigation (see below) has been applied to protect the
   kernel, but the IBPB-extending microcode has not been applied.  User
   space tasks may still be vulnerable.

 * 'Vulnerable: Microcode, no safe RET':

   Extended IBPB functionality microcode patch has been applied. It does
   not address User->Kernel and Guest->Host transitions protection but it
   does address User->User and VM->VM attack vectors.

   Note that User->User mitigation is controlled by how the IBPB aspect in

Annotation

Implementation Notes