InvisiSpec: Making Speculative Execution Invisible in the Cache - - PowerPoint PPT Presentation

▶
invisispec making speculative execution invisible in the
SMART_READER_LITE
LIVE PREVIEW

InvisiSpec: Making Speculative Execution Invisible in the Cache - - PowerPoint PPT Presentation

Sep 01, 2023 333 likes •559 views

InvisiSpec: Making Speculative Execution Invisible in the Cache Hierarchy Mengjia Yan, Jiho Choi, Dimitrios Skarlatos, Adam Morrison, Christopher W. Fletcher, and Josep Torrellas University of Illinois at Urbana-Champaign Tel Aviv

slide-1
SLIDE 1

The Blavatnik School

  • f Computer Science

The Raymond and Beverly Sackler Faculty of Exact Sciences Tel Aviv University

InvisiSpec: Making Speculative Execution Invisible in the Cache Hierarchy

Mengjia Yan, Jiho Choi, Dimitrios Skarlatos, Adam Morrison∗, Christopher W. Fletcher, and Josep Torrellas University of Illinois at Urbana-Champaign ∗Tel Aviv University

slide-2
SLIDE 2

The Blavatnik School

  • f Computer Science

The Raymond and Beverly Sackler Faculty of Exact Sciences Tel Aviv University

Speculative Execution Attacks

  • Exploit the side effects of instructions on incorrectly-speculated paths (instructions

to be squashed)

  • Exploit a key feature of current ooo processors: speculative execution
  • Any meaningful defense needs hardware support
  • Defenses will be easier to implement in
  • Simple cores
  • Cores with “little legacy”

InvisiSpec: Making Speculative Execution Invisible in the Cache Hierarchy

2

slide-3
SLIDE 3

The Blavatnik School

  • f Computer Science

The Raymond and Beverly Sackler Faculty of Exact Sciences Tel Aviv University

1: if (x < array1_size) { 2: val = array1[x] 3: ld array2[val] 4: }

Existing Speculative Execution Attacks

  • Exploit the side-effects of transient instructions (speculatively-executed

instructions that are doomed to be squashed)

InvisiSpec: Making Speculative Execution Invisible in the Cache Hierarchy

3

Existing Attack Sources of Transient Instructions Spectre Control-flow misprediction Meltdown Virtual memory exception L1 Terminal Fault Speculative Store Bypass Address alias between a load and an earlier store Transient Instructions

slide-4
SLIDE 4

The Blavatnik School

  • f Computer Science

The Raymond and Beverly Sackler Faculty of Exact Sciences Tel Aviv University

Proposal: Comprehensive Speculative Attack Model

  • Any speculative load (i.e., load not at the head of ROB) is vulnerable
  • New speculative execution attacks may be found in the future

InvisiSpec: Making Speculative Execution Invisible in the Cache Hierarchy

4

Attack Model Sources of Transient Instructions Comprehensive Various events, such as:

  • Exceptions
  • Control-flow mispredictions
  • Address alias between a load and an earlier store
  • Address alias between two loads
  • Memory consistency model violations
  • Interrupts

Spectre Control-flow misprediction

slide-5
SLIDE 5

The Blavatnik School

  • f Computer Science

The Raymond and Beverly Sackler Faculty of Exact Sciences Tel Aviv University

Load reaches head of ROB

Lifetime of a load instruction

InvisiSpec: Making Speculative Execution Invisible in the Cache Hierarchy

5

Load is issued to memory

Load is speculative Spectre attack model Comprehensive attack model All prior branches are resolved

unsafe safe unsafe safe

The load becomes unsquashable Visibility Point

  • Exceptions
  • Control-flow

mispredictions

  • Address alias

load and store

  • Address alias

load and load

  • Memory

consistency model violations

  • Interrupts
slide-6
SLIDE 6

The Blavatnik School

  • f Computer Science

The Raymond and Beverly Sackler Faculty of Exact Sciences Tel Aviv University

How do we Defend against Speculative Attacks?

slide-7
SLIDE 7

The Blavatnik School

  • f Computer Science

The Raymond and Beverly Sackler Faculty of Exact Sciences Tel Aviv University

Trivial Approach

  • Delay issuing the load until its Visibility Point

InvisiSpec: Making Speculative Execution Invisible in the Cache Hierarchy

7

Visibility Point

Delay Issue the load Load could be issued to memory Load reaches head of ROB

Speculative loads are issued later than in a conventional processor To defend against the comprehensive attack model à the processor becomes an in-order processor

slide-8
SLIDE 8

The Blavatnik School

  • f Computer Science

The Raymond and Beverly Sackler Faculty of Exact Sciences Tel Aviv University

Better Approach

  • The load probes the local L1/L2
  • If hit, get the data and use it, but do not change the state (i.e., cache replacement bits)
  • Otherwise, delay until the Visibility Point

InvisiSpec: Making Speculative Execution Invisible in the Cache Hierarchy

8

Visibility Point

Probe L1/L2 and hit Load could be issued to memory Load reaches head of ROB

Visibility Point

Probe L1/L2 and miss: Delay Issue the load Load reaches head of ROB Change replacement bits

slide-9
SLIDE 9

The Blavatnik School

  • f Computer Science

The Raymond and Beverly Sackler Faculty of Exact Sciences Tel Aviv University

Advanced Approach

  • The load probes the local L1/L2
  • If hit, get the data and use it, but do not change the state
  • Otherwise
  • Use Value Prediction to return a value to the pipeline
  • At the Visibility Point: Issue the load and compare the return value to the predicted one
  • Squash if they are different

InvisiSpec: Making Speculative Execution Invisible in the Cache Hierarchy

9

Visibility Point

Probe L1/L2. If miss, predict value Load could be issued to memory Load reaches head of ROB Issue the load Compare

slide-10
SLIDE 10

The Blavatnik School

  • f Computer Science

The Raymond and Beverly Sackler Faculty of Exact Sciences Tel Aviv University

More Advanced Approach

  • Speculative Taint Tracking: Smart delay-based

InvisiSpec: Making Speculative Execution Invisible in the Cache Hierarchy

10

Visibility Point

Untainted: Issue without delay Load could be issued to memory Load reaches head of ROB

Visibility Point

Tainted: Delay until untainted Issue the load Load reaches head of ROB

slide-11
SLIDE 11

The Blavatnik School

  • f Computer Science

The Raymond and Beverly Sackler Faculty of Exact Sciences Tel Aviv University

Super Advanced Approach: InvisiSpec: Issue the Load Invisibly

slide-12
SLIDE 12

The Blavatnik School

  • f Computer Science

The Raymond and Beverly Sackler Faculty of Exact Sciences Tel Aviv University

InvisiSpec

  • Issue the load immediately, invisibly (i.e., no change to the cache hierarchy)
  • At the Visibility Point: HW re-issues the load and changes state of caches

InvisiSpec: Making Speculative Execution Invisible in the Cache Hierarchy

12

Visibility Point

Issue an invisible load request Use the value Make the load visible in cache Load is issued to memory Load reaches head of ROB

Speculative loads are issued as early as in a conventional machine and can pass data to dependent instructions immediately Add an “invisible transaction” that does not change the states of the caches

slide-13
SLIDE 13

The Blavatnik School

  • f Computer Science

The Raymond and Beverly Sackler Faculty of Exact Sciences Tel Aviv University

LLC

Making Unsafe Loads Invisible

  • Invisible load request
  • No modification to cache states, including
  • Cache occupancy
  • Replacement information
  • Coherence information
  • TLB state
  • Bring the data to Speculative Buffer (SB) (in

addition to the register)

InvisiSpec: Making Speculative Execution Invisible in the Cache Hierarchy

13

core L1 cache SB

Invisible load request Returned data

core L1 cache SB

slide-14
SLIDE 14

The Blavatnik School

  • f Computer Science

The Raymond and Beverly Sackler Faculty of Exact Sciences Tel Aviv University

Making Loads Visible at Visibility Point

  • Make the load visible: HW issues a normal request (which changes the caches)
  • While in the Window of Invisibility, processor does not receive invalidations

InvisiSpec: Making Speculative Execution Invisible in the Cache Hierarchy

14

Window of Invisibility Visibility Point

Issue an invisible load request Use the value Make the load visible in cache Load is issued to memory Load reaches head of ROB

Risk of memory consistency violations

slide-15
SLIDE 15

The Blavatnik School

  • f Computer Science

The Raymond and Beverly Sackler Faculty of Exact Sciences Tel Aviv University

An Example of Memory Consistency Violation

InvisiSpec: Making Speculative Execution Invisible in the Cache Hierarchy

15

P1 Ld lock Ld counter Wr counter release lock

P1 caches

Ld lock Ld counter

time P1 does not receive an invalidation! P1 sees the lock is free, but has read

  • ld counter.
slide-16
SLIDE 16

The Blavatnik School

  • f Computer Science

The Raymond and Beverly Sackler Faculty of Exact Sciences Tel Aviv University

How to Make Load Visible while Maintaining Consistency?

At Visibility Point: HW issues the request that changes state of caches (“Validation”) Data goes into L1. Compare the incoming data and the one in the SB If mismatch, squash the load as it violates memory consistency model

  • Problem: validations may cause stall at ROB head

InvisiSpec: Making Speculative Execution Invisible in the Cache Hierarchy

16

P1 caches

Ld lock Ld counter Wr counter release lock

time

Visibility point Ld lock Visibility point Ld counter squash and retry

slide-17
SLIDE 17

The Blavatnik School

  • f Computer Science

The Raymond and Beverly Sackler Faculty of Exact Sciences Tel Aviv University

How to Reduce the Cost of Validations?

  • For loads with no risk of consistency violation: Issue an Exposure, not a Validation
  • HW issues the request at the Visibility Point
  • Load does not need to wait for response to retire
  • Data goes into cache. No need to compare data
  • High performance: does not cause a stall

InvisiSpec: Making Speculative Execution Invisible in the Cache Hierarchy

17

P1 caches

Ld X Wr X

time

Visibility point Ld X

There are many cases where a load can use Exposures

slide-18
SLIDE 18

The Blavatnik School

  • f Computer Science

The Raymond and Beverly Sackler Faculty of Exact Sciences Tel Aviv University

Pros & Cons of InvisiSpec

  • Security
  • Successfully prevent attacks
  • Highest performance
  • Speculative loads are issued as early as in a

conventional machine

  • Applicability
  • Handle multi-threaded issues
  • No software changes
  • Add invisible coherence transaction
  • May stall due to Validations

InvisiSpec: Making Speculative Execution Invisible in the Cache Hierarchy

18

BUT:

  • Most validations are converted to Exposures
slide-19
SLIDE 19

The Blavatnik School

  • f Computer Science

The Raymond and Beverly Sackler Faculty of Exact Sciences Tel Aviv University

Discussion

  • There is a range of HW solutions with various tradeoffs
  • Ideas ready to be implemented in a simple processor
  • Keen to see the impact of a provably (more) secure processor

InvisiSpec: Making Speculative Execution Invisible in the Cache Hierarchy

19

slide-20
SLIDE 20

The Blavatnik School

  • f Computer Science

The Raymond and Beverly Sackler Faculty of Exact Sciences Tel Aviv University

Conclusion

  • InvisiSpec is the first comprehensive defense mechanism against speculative

execution attacks in the cache hierarchy

  • Paper appeared in MICRO 2018:

http://iacoma.cs.uiuc.edu/iacoma-papers/micro18.pdf

  • We published the code of our architecture simulator:

https://github.com/mjyan0720/InvisiSpec-1.0

InvisiSpec: Making Speculative Execution Invisible in the Cache Hierarchy

20

slide-21
SLIDE 21

The Blavatnik School

  • f Computer Science

The Raymond and Beverly Sackler Faculty of Exact Sciences Tel Aviv University

More in the paper

  • Security analysis
  • Details of when to use validations and exposures, and overlapping of them
  • Details of implementation
  • Detailed performance and area overhead evaluation results

InvisiSpec: Making Speculative Execution Invisible in the Cache Hierarchy

21

slide-22
SLIDE 22

The Blavatnik School

  • f Computer Science

The Raymond and Beverly Sackler Faculty of Exact Sciences Tel Aviv University

Speculative Execution Attacks

  • An example of Spectre Variant 1 (array bound checking attack).

InvisiSpec: Making Speculative Execution Invisible in the Cache Hierarchy

22

1: if (x < array1_size) { 2: val = array1[x] 3: ld array2[val] 4: } Victim code Attack to read arbitrary memory: 1) Train branch predictor 2) Trigger branch misprediction 3) Side channel Speculative execution attacks exploit side effects of instructions

  • n paths that will be squashed

Leaves side effects in cache