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] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1906141156180.1722@nanos.tec.linutronix.de>
Date:   Fri, 14 Jun 2019 12:25:27 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Tim Chen <tim.c.chen@...ux.intel.com>
cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Jonathan Corbet <corbet@....net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Ben Greear <greearb@...delatech.com>, stable@...r.kernel.org,
        Andi Kleen <ak@...ux.intel.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Jun Nakajima <jun.nakajima@...el.com>,
        Jiri Kosina <jikos@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Asit Mallick <asit.k.mallick@...el.com>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        Jon Masters <jcm@...hat.com>,
        Waiman Long <longman9394@...il.com>,
        Borislav Petkov <bp@...en8.de>,
        Mark Gross <mgross@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>, x86@...nel.org
Subject: Re: [PATCH v2] Documentation: Add section about CPU vulnerabilities
 for Spectre

Tim,

On Thu, 6 Jun 2019, Tim Chen wrote:

> Here's a revised version of the spectre documentation.

thanks for the follow up!

> +++ b/Documentation/admin-guide/hw-vuln/spectre.rst
> @@ -0,0 +1,619 @@

Please add a SPDX license identifier

> +Spectre side channels
> +=====================
> +
> +Spectre is a class of side channel attacks that exploit branch prediction
> +and speculative execution on modern CPUs to read memory, possibly
> +bypassing access controls. Speculative execution side channel exploits
> +do not modify memory but attempt to infer privileged data in the memory.
> +
> +This document covers Spectre variant 1 and Spectre variant 2.
> +
> +Affected processors
> +-------------------
> +
> +Speculative execution side channel methods affect a wide range of modern
> +high performance processors, since most modern high speed processors
> +use branch predictions and speculative executions.

  branch prediction and speculative execution

> +
> +The following CPUs are vulnerable:
> +
> +    - Intel Core, Atom, Pentium, and Xeon processors
> +    - AMD Phenom, EPYC, and Zen processors
> +    - IBM POWER and zSeries processors
> +    - Higher end ARM processors
> +    - Apple CPUs
> +    - Higher end MIPS CPUs
> +    - Likely most other high performance CPUs. Contact your CPU vendor for details.

Please use line breaks. They work nicely in lists.

> +
> +Whether a processor is affected or not can be read out from the Spectre
> +vulnerability files in sysfs. See :ref:`spectre_sys_info`.
> +
> +Related CVEs
> +------------
> +
> +The following CVE entries describe Spectre variants:
> +
> +   =============   =======================  =================
> +   CVE-2017-5753   Bounds check bypass      Spectre variant 1
> +   CVE-2017-5715   Branch target injection  Spectre variant 2
> +   =============   =======================  =================
> +
> +Problem
> +-------
> +
> +CPUs use speculative operations to improve performance. That may leave
> +traces of memory accesses or computations in the processor's caches,
> +buffers, and branch predictors. Malicious software may be able to
> +influence the speculative execution paths, and then use the side effects
> +of the speculative execution in the CPUs caches and buffers to infer
> +privileged data touched during the speculative execution.
> +
> +Spectre variant 1 attacks take advantage of speculative execution of
> +conditional branches, while Spectre variant 2 attacks use speculative
> +execution of indirect branches to leak privileged memory. See [1] [5]
> +[7] [10] [11].
> +
> +Spectre variant 1 (Bounds Check Bypass)
> +---------------------------------------
> +
> +The bounds check bypass attack [2] takes advantage of speculative
> +execution that bypass conditional branch instructions used for memory
> +access bounds check (e.g. checking if the index of an array results in
> +memory access within a valid range). This results in memory accesses to
> +invalid memory (say with out-of-bound index) that are done speculatively

s/say//

> +before validation checks resolve. Such speculative memory accesses can
> +leave side effects, creating side channels which leak information to
> +the attacker.
> +
> +There are some extensions of Spectre variant 1 attacks for reading
> +data over the network, see [12]. However such attacks are difficult,
> +low bandwidth, fragile, and are considered low risk.
> +
> +Spectre variant 2 (Branch Target Injection)
> +-------------------------------------------
> +
> +The branch target injection attack takes advantage of speculative
> +execution of indirect branches [3].  The indirect branch predictors
> +inside the processor used to guess the target of indirect branches can
> +be influenced by an attacker, causing gadget code to be speculatively
> +executed, thus exposing sensitive data touched by the victim. The side
> +effects left in the CPU's caches during speculative execution can be
> +measured to infer data values.
> +
> +.. _poison_btb:
> +
> +In Spectre variant 2 attacks, the attacker can steer speculative indirect
> +branches in the victim to gadget code by poisoning the branch target
> +buffer of a CPU used for predicting indirect branch addresses. Such
> +poisoning could be done by indirect branching into existing code, with the
> +address offset of the indirect branch under the attacker's control. Since
> +the branch prediction hardware does not fully disambiguate branch address
> +and uses the offset for prediction, this could cause privileged code's
> +indirect branch to jump to a gadget code with the same offset.
> +
> +The most useful gadgets take an attacker-controlled input parameter (such
> +as a register value) so that the memory read can be controlled. Gadgets
> +without input parameters might be possible, but the attacker would have
> +very little control over what memory can be read, reducing the risk of
> +the attack revealing useful data.
> +
> +One other variant 2 attack vector is for the attacker to poison the
> +return stack buffer (RSB) [13] to cause speculative RET execution to go
> +to an gadget.  An attacker's imbalanced CALL instructions might "poison"
> +entries in the return stack buffer which are later consumed by a victim's
> +RET instruction.  This attack can be mitigated by flushing the return
> +stack buffer on context switch, or VM exit.

This should mention that SMT sibling threads can be affected because L1 and
BTB can be shared resources.

> +Attack scenarios
> +----------------
> +
> +The following list of attack scenarios have been anticipated, but may
> +not cover all possible attack vectors.
> +
> +1. A user process attacking the kernel
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +   The attacker passes a parameter to the kernel via a register or via a
> +   known address in memory during a syscall. Such parameter may be used
> +   later by the kernel as an index to an array or to derive a pointer
> +   for Spectre variant 1 attack.  The index or pointer is invalid, but

... for a Spectre ...


> +2. A user process attacking another user process
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +   A malicious user process can try to attack another user process,
> +   either via a context switch on the same hardware thread, or from the
> +   sibling hyperthread sharing a physical processor core on simultaneous
> +   multi-threading (SMT) system.
> +
> +   Spectre variant 1 attacks generally require passing parameters between
> +   the processes, which needs a data passing relationship, such as remote
> +   procedure calls (RPC).  Those parameters are used in gadget code to
> +   derive invalid data pointers accessing privileged memory.

priviledged memory in the attacked process.

> +   Spectre variant 2 attacks can be launched by a rogue process by
> +   :ref:`poisoning <poison_btb>` the branch target buffer.  This can
> +   influence the indirect branch targets for a victim process that either
> +   runs later on the same hardware thread, or running concurrently on
> +   a sibling hardware thread running on the same physical core.

s/thread running on/thread sharing/

> +   On x86, a user process can protect itself against Spectre variant 2
> +   attacks by using prctl syscall to disable indirect branch speculation

s/using prctl syscall/using the prctl() syscall/

> +   for itself.  An administrator can also cordon off an unsafe process
> +   from polluting the branch target buffer by disabling the process's
> +   indirect branch speculation. This comes with a performance cost from
> +   disabling indirect branch speculation and clearing the branch target
> +   buffer.  On SMT CPU, for a process that has indirect branch speculation

s/On SMT CPU/When SMT is enabled

> +   disabled, Single Threaded Indirect Branch Predictors (STIBP) [4]
> +   is turned on to prevent the sibling thread from controlling branch

s/is/are/	Predictors are clearly plural

> +   target buffer.  In addition, Indirect Branch Prediction Barrier (IBPB)

In addition, the Indirect ..

> +   is issued to clear the branch target buffer when context switching
> +   to and from such process.
> +
> +   On x86, the return stack buffer is stuffed on context switch.
> +   This prevents the branch target buffer from being used for branch
> +   prediction when the return stack buffer underflow while switching to

underflows

> +   a deeper call stack. Any poisoned entries in the return stack buffer
> +   left by the previous process will also be cleared.
> +
> +   User programs should use address space randomization to make attacks
> +   more difficult (Set /proc/sys/kernel/randomize_va_space = 1 or 2).
> +
> +3. A virtualized guest attacking the host
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +   The attack mechanism is similar to how user processes attack the
> +   kernel.  The kernel is entered via hyper calls or other virtualization

Please use the 'hyper-call' notation consistently.

> +   exit paths.
> +
> +   For Spectre variant 1 attack, rogue guests can pass parameters (e.g. in

either: For a Spectre variant 1 attack,
or:     For Spectre variant 1 attacks,

> +   registers) via hyper-calls to derive invalid pointers to speculate
> +   into privileged memory after entering the kernel.  For places where
> +   such kernel code are identified, nospec accessor macros are used to

s/are/has been identified/

> +   stop speculative memory access.
> +
> +   For Spectre variant 2 attack, rogue guests can :ref:`poison

See above.

> +   <poison_btb>` the branch target buffer or return stack buffer, causing
> +   the kernel to jump to gadget code in the speculative execution paths.
> +
> +   To mitigate variant 2, the host kernel can use return trampoline

trampolines

> +   for indirect branches to bypass poisoned branch target buffer, and

to bypass the

> +   flushes return stack buffer on VM exit.  This prevents rogue guest

s/and flushes return/and flushing the return/

> +   from affecting indirect branching in host kernel.
> +
> +   To protect host processes from rogue guests, host processes can have
> +   indirect branch speculation disabled via prctl.  The branch target

prctl()

> +   buffer is cleared before context switching to such processes.
> +
> +4. A virtualized guest attacking other guest
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +   A rogue guest may attack another guest to get data accessible by the
> +   other guest.
> +
> +   Spectre variant 1 attack is possible if parameters can be passed
> +   between guests.  This may be done via mechanisms such as shared memory
> +   or message passing.  Such parameters could be used to derive data
> +   pointers to privileged data in guest.  The privileged data could be
> +   accessed by gadget code in the victim's speculation paths.
> +
> +   Spectre variant 2 attack can be launched from a rogue guest by
> +   :ref:`poisoning <poison_btb>` the branch target buffer or return stack
> +   buffer. Such poisoned entries could be used to influence speculation
> +   execution paths in the victim guest. Linux kernel mitigates such
> +   attacks by flushing the return stack buffer on VM exit and also clears
> +   the branch target buffer before switching to a new guest.

This needs to explain that this is not preventing SMT sibling attacks.

> +Turning on mitigation for Spectre variant 1 and Spectre variant 2
> +-----------------------------------------------------------------
> +
> +1. Kernel mitigation
> +^^^^^^^^^^^^^^^^^^^^
> +
> +   For Spectre variant 1, vulnerable kernel codes (as determined by code

For the Spectre ..

s/codes/code/

> +   audit or scanning tools) are annotated on a case by case basis to use
> +   nospec accessor macros for bounds clipping [2] to avoid any usable
> +   disclosure gadgets. However, it may not cover all attack vectors for
> +   Spectre variant 1.
> +
> +   For Spectre variant 2 mitigation, the compiler turns indirect calls or

> +   jumps in the kernel into an equivalent return trampolines (retpoline)

s/an//

> +   [3] [9] to go to the target addresses.  Speculative execution paths
> +   under retpolines are trapped in an infinite loop to prevent any
> +   speculative execution jumping to a gadget.
> +
> +   To turn on retpoline mitigation on a vulnerable CPU, the kernel
> +   needs to be compiled with a gcc compiler that supports the
> +   -mindirect-branch=thunk-extern -mindirect-branch-register options.
> +   If the kernel is compiled with a clangs compiler, the compiler needs

s/clangs/Clang/

> +2. User program mitigation
> +^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +   User programs can mitigate Spectre variant 1 using LFENCE or "bounds
> +   clipping". For more details see [2].
> +
> +   For Spectre variant 2 mitigation, individual user programs
> +   can be compiled with return trampolines for indirect branches.
> +   This protects them from consuming poisoned entries in Branch Target

in the Branch...

> +   Buffer left by malicious software.  Alternatively, the programs
> +   can disable their indirect branch speculation via prctl (See

prctl()

> +   :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`)
> +   On x86, this will turn on STIBP to guard against attacks from the
> +   sibling thread when the user program is running, and use IBPB to
> +   flush the branch target buffer when switching to/from the program.

> +3. VM mitigation
> +^^^^^^^^^^^^^^^^
> +
> +   Within the kernel, Spectre variant 1 attacks from rogue guests
> +   are mitigated on a case by case basis in VM exit paths. Vulnerable
> +   codes use nospec accessor macros for "bounds clipping", to avoid any

code uses

> +   usable disclosure gadgets.  However, this may not cover all variant
> +   1 attack vectors.
> +
> +   For Spectre variant 2 attacks from rogue guests to the kernel, the
> +   Linux kernel uses retpoline to prevent consumption of poisoned entries

uses retpoline or Enhanced IBRS

> +   in branch target buffer left by rogue guests.  It also flushes the
> +   return stack buffer on every VM exit to prevent return stack buffer

prevent a return ...

> +   underflow so poisoned branch target buffer could be used, or attacker
> +   guests leaving poisoned entries in the return stack buffer.
> +
> +   To mitigate guest-to-guest attacks, the branch target buffer is
> +   sanitized by flushing before switching to a new guest on a CPU.
> +
> +   These mitigations are turned on by default on vulnerable CPUs.
> +
> +   The kernel also allows guests to use any microcode based mitigation
> +   they chose to use (such as IBPB or STIBP on x86).
> +
> +.. _mitigation_control_command_line:

...

Aside of the few nitpicks this is a very well done document!

Thanks,

	tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ