A Reo Semantics for Reasoning about Speculative Execution - - PowerPoint PPT Presentation

A Reo Semantics for Reasoning about Speculative Execution

Hans-Dieter A. Hiep

Vrije Universiteit Amsterdam Centrum Wiskunde & Informatica

November 13th, 2018

Overview

• 1. Motivation
• 2. Language
• 3. Foundation
• 4. Properties

Motivation

Recent security issues in processors are popularized as:

◮ Meltdown ◮ Spectre ◮ Foreshadow

Are caused by the combination of:

◮ Cache hierarchy ◮ Simultaneous multi-threading ◮ Speculative execution ◮ Irreversibility

Mitigation could reduce performance by 50% (as reported by “cloud” computing providers)

Motivation: speculative execution

Increase throughput by reducing critical path length int outcome = slowOperation(); if (outcome < 0) doThis(); else doThat(); while slowOperation is executing, we speculate.

Motivation: speculative execution

Increase throughput by reducing critical path length int outcome = slowOperation(); if (outcome < 0) doThis(); else doThat(); while slowOperation is executing, we speculate.

• 1. A true speculation correctly predicts outcome:

reduction in critical path length

• 2. A false speculation incorrectly predicts outcome:

all observable effects have to be reversed

Motivation: reversible computing

Imagine a physical device: interface cache { void put(int value); int get(); } Is this device reversible?

Motivation: reversible computing

Imagine a physical device: interface cache { void put(int value); int get(); } Is this device reversible? No! Overwriting: perform put twice

Motivation

To increase trustworthiness of components, we investigate a logical formalism, in which we can unambiguously state desired safety, privacy and security properties. Ambition: certification by verification.

Overview

• 1. Motivation
• 2. Language
• 3. Foundation
• 4. Properties

Language: Analogy

Language: Standard Components

• B
• B
• B
• B
• B
• B
• B
• B
• B
• B
• B

C

• B

C

• B

C

• B

C

Language: Input-only Components

• B
• B
• B
• B
• B
• B
• B
• B
• B
• B
• B

C

• B

C

• B

C

• B

C

Language: Output-only Components

• B
• B
• B
• B
• B
• B
• B
• B
• B
• B
• B

C

• B

C

• B

C

• B

C

Language: Interface

Definition

An interface U consists of:

• 1. input ports I1,...,In
• 2. ouput ports O1,...,Ok
• 3. each port has an associated data type
• O

2 O2 n O

• Given interface U, by U⊥ we denote its dual.

Language: Instances and References

• B

C

• B

C

Language: Instances and References

• B

C

• B

C x y z

Component instances x,y,z,...

Language: Instances and References

• B

C

• B

C x y z

Component instances x,y,z,... Qualified x.A and unqualified A.

Language: Composition

• B

C

• B

C x y z

Definition

A composition is either:

◮ an instance

Language: Composition

• B

C

• B

C x y z

Definition

A composition is either:

◮ an instance ◮ two compositions adjoined

Language: Composition

• B

C

• B

C x y z

Definition

A composition is either:

◮ an instance ◮ two compositions adjoined ◮ identification of two references of a composition

Language: Composition

• B

C

• B

C x y z B

• C

Definition

A composition is either:

◮ an instance ◮ two compositions adjoined ◮ identification of two references of a composition

Well-formed if no unqualified references

Language: Component

• B

C

• B

C x y z B

• C

Definition (to be continued)

A component is either:

◮ primitive

Language: Component

• B

C

• B

C x y z B

• C

Definition (to be continued)

A component is either:

◮ primitive ◮ composite

Language: Results

• 1. Formal graphical language for Reo
• 2. Implemented prototype in Java
• 3. Designed normalization procedure and type checker
• cf. A survey of graphical languages for monoidal categories,

P . Selinger, 2009

• cf. Sequent calculus: a logic and a language for computation and duality,

P . Downen, 2017

Overview

• 1. Motivation
• 2. Language
• 3. Foundation
• 4. Properties

Foundation: Data domains

Data types α, β, ...

◮ contain special ‘null’ value ∗

Examples

Signals: Signal = {∗,0} Naturals: Nat = {∗,0,1,2,...}

Foundation: Stream domains

Data streams (N → α), (N → β), ...

◮ functions from naturals to data types

Examples

σ : N → Signal is a data stream over signals head σ(0) is ∗ or 0 tail σ′ is stream derivative

• cf. On Streams and Coinduction, J.J.M.M. Rutten, 2002

Foundation: Multi-sorted logic

Sorts:

◮ each data type is a distinct sort ◮ each data stream is a distinct sort ◮ there is a sort for naturals, N

Non-logical symbols:

◮ ∗α null constant ◮ dα data constant ◮ ⊥ proposition ◮ = equality predicate ◮ 0,1,2,... and +,−,×,≤ for naturals ◮ atα with arity (N → α),N,α ◮ skipα with arity (N → α),N,(N → α)

Foundation: Multi-sorted logic

Terms: standard

◮ variables xs ◮ constants ◮ function symbols

Formulas: standard

◮ propositions ◮ predicates of terms ◮ standard logical symbols ¬, ∧, ∨, →, ↔ ◮ first-order quantification ∃xs, ∀xs binders for xs

Treat sorts implicitly. Write at(X,t) as X(t), called applications. Write skip(X,t) as X (t), called derivations.

Foundation: Coordination Protocols

Definition

A coordination protocol is a first-order formula such that all free variables X s are of a data stream sort s = (N → α)

Foundation: Components

Definition

A component φ(U) is a coordination protocol φ and interface U.

◮ Primitive components given as φ(U),

where free variables of φ are ports of U.

◮ Composite components by induction:

◮ Adjoined components φ(U) and ψ(V):

take φ ∧ψ

◮ Identification of references X and Y on φ(U):

take ∃X.∃Y.(φ ∧∀t.(X(t) = Y(t)))

Foundation: Coordination Protocols

Coordination protocols induce a set of infinite tables

(cf. Rule-Based Form for Stream Constraints, K. Dokter, 2018)

◮ Columns: ports ◮ Rows: simultaneous “observations”

X1 X2 ... Xn ∗ d ... ∗ ∗ ∗ ... e . . . . . . . . . Table: “execution” Set of tables: “computation”

Foundation: Coordination Protocols

Examples

Let X be a port of data type Signal. Consider φ = ∀t.(X(t) = ∗∨X(t) = 0) Solution: assignment of X to a data stream L (φ) = X ∗ ∗ . . . , X ∗ . . . , X ∗ . . . , X . . . , ...

Foundation: Coordination Protocols

Fact: coordination protocols only ‘interact’ for shared variables

Examples (No interaction)

Consider φ = ∀t.(X(t) = ∗) and ψ = ∀t.(Y(t) = 0)∨∀t.(Y(t) = ∗) L (φ) = X ∗ ∗ . . .

• and L (ψ) =

Y . . . , Y ∗ ∗ . . .

• L (φ ∧ψ) =

X Y ∗ ∗ . . . . . . , X Y ∗ ∗ ∗ ∗ . . . . . .

Foundation: Coordination Protocols

Fact: coordination protocols only ‘interact’ for shared variables

Examples (Interaction)

Consider φ = ∀t.(X(t) = ∗)∨∀t.(X(t) = 0) and ψ = ∃t.(X(t) = 0) L (φ) = X ∗ ∗ . . . , X . . .

• and L (ψ) =

X ∗ . . . , X ∗ . . . , ... L (φ ∧ψ) = X . . .

Foundation: Primitives

• B
• B
• B
• B
• B
• B
• B
• B
• B
• B
• B

C

• B

C

• B

C

• B

C

Foundation: Frame Conditions

Insight: modeling of buffers using frame conditions.

X M Z ∗ X M Z X M Z ∗ d d ∗ ∗ d d ∗ ∗ d d

These are overlapping as follows:

X Z

• d
• d
• d
• d

d

Foundation: Frame Conditions

Definition of buffer

X M Z ∗ X M Z X M Z ∗ d d ∗ ∗ d d ∗ ∗ d d

∀t.(( Z(t) = ∗ ∧M(t) = ∗∧M(t +1) = X(t)) ∨ (X(t) = ∗∧Z(t) = ∗ ∧M(t) = ∗∧M(t +1) = M(t)) ∨ (X(t) = ∗∧Z(t) = M(t)∧M(t) = ∗∧M(t +1) = ∗))

Foundation: Frame Conditions

Definition of buffer

X M Z ∗ X M Z X M Z ∗ d d ∗ ∗ d d ∗ ∗ d d

∀t.(( Z(t) = ∗ ∧M(t) = ∗∧M(t +1) = X(t)) ∨ (X(t) = ∗∧Z(t) = ∗ ∧M(t) = ∗∧M(t +1) = M(t)) ∨ (X(t) = ∗∧Z(t) = M(t)∧M(t) = ∗∧M(t +1) = ∗)) Problem: column M is not a port of buffer. Can we get rid of it?

Foundation: Frame Conditions

Alternative definition of buffer

X Z ∗ X Z ∗ ∗ ∗ d d ∗ ∗

∀t.( Z(t) = ∗∧X(t) = ∗ ∨ (Z(t) = ∗∧∃j.t < j ∧X(j) = ∗∧Z(j) = X(t) ∧ ∀i.t < i ∧i < j → X(i) = ∗∧Z(i) = ∗) ∨ (X(t) = ∗∧∃j.j < t ∧X(j) = Z(t)∧Z(j) = ∗ ∧ ∀i.j < i ∧i < t → X(i) = ∗∧Z(i) = ∗))

Foundation: Frame Conditions

Alternative definition of buffer

X Z ∗ X Z ∗ ∗ ∗ d d ∗ ∗

∀t.( Z(t) = ∗∧X(t) = ∗ ∨ (Z(t) = ∗∧∃j.t < j ∧X(j) = ∗∧Z(j) = X(t) ∧ ∀i.t < i ∧i < j → X(i) = ∗∧Z(i) = ∗) ∨ (X(t) = ∗∧∃j.j < t ∧X(j) = Z(t)∧Z(j) = ∗ ∧ ∀i.j < i ∧i < t → X(i) = ∗∧Z(i) = ∗)) Question: are these definitions equivalent?

Foundation: Frame Conditions

Alternative definition of buffer

X Z ∗ X Z ∗ ∗ ∗ d d ∗ ∗

∀t.( Z(t) = ∗∧X(t) = ∗ ∨ (Z(t) = ∗∧∃j.t < j ∧X(j) = ∗∧Z(j) = X(t) ∧ ∀i.t < i ∧i < j → X(i) = ∗∧Z(i) = ∗) ∨ (X(t) = ∗∧∃j.j < t ∧X(j) = Z(t)∧Z(j) = ∗ ∧ ∀i.j < i ∧i < t → X(i) = ∗∧Z(i) = ∗)) Question: are these definitions equivalent? No.

Foundation: Duals

Definition

A dual of a component Uφ is U⊥φ.

• B
• B
• B
• B

Foundation: Results

• 1. Found logical formalism

with data types and data streams

• 2. Defined primitive components
• 3. Two different kinds of nodes (Reo only has below)

O O2

• 2

n O

• 4. Prophet is dual of buffer

Overview

• 1. Motivation
• 2. Language
• 3. Foundation
• 4. Properties

Properties

◮ Time independence

(stuttering)

◮ Linearity

(reversibility)

◮ Causality

(speculative execution)

◮ Instantaneous

(stateless)

◮ Synchronous and asynchronous

(clocked and unclocked)

◮ Termination and progress

(safety and liveness)

Properties (here)

◮ Time independence

(stuttering)

◮ Linearity

(reversibility)

◮ Causality

(speculative execution)

◮ Instantaneous

(stateless)

◮ Synchronous and asynchronous

(clocked and unclocked)

◮ Termination and progress

(safety and liveness)

Properties: Sentences

Given a coordination protocol φ. A schematic property P(φ) is a sentence after substituting a coordination protocol φ. Validity of P(φ): P(φ) Classes of components: {φ | P(φ)}

Properties: Time Independence

Time independence is a closure condition: L (φ) = X ∗ ∗ . . . , ..., X ∗ . . . , ...

◮ May remove rows with all ∗ ◮ May insert row with all ∗

• 1. No real-time clocks
• 2. Independence is not compositional

Properties: Time Independence

Let φ(U) be a component. stretch(φ) := ∀ X : U.(φ( X) → ∀t.∃ Y : U.(φ( Y)∧ all-silent( Y,t)∧precong( X, Y,t)∧cong( X (t), Y (t+1)))) shrink(φ) := ∀ X : U.(φ( X) → ∀t.∃ Y : U.(φ( Y)∧ (all-silent( X,t) → precong( X, Y,t)∧cong( X (t+1), Y (t))))) Time independence is stretch(φ)∧shrink(φ).

Properties: Time Independence

• B
• B
• B
• B
• B
• B
• B
• B
• B
• B
• B

C

• B

C

• B

C

• B

C

Properties: Linearity

Event: (time, port, value) Bijection between input events and output events of same value X Y ∗ d d ∗ e e f ∗ ∗ f . . . . . . Intuition: no duplication, no garbage, no arbitrary

Properties: Linearity

• B
• B
• B
• B
• B
• B
• B
• B
• B
• B
• B

C

• B

C

• B

C

• B

C

Properties: Causality

Event: (time, port, value) Relation between input events and output events of same value Such that every output is not related to future input X Y ∗ ∗ d d ∗ d f d ∗ f . . . . . . Intuition: explain output only by seen observations

Properties: Causality

• B
• B
• B
• B
• B
• B
• B
• B
• B
• B
• B

C

• B

C

• B

C

• B

C

Properties: Termination and Progress

Productivity (execution): prod( X : P) := ∃t.

• i∈P

Xi(t) = ∗ Terminating (execution): term( X : P) := ∃t.(¬prod( X (t))) Terminating (computation): term(φ) := ∀ X : P.(φ( X) → term( X)) Deadlock: deadlock(φ, X : P) := φ( X)∧term( X)∧¬term(φ) a terminating execution in a non-terminating computation

Properties: Termination and Progress

• B
• B
• B
• B
• B
• B
• B
• B
• B
• B
• B

C

• B

C

• B

C

• B

C

Reasoning about Speculative Execution

• 1. We have prophets that intuitively models speculations,
• 2. If a prophet generates a true speculation,

then troughput is increased (critical path length reduced).

• 3. If a prophet generates a false speculation

then the system may come to a standstill,

• 4. Enforcing productivity with a pull,

such deadlock behavior is ruled out: therefore, only true speculations are specified.

Reasoning about Speculative Execution

• 1. The present model abstracts low-level details

(message passing, shared memory, locks, etc.)

• 2. Interesting properties formulated unambiguously
• 3. Specifications seem implementable in numerous ways:

◮ Sequentially, using backtracking ◮ Cooperatively, by scheduling components ◮ Parallel, one processor for each component ◮ Distributed, components reach consensus on observations ◮ etc.

• 4. A correct implementation preserves all properties of model