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

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

File Facts

System
Linux kernel
Corpus path
Documentation/admin-guide/hw-vuln/rsb.rst
Extension
.rst
Size
14737 bytes
Lines
269
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

=======================
RSB-related mitigations
=======================

.. warning::
   Please keep this document up-to-date, otherwise you will be
   volunteered to update it and convert it to a very long comment in
   bugs.c!

Since 2018 there have been many Spectre CVEs related to the Return Stack
Buffer (RSB) (sometimes referred to as the Return Address Stack (RAS) or
Return Address Predictor (RAP) on AMD).

Information about these CVEs and how to mitigate them is scattered
amongst a myriad of microarchitecture-specific documents.

This document attempts to consolidate all the relevant information in
once place and clarify the reasoning behind the current RSB-related
mitigations.  It's meant to be as concise as possible, focused only on
the current kernel mitigations: what are the RSB-related attack vectors
and how are they currently being mitigated?

It's *not* meant to describe how the RSB mechanism operates or how the
exploits work.  More details about those can be found in the references
below.

Rather, this is basically a glorified comment, but too long to actually
be one.  So when the next CVE comes along, a kernel developer can
quickly refer to this as a refresher to see what we're actually doing
and why.

At a high level, there are two classes of RSB attacks: RSB poisoning
(Intel and AMD) and RSB underflow (Intel only).  They must each be
considered individually for each attack vector (and microarchitecture
where applicable).

----

RSB poisoning (Intel and AMD)
=============================

SpectreRSB
~~~~~~~~~~

RSB poisoning is a technique used by SpectreRSB [#spectre-rsb]_ where
an attacker poisons an RSB entry to cause a victim's return instruction
to speculate to an attacker-controlled address.  This can happen when
there are unbalanced CALLs/RETs after a context switch or VMEXIT.

* All attack vectors can potentially be mitigated by flushing out any
  poisoned RSB entries using an RSB filling sequence
  [#intel-rsb-filling]_ [#amd-rsb-filling]_ when transitioning between
  untrusted and trusted domains.  But this has a performance impact and
  should be avoided whenever possible.

  .. DANGER::
     **FIXME**: Currently we're flushing 32 entries.  However, some CPU
     models have more than 32 entries.  The loop count needs to be
     increased for those.  More detailed information is needed about RSB
     sizes.

* On context switch, the user->user mitigation requires ensuring the
  RSB gets filled or cleared whenever IBPB gets written [#cond-ibpb]_
  during a context switch:

  * AMD:
	On Zen 4+, IBPB (or SBPB [#amd-sbpb]_ if used) clears the RSB.
	This is indicated by IBPB_RET in CPUID [#amd-ibpb-rsb]_.

Annotation

Implementation Notes