translation validation for a verified os kernel · 2021. 1. 6. · c standard semantics aside: why...

Translation Validation for a Verified OS Kernel

Thomas Sewell1 Magnus Myreen2 Gerwin Klein1

1UNSW & NICTA

2University of Cambridge

12 Feb 2013

NICTA Funding and Supporting Members and Partners

Translation Validation for a Verified OS Kernel Copyright NICTA 2013Thomas Sewell1 , Magnus Myreen2 , Gerwin Klein1 1/18

Overview Picture

voidsuspend(tcb_t *target){ ipcCancel(target); setThreadState(tar tcbSchedDequeue(ta

FORMALMODEL

LOGIC


Overview Picture


FORMALMODEL

GCC

LD

f0015594: e92d4010 push {r4, lr}f0015598: e1a04000 mov r4, r0f001559c: ebffff28 bl f0015244f00155a0: e1a00004 mov r0, r4f00155a4: e3a01000 mov r1, #0f00155a8: ebfff9a5 bl f0013c44f00155ac: e1a00004 mov r0, r4

LOGIC

REAL WORLD


Overview Picture


FORMALMODEL

GCC

LD


seL4

seL4: Formal Verification and All That

Gerwin Klein, Kevin Elphinstone, Gernot Heiser, June Andronick,David Cock, Philip Derrin, Dhammika Elkaduwe, Kai Engelhardt,Michael Norrish, Rafal Kolanski, Thomas Sewell, Harvey Tuch,Simon Winwood, Peter Gammie, Toby Murray, David Greenaway,Andrew Boyton, Daniel Matichuk, Matthew Brassil,Timothy Bourke, Sean Seefried, Corey Lewis and Xin Gao.

LOGIC

REAL WORLD


Overview Picture


FORMALMODEL

GCC

LD


seL4

seL4: Formal Verification and All That

Gerwin Klein, Kevin Elphinstone, Gernot Heiser, June Andronick,David Cock, Philip Derrin, Dhammika Elkaduwe, Kai Engelhardt,Michael Norrish, Rafal Kolanski, Thomas Sewell, Harvey Tuch,Simon Winwood, Peter Gammie, Toby Murray, David Greenaway,Andrew Boyton, Daniel Matichuk, Matthew Brassil,Timothy Bourke, Sean Seefried, Corey Lewis and Xin Gao.

ARM ISA and Decompiler

Anthony Fox and Magnus Myreen

LOGIC

REAL WORLD


Overview

This talk in one bullet point:

• We can prove the binary refines the formal model, for seL4’s verifiedcomponents and gcc-4.5.1 -O1.

Talk contents:• Structure of proof and approach.

• Alternative approaches.• C Semantics & C Standard.• Challenges.• Restrictions & workarounds.


Approach

C SEMANTICS

Binary ObjectPro

of

Pro

ducing

Conversion C IL

ASM IL

Com

pariso

n


GCC

LD

seL4Pr

oof

Pro

duci

ng

Conversion ASM Funs

ARM


Approach

C SEMANTICS

Binary ObjectPro

of

Pro

ducing

Conversion C IL

ASM IL

Com

pariso

n


GCC

LD

seL4Pr

oof

Pro

duci

ng

Conversion ASM Funs

ARM

- Isabelle/HOL- Pseudo Compilation

- HOL4- Decompilation into Logic- Cambridge ARM Semantics

- SMT+


Approach

C SEMANTICS

Binary ObjectPro

of

Pro

ducing

Conversion C IL

ASM IL

Com

pariso

n

Parsing

Conversion toIntermediate Language

Optimisation Passes

Instruction Scheduling

Assembly

Core

Front

End

Back

End


GCC

LD

seL4Pr

oof

Pro

duci

ng

Conversion ASM Funs

ARM


C Program Semantics

C SEMANTICS



C Program Semantics

Maps syntax of C to a deeply embedded language inIsabelle/HOL with an operational semantics.

Partial semantics to explain undefined behaviour.

if (...) {...} ⇒ IF (...) THEN ... FI

f (1, 2); ⇒ CALL f_'proc (1, 2);;

x ++; ⇒

Guard {`x <=s `x + 1}

(`x :== `x + 1);;

*p = *q; ⇒

Guard {ptr_valid `p}

Guard {ptr_valid `q}

mem :== h_upd `p

(h_val `q `mem) `mem


C Program Semantics

Maps syntax of C to a deeply embedded language inIsabelle/HOL with an operational semantics.

Partial semantics to explain undefined behaviour.

if (...) {...} ⇒ IF (...) THEN ... FI

f (1, 2); ⇒ CALL f_'proc (1, 2);;

x ++; ⇒ Guard {`x <=s `x + 1}

(`x :== `x + 1);;

*p = *q; ⇒ Guard {ptr_valid `p}

Guard {ptr_valid `q}

mem :== h_upd `p

(h_val `q `mem) `mem


C Standard Semantics

Aside: Why not just trust the compiler?

The ptr_valid assertion used in Guard is subtle.

The object rule says that a pointers may come from arithmetic within anobject, & and malloc.

What about casts from numbers?(pt_t *)(pt[x] & 0xFFFFF000)

There are multiple interpretations of the C language.• NICTA seL4: Liberal, portable assembler, soundy.

• Strict aliasing rule but not object rule.

• CompCert: Conservative.


Decompilation

Binary Object

Proof

Pro

duci

ng

Conversion ASM Funs

ARM


Example Decompilation

uint avg (uint i, uint j) {

return (i + j) / 2;

}

<avg>:

avg+0 e0810000 add r0, r1, r0 // add r1 to r0

avg+4 e1a000a0 lsr r0, r0, #1 // shift r0 right

avg+8 e12fff1e bx lr // return

avg (r0, r1) = let r0 = r1 + r0 inlet r0 = r0 >>> 1 in

r0

{R0 r0 ∗ R1 r1 ∗ R14 lr ∗ PC p }p : e0810000 e1a000a0 e12fff1e

{R0 (avg (r0, r1)) ∗ R1 _ ∗ R14 _ ∗ PC lr }


Example Decompilation

uint avg (uint i, uint j) {

return (i + j) / 2;

}

<avg>:

avg+0 e0810000 add r0, r1, r0 // add r1 to r0

avg+4 e1a000a0 lsr r0, r0, #1 // shift r0 right

avg+8 e12fff1e bx lr // return

avg (r0, r1) = let r0 = r1 + r0 inlet r0 = r0 >>> 1 in

r0

{R0 r0 ∗ R1 r1 ∗ R14 lr ∗ PC p }p : e0810000 e1a000a0 e12fff1e

{R0 (avg (r0, r1)) ∗ R1 _ ∗ R14 _ ∗ PC lr }Translation Validation for a Verified OS Kernel Copyright NICTA 2013Thomas Sewell1 , Magnus Myreen2 , Gerwin Klein1 9/18

Challenges for Decompilation

uint avg8 (uint i1, i2, i3, i4, i5, i6, i7, i8) {

return (i1+i2+i3+i4+i5+i6+i7+i8) / 8;

}

<avg8>:

e0811000 add r1, r1, r0

e0811002 add r1, r1, r2

e59d2000 ldr r2, [sp] // load

e0811003 add r1, r1, r3

e0810002 add r0, r1, r2

e99d000c ldmib sp, {r2, r3} // load

e0800002 add r0, r0, r2

e0800003 add r0, r0, r3

e59d300c ldr r3, [sp, #12] // load

e0800003 add r0, r0, r3

e1a001a0 lsr r0, r0, #3

e12fff1e bx lr


Challenges for Decompilation

uint avg8 (uint i1, i2, i3, i4, i5, i6, i7, i8) {

return (i1+i2+i3+i4+i5+i6+i7+i8) / 8;

}

<avg8>:

e0811000 add r1, r1, r0

e0811002 add r1, r1, r2

e59d2000 ldr r2, [sp] // load

e0811003 add r1, r1, r3

e0810002 add r0, r1, r2

e99d000c ldmib sp, {r2, r3} // load

e0800002 add r0, r0, r2

e0800003 add r0, r0, r3

e59d300c ldr r3, [sp, #12] // load

e0800003 add r0, r0, r3

e1a001a0 lsr r0, r0, #3

e12fff1e bx lrTranslation Validation for a Verified OS Kernel Copyright NICTA 2013Thomas Sewell1 , Magnus Myreen2 , Gerwin Klein1 10/18

Stack and Heap

Aside: Hiding stack accesses mean they must not be aliased.

Our C semantics forbids pointers to the stack.

We also eliminate padding, clearly separating:

• the heap, under user control.

• the stack, under compiler control.

Enables a simple notion of correct compilation:

∀(in, in_heap) ∈ domain(C). C(in, in_heap) = B(in, in_heap)

This would be difficult with higher level optimisations.


Conversion to Graph

C SEMANTICS

Pro

of

Pro

ducing

Conversion C IL

ASM ILASM Funs

Not going to discuss this in detail.


Graph Refinement

The proof of refinement between graphs involves two processes:

• A search process, which heuristically discovers a proof object.

• A check process, which checks the proof is sound.

This follows Pnueli’s translation validation design.

Both processes use SMT solving extensively.

ass_24

t_Ret_24

C

ass_25

C

26

T

t_Err_26

F

27

F

37

T

36

T

t_Err_37

F

ass_28

126

C

N

29

T

t_Err_29

F

ass_30

C

31

T

t_Err_31

F

ass_32

C

33

T

t_Err_33

F

ass_34

C

35

T

t_Err_35

F

T F

ass_38

t_Ret_38

C

39

F T

C

ass_48

125

N

ass_49

N

ass_50

C

ass_51

N

ass_52

C

53

T

t_Err_53

F

ass_54

C

ass_55

C

56

T

t_Err_56

F

C

ass_62

N

ass_63

N

ass_64

C

ass_65

N

ass_66

C

67

T

t_Err_67

F

ass_68

C

ass_69

C

70

T

t_Err_70

F

C

ass_95

C

96

T

t_Err_96

F

108

N

107

ass_114

N

C

ass_112

N

111

C

ass_109

C

ass_110

C

T

t_Err_111

F


Proof Objects

1

ass_22

N

ass_21

C

ass_2

t_Ret_2

C

ass_3

C

4

T

t_Err_4

F

ass_5

122

C

117

N

ass_6

C

ass_7

t_Ret_7

C

ass_8

C

9

T

t_Err_9

F

10

T

t_Err_10

F

ass_11

C

ass_12

104

C

93

N

ass_13

89

C

45

N

14

T F

ass_15

C

ass_16

C

ass_17

C

ass_18

C

ass_19

C

ass_20

C

C

23

N

ass_24

t_Ret_24

C

ass_25

C

26

T

t_Err_26

F

27

F

37

T

36

T

t_Err_37

F

ass_28

126

C

N

29

T

t_Err_29

F

ass_30

C

31

T

t_Err_31

F

ass_32

C

33

T

t_Err_33

F

ass_34

C

35

T

t_Err_35

F

T F

ass_38

t_Ret_38

C

39

F T

ass_40

C

ass_41

C

42

N

43

N

44

ass_90

N

C

ass_88

N

ass_87

C

ass_46

C

47

T

t_Err_47

F

ass_48

125

N

N

ass_49

N

ass_50

C

ass_51

N

ass_52

C

53

T

t_Err_53

F

ass_54

C

ass_55

C

56

T

t_Err_56

F

ass_57

C

ass_58

C

ass_59

C

ass_60

C

ass_61

C

ass_62

N

ass_63

N

ass_64

C

ass_65

N

ass_66

C

67

T

t_Err_67

F

ass_68

C

ass_69

C

70

T

t_Err_70

F

ass_71

C

ass_72

C

ass_73

C

ass_74

C

ass_75

C

76

T F

ass_77

C

ass_78

C

79

T

t_Err_79

F

ass_80

C

ass_81

C

ass_82

C

83

T

t_Err_83

F

ass_84

C

ass_85

C

86

T F

C

92

ass_105

N

C

ass_103

N

ass_102

C

ass_94

C

ass_95

C

96

T

t_Err_96

F

ass_97

113

C

108

N

ass_98

C

ass_99

C

100

T

t_Err_100

F

ass_101

C

C

107

ass_114

N

C

ass_112

N

111

C

ass_109

C

ass_110

C

T

t_Err_111

F

116

ass_123

N

C

ass_121

N

120

C

ass_118

C

ass_119

C

T

t_Err_120

F

Proof objects contain:

• An inlining of all needed function bodies intoone space.

• Restrict rules, which observe that a givenpoint in a loop may be reached only n times.

• Split rules, which observe that a C loop pointis reached as often as a loop point in thebinary.

• Checked by k -induction.• Parameter eqs must relate enough of binary

state to C state to relate events after the loop.


Proof Objects

1

ass_22

N

ass_21

C

ass_2

t_Ret_2

C

ass_3

C

4

T

t_Err_4

F

ass_5

122

C

117

N

ass_6

C

ass_7

t_Ret_7

C

ass_8

C

9

T

t_Err_9

F

10

T

t_Err_10

F

ass_11

C

ass_12

104

C

93

N

ass_13

89

C

45

N

14

T F

ass_15

C

ass_16

C

ass_17

C

ass_18

C

ass_19

C

ass_20

C

C

23

N

ass_24

t_Ret_24

C

ass_25

C

26

T

t_Err_26

F

27

F

37

T

36

T

t_Err_37

F

ass_28

126

C

N

29

T

t_Err_29

F

ass_30

C

31

T

t_Err_31

F

ass_32

C

33

T

t_Err_33

F

ass_34

C

35

T

t_Err_35

F

T F

ass_38

t_Ret_38

C

39

F T

ass_40

C

ass_41

C

42

N

43

N

44

ass_90

N

C

ass_88

N

ass_87

C

ass_46

C

47

T

t_Err_47

F

ass_48

125

N

N

ass_49

N

ass_50

C

ass_51

N

ass_52

C

53

T

t_Err_53

F

ass_54

C

ass_55

C

56

T

t_Err_56

F

ass_57

C

ass_58

C

ass_59

C

ass_60

C

ass_61

C

ass_62

N

ass_63

N

ass_64

C

ass_65

N

ass_66

C

67

T

t_Err_67

F

ass_68

C

ass_69

C

70

T

t_Err_70

F

ass_71

C

ass_72

C

ass_73

C

ass_74

C

ass_75

C

76

T F

ass_77

C

ass_78

C

79

T

t_Err_79

F

ass_80

C

ass_81

C

ass_82

C

83

T

t_Err_83

F

ass_84

C

ass_85

C

86

T F

C

92

ass_105

N

C

ass_103

N

ass_102

C

ass_94

C

ass_95

C

96

T

t_Err_96

F

ass_97

113

C

108

N

ass_98

C

ass_99

C

100

T

t_Err_100

F

ass_101

C

C

107

ass_114

N

C

ass_112

N

111

C

ass_109

C

ass_110

C

T

t_Err_111

F

116

ass_123

N

C

ass_121

N

120

C

ass_118

C

ass_119

C

T

t_Err_120

F





• Checked by k -induction.

• Parameter eqs must relate enough of binarystate to C state to relate events after the loop.


Proof Objects

1

ass_22

N

ass_21

C

ass_2

t_Ret_2

C

ass_3

C

4

T

t_Err_4

F

ass_5

122

C

117

N

ass_6

C

ass_7

t_Ret_7

C

ass_8

C

9

T

t_Err_9

F

10

T

t_Err_10

F

ass_11

C

ass_12

104

C

93

N

ass_13

89

C

45

N

14

T F

ass_15

C

ass_16

C

ass_17

C

ass_18

C

ass_19

C

ass_20

C

C

23

N

ass_24

t_Ret_24

C

ass_25

C

26

T

t_Err_26

F

27

F

37

T

36

T

t_Err_37

F

ass_28

126

C

N

29

T

t_Err_29

F

ass_30

C

31

T

t_Err_31

F

ass_32

C

33

T

t_Err_33

F

ass_34

C

35

T

t_Err_35

F

T F

ass_38

t_Ret_38

C

39

F T

ass_40

C

ass_41

C

42

N

43

N

44

ass_90

N

C

ass_88

N

ass_87

C

ass_46

C

47

T

t_Err_47

F

ass_48

125

N

N

ass_49

N

ass_50

C

ass_51

N

ass_52

C

53

T

t_Err_53

F

ass_54

C

ass_55

C

56

T

t_Err_56

F

ass_57

C

ass_58

C

ass_59

C

ass_60

C

ass_61

C

ass_62

N

ass_63

N

ass_64

C

ass_65

N

ass_66

C

67

T

t_Err_67

F

ass_68

C

ass_69

C

70

T

t_Err_70

F

ass_71

C

ass_72

C

ass_73

C

ass_74

C

ass_75

C

76

T F

ass_77

C

ass_78

C

79

T

t_Err_79

F

ass_80

C

ass_81

C

ass_82

C

83

T

t_Err_83

F

ass_84

C

ass_85

C

86

T F

C

92

ass_105

N

C

ass_103

N

ass_102

C

ass_94

C

ass_95

C

96

T

t_Err_96

F

ass_97

113

C

108

N

ass_98

C

ass_99

C

100

T

t_Err_100

F

ass_101

C

C

107

ass_114

N

C

ass_112

N

111

C

ass_109

C

ass_110

C

T

t_Err_111

F

116

ass_123

N

C

ass_121

N

120

C

ass_118

C

ass_119

C

T

t_Err_120

F





• Checked by k -induction.• Parameter eqs must relate enough of binary

state to C state to relate events after the loop.


SMT

SMT problems generated contain:

• Fixed-length values and arithmetic: word32, +, -, <= etc.

• Arrays to model the heap: heap :: word30 => word32.

• If-then-else operators to handle multiple paths.

x := 12

x < 12?

x := y + 1

T F

• Validity assertions and needed inequalities:ptr1_valid & ptr2_valid⇒ ptr1 > ptr2 + 7 ∨ ptr2 > ptr1 + 15.

Strong compatibility with SMTLIB2 QF_ABV.


Strong similarity to QF_ABV category of the SMT competition.

We ran this experiment with Z3 (version 4.0) and SONOLAR (version2012-06-14).

The solvers are efficient at producing both sat and unsat results, whichis important in discovering and checking a proof.


Results

The proof rules and inlining heuristic mentioned are sufficient for seL4’sverified code with gcc-4.5.1 -O1.

Nested loops and some -O2 loop optimisations are not yet handled.

0.01

0.1

1

10

100

1000

10000

1 10 100 1000

Sec

onds

C Statements

'plot'


Conclusions

Translation validation can scale up to substantial problem size, usingnaive approaches, for a carefully managed problem.

Supporting factors:

• Simple looping structure.

• C Semantics already at the level of bits and bytes.

• Clear separation of compiler and user control.

• Strong compatibility with SMT QF_ABV.

Software is available athttp://www.ssrg.nicta.com.au/software/TS/graph-refine


translation validation for a verified os kernel · 2021. 1. 6. · c standard semantics aside: why...

Documents