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 � � B � C C � C B B C

Language: Input-only Components � � � � � � B � B � B � B � B � B � B � B � B � B B � � B � C C � C B B C

Language: Output-only Components � � � � � � B � B � B � B � B � B � B � B � B � B B � � B � C C � C B B C

Language: Interface Definition An interface U consists of: 1. input ports I 1 ,..., I n 2. ouput ports O 1 ,..., O k 3. each port has an associated data type � � O � � 2 O 2 � � � � � � � n O � Given interface U , by U ⊥ we denote its dual .

Language: Instances and References B � � C � C B

Language: Instances and References x z B � � y C � C B Component instances x , y , z ,...

Language: Instances and References x z B � � y C � C B Component instances x , y , z ,... Qualified x . A and unqualified A .

Language: Composition x z B � � y C � C B Definition A composition is either: ◮ an instance

Language: Composition x z B � � y C � C B Definition A composition is either: ◮ an instance ◮ two compositions adjoined

Language: Composition x z B � � y C � C B Definition A composition is either: ◮ an instance ◮ two compositions adjoined ◮ identification of two references of a composition

Language: Composition x z B � � � y C � C C B B 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 x z B � � � y C � C C B B Definition (to be continued) A component is either: ◮ primitive

Language: Component x z B � � � y C � C C B B 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 x s ◮ constants ◮ function symbols Formulas: standard ◮ propositions ◮ predicates of terms ◮ standard logical symbols ¬ , ∧ , ∨ , → , ↔ ◮ first-order quantification ∃ x s , ∀ x s binders for x s 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” X 1 X 2 ... X n ∗ 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 � X X X X ∗ 0 ∗ 0 L ( φ ) = , , , , ... ∗ ∗ 0 0 . . . . . . . . . . . .

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 ) = ∗ ) � X � Y Y � � ∗ 0 ∗ L ( φ ) = and L ( ψ ) = , ∗ 0 ∗ . . . . . . . . . � X Y X Y � ∗ 0 ∗ ∗ L ( φ ∧ ψ ) = , ∗ ∗ ∗ 0 . . . . . . . . . . . .

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 ) � X X � X X � ∗ 0 ∗ 0 L ( φ ) = , and L ( ψ ) = , , ... ∗ 0 0 ∗ . . . . . . . . . . . . � X � 0 L ( φ ∧ ψ ) = 0 . . .

Foundation: Primitives � � � � � � B � B � B � B � B � B � B � B � B � B B � � B � C C � C B 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 ) = ∗ ))