Speculation Barriers - Proposal of Work

Proposer

Name: Ved Shanbhogue

Organization/Affiliation: Rivos Inc.

Introduction

Modern CPU pipelines are massively parallelized, leveraging control flow speculation, data value speculation, and data dependency speculation to enhance efficiency and avoid stalls caused by unresolved instruction dependencies. However, this aggressive speculation introduces vulnerabilities to transient execution attacks like Spectre, which exploit speculative execution to leak sensitive data.

The proposed speculation barriers extension addresses these vulnerabilities by introducing speculation barriers, enabling developers to explicitly control speculation boundaries and ensure that speculative execution – arising from control flow, data value, or data dependency speculation – does not expose data through timing channels.

Definitions (Optional)

Side Channel - A channel is any medium in a computing system that may transmit or signal information. Legitimate channels are those intended by the system designers for transmission of information, and all other channels are incidental channels. An incidental channel is a covert channel if the adversary controls both its input and output. An incidental channel serves as a side channel if the adversary cannot exert control on its input and is only able to read its output.

Speculative execution - Processors that predict the outcomes of a branch or a load may use a value before the processor confirms that the speculative value is correct and thereby allow execution to proceed with the speculative value temporarily. If the speculation was confirmed to be correct then the instructions that depend on that value are valid and the instructions that used those values may retire. On the other hand if the speculative value was incorrect then such instructions must be flushed from the pipeline and executed again with the correct value. These flushed instructions are called transient instruction. Though the transient instructions do not commit their results to architectural state, they may affect the micro-architectural processor state (e.g., caches). This micro-architectural state constitutes an incidental channel and can be observed using techniques such as Flush+Reload or Prime+Probe that measure the timing of access to such micro-architectural state.

Transient Execution Attacks - are attacks that exploit the side effects of transient execution. Such attacks involve accessing the victims secrets and transmitting the secrets though a covert channel using a disclosure gadget. Such attacks can be further classified as domain-bypass attacks, cross-domain attacks, and in-domain attacks. Domain-bypass attacks bypass hardware access controls such as privilege separation or page tables. Examples of such include Rogue Data Cache Load (Meltdown). A cross-domain attack requires finding a disclosure gadget in the victims domain which can be transiently executed to access and transmit a secret over a covert channel. Examples of such include Branch Target Injection (Spectre variant 2). A in-domain attacks allows a adversary to access a secret within the same domain by circumventing software-based access controls. An example of this is Bounds Check Bypass (Spectre Variant 1).

Background

Processors can effectively mitigate against domain-bypass and cross-domain transient execution attacks using features such as isolating predictors between modes and address spaces. Such cross-domain attack mitigation’s may be achieved using relatively low overheads.

In-domain attacks involve bypassing software-based access controls and these access control boundaries are typically not visible to the processor hardware. The proposed speculation barriers extension addresses the cross-domain and in-domain vulnerabilities by introducing speculation barriers, enabling developers to explicitly control speculation boundaries and ensure that speculative execution – arising from control flow, data value, or data dependency speculation – does not expose data through timing channels. These instructions may be incorporated in the program by the compiler or may be placed in the program by the programmer. The mitigation’s using speculation barriers may incur higher overheads depending on the mitigation. For instance, the LVI mitigation's in LLVM for other architectures have shown a geomean impact of 9%. The speculation barriers provide a mechanism for system designers to address the threat of transient execution attacks such as for implementing high-assurance systems or critical infrastructure components.

Objectives

The deliverables of this group shall include:

• An ISA extension specification with speculation barriers to address speculation due to control-flow prediction, data-dependency prediction, and data-value prediction.

• A threat model and usage rationale. The instructions defined shall be evaluated to ensure they can be used for currently implemented compiler based mitigation’s and programmer introduced mitigation’s. The GCC compiler and the LLVM based compilers shall evaluated for compiler based mitigation’s and the Linux kernel for programmer introduced mitigation's.

• A set of litmus tests for these instructions.

• Spike emulator shall be extended to support these instructions. The Sail reference model shall be updated with these instructions. The architecture compatibility tests (ACT) and related collateral such as riscv-opcodes and riscof shall be updated to support these instructions.

Collaborations

The group shall collaborate with Privileged IC, Unprivileged IC, Applications and Tools HC, and the Architecture Review Committee.

For more details, refer to the list of active work groups and committees.

Non-objectives

The following are not not objectives for the speculation barriers:

1. Addressing domain-bypass transient execution attacks. Domain-bypasses may be considered as micro-architecture bugs as the domain boundaries protections such as those provided by PMP/SPMP, Page tables, and privilege modes are being violated. In the case of domain-bypass attacks the attacker uses transient execution to its benefit to perform the domain-bypass accesses transiently and without causing an architectural fault due to the cross-domain access. In such cases the attacker is not motivated to use the speculation barriers as the intent is to maximally exploit the speculative execution.

2. Eliminating side and/or covert channels. This extension provides instructions that may be used to control speculative execution boundaries and thereby avoid leaking the secrets through these incidental channels. This extension does not eliminate the incidental channels.

3. Address leaking of information through means other than speculative execution for cross-domain or in-domain transient execution attacks. Specifically, this extension does not address leakage of information through incidental channels such as power, thermal, etc. This extension does not address leakage of information through mechanisms that are not directly related to instruction execution - whether transient or not.

Sponsoring Organizations

These Premier and Strategic Members support this Proposal:

1. Rivos Inc.

2. Nvidia

3. SiFive

4. Ventana Microsystems.

5. Tenstorrent