Formal verification of low-level execution platforms Apps OS - - PowerPoint PPT Presentation

formal verification of low level execution platforms
SMART_READER_LITE
LIVE PREVIEW

Formal verification of low-level execution platforms Apps OS - - PowerPoint PPT Presentation

Roberto Guanciale Estonian Winter School Day 02 Formal verification of low-level execution platforms Apps OS Hardware Host 1 Motivations Apps Crypto Service OS Hypervisor/ Separation Kernel Hardware Host 1 Motivations Separation


slide-1
SLIDE 1

Formal verification

  • f low-level

execution platforms

Roberto Guanciale Estonian Winter School Day 02

slide-2
SLIDE 2

Motivations

Host 1

Hardware OS Apps

slide-3
SLIDE 3

Motivations

Host 1

Hardware OS Apps Hypervisor/ Separation Kernel Crypto Service

slide-4
SLIDE 4

Hosting untrusted SW (hypervisors host operating systems)

Hosting trusted critical SW

Supporting

CPU sharing

Spatial isolation

Context switch

Communications

Separation Kernel / Hypervisor

slide-5
SLIDE 5
  • Registers (Program Counter)
  • Flags
  • Fetches instruction from memory
  • Executes arithmetical instructions
  • Loads/Stores data from/to memory
  • Has several mode of operations (PL0/PL1)
  • Multiplexed

5 minute course on computer architecture (ARMv7)

slide-6
SLIDE 6
  • Contains instructions
  • Contains data (heap/stack/etc)
  • Is a big table from physical addresses

to bytes

  • Partitioned

5 minute course on computer architecture

slide-7
SLIDE 7
  • Translates virtual addresses to

physical addresses

  • Configured via page tables (stored in

memory) and coprocessors

  • for every va
  • corresponding pa (if mapped)
  • access rights (rd/wt)
  • required mode
  • Enforce access policies

5 minute course on computer architecture

MMU

Load/Store VA Page Tables Load/Store PA Exceptions

slide-8
SLIDE 8

5 minute course on computer architecture

MMU

Load/Store VA Page Tables Load/Store PA Exceptions

  • From PL1 to PL0
  • Special instruction
  • Jump to an arbitrary address
  • From PL0 to PL1
  • Exceptions / Instruction to raise a SW interrupt
  • jump to a fixed address (exception handler)
slide-9
SLIDE 9

ISA model

slide-10
SLIDE 10

ISA model

slide-11
SLIDE 11

Hardware OS Hypervisor Crypto Service

Cooperative scheduling Static memory allocation Message passing Paravirtualization No preemption

slide-12
SLIDE 12

Hardware OS Hypervisor Crypto Service

Cooperative scheduling Static memory allocation Message passing Paravirtualization No preemption

  • executed in PL1
  • invoked via SW interrupt
  • supervises page tables
slide-13
SLIDE 13

A trace of the system

slide-14
SLIDE 14

A trace of the system

Context switch: page tables are updated blue-registers are stored red-registers are loaded

slide-15
SLIDE 15

Security property

  • Non-interference
slide-16
SLIDE 16

Security property

  • Non-interference
slide-17
SLIDE 17

Security property

  • Non-interference
slide-18
SLIDE 18

Security property

  • Non-interference
slide-19
SLIDE 19

Security property

  • Non-interference
slide-20
SLIDE 20

Security property

  • Non-interference

Does not work: the two partitions communicate!

slide-21
SLIDE 21

Top Level Specification

Host 1

Hardware Software Crypto Service

Host 2

Hardware

slide-22
SLIDE 22

Top level specification (ideal world)

  • Two physically separated machine
  • Only one machine active
  • No PL1 computation
slide-23
SLIDE 23

Top level specification (ideal world)

  • Two physically separated machine
  • Only one machine active
  • No PL1 computation

?

slide-24
SLIDE 24

Top level specification (ideal world)

  • Two physically separated machine
  • Only one machine active
  • No PL1 computation

Ideal Functionality

slide-25
SLIDE 25

Top level specification (ideal world)

  • Two physically separated machine
  • Only one machine active
  • No PL1 computation (replaced by atomic functionalities)

Ideal Functionality

slide-26
SLIDE 26

Top level specification (ideal world)

  • Two physically machines (one active)

and hypervisor data

slide-27
SLIDE 27

Top level specification (ideal world)

  • Two physically machines (one active)

and hypervisor data

  • Standard computations

have standard effects

slide-28
SLIDE 28

Top level specification (ideal world)

  • Two physically machines (one active)

and hypervisor data

  • Standard computations

have standard effects

  • Exceptions activate the

ideal functionalities

slide-29
SLIDE 29

Verification Strategy

  • Trace equivalence
  • Unwinding condition based on bisimulation
slide-30
SLIDE 30

Verification Strategy

  • Bisimulation
slide-31
SLIDE 31

Verification Strategy

  • Bisimulation

Weak transitions

slide-32
SLIDE 32

Bisimulation

Reg OS1 Hypervisor OS2 Reg OS1 Reg OS2 h

slide-33
SLIDE 33

Bisimulation

Reg OS1 Hypervisor OS2 Reg OS1 Reg OS2 h

slide-34
SLIDE 34

Bisimulation

Reg OS1 Hypervisor OS2 Reg OS1 Reg OS2 h

slide-35
SLIDE 35

Bisimulation

Reg OS1 Hypervisor OS2 Reg OS1 Reg OS2 h

slide-36
SLIDE 36

Bisimulation

Reg OS1 Hypervisor OS2 Reg OS1 Reg OS2 h

slide-37
SLIDE 37

Bisimulation

Reg OS1 Hypervisor OS2 Reg OS1 Reg OS2 h

slide-38
SLIDE 38

Exercise

  • Assuming non-interference property of H: H only depends
  • n the active machine
  • n the content of the memory of other machine at address

OUT2 (OUT1)

  • Assuming non-interference property for guest 2: region of memory

in MEM2 that includes OUT2 does not depend on the content of region K2

slide-39
SLIDE 39

Proof Decomposition: PL0 transitions

  • Non-interference for ARMv7
  • Non dependent by the kernel code
  • Non dependent by the partition code
slide-40
SLIDE 40

Proof Decomposition: PL1 transitions

  • Functional correctness
  • The handlers code respects the specification
slide-41
SLIDE 41

PL0 proof

  • Non dependent by the kernel code / guest code
  • have to be done for every possible instruction
  • Strategy
  • prove SW independent theorems assuming properties of the

system

  • verify that our SW meets this assumptions
slide-42
SLIDE 42

PL0 proof: ISA integrity

slide-43
SLIDE 43

PL0 proof: ISA integrity

slide-44
SLIDE 44

PL0 proof: ISA integrity

slide-45
SLIDE 45

PL0 proof: ISA integrity

slide-46
SLIDE 46

Exercise

  • When is an equivalence relation?
  • Reflexive
  • Symmetric
  • Transitive
slide-47
SLIDE 47

PL0 proof: ISA confidentiality

slide-48
SLIDE 48

PL0 proof: ISA confidentiality

slide-49
SLIDE 49

PL0 proof: ISA confidentiality

slide-50
SLIDE 50

PL0 proof: ISA confidentiality

slide-51
SLIDE 51

PL0 proof: ISA confidentiality

slide-52
SLIDE 52

PL0 proof: ISA confidentiality

slide-53
SLIDE 53

PL0 proof: ISA confidentiality

slide-54
SLIDE 54

Proof obligation (O1): page tables

slide-55
SLIDE 55

PL0 Proof: memory equality

  • If machine 1 is active then machine 2 is unchanged
  • from O1 and T1 we know that in the real machine the memory

MEM2 is unchanged

  • thus the equivalence between the real machine and machine 2 for

MEM2 is preserved

slide-56
SLIDE 56

PL0 Proof: memory equality

  • from O1 and T2 we know that the behavior of both the real machine

and machine 1 depends only on memory in MEM1

  • thus the equivalence between the real machine and machine 1 for

MEM1 is preserved

slide-57
SLIDE 57

Proof obligation (O2): page tables

slide-58
SLIDE 58

PL0 Proof: invariants and hypervisor data-structures

  • from definition of TLS we know that the hypervisor data can not be

changed

  • from O2 and T1 we know that in the real machine the memory that

holds these structure can not be changed

  • from O2 and T1 we know that the invariants are preserved
slide-59
SLIDE 59

Exercise

  • Extend the model and proofs to handle a Memory Mapped device

(UART)

  • Address DevOut can be used to write something
  • Address DevIn can be used to read something
  • Device fetches and writes into these addresses
  • Partition 2 should be in control of the device
  • Device transitions are interleaved with CPU transitions (assume

the device does not perform any action while the CPU is in PL1)

slide-60
SLIDE 60

Exercise

  • How should DMA devices be handled?
  • Address DevOut can be used to write a pointer
  • Address DevIn can be used to write a pointer
  • Device fetches these pointers and writes/reads into the pointed

memory

  • Partition 2 should be in control of the device
slide-61
SLIDE 61

Exercise

  • Extend the toy CPU with a new instruction
slide-62
SLIDE 62

Summary

  • ISA model
  • Verification Goal (via TLS)
  • Proof decomposition
  • Sketch of proof for PL0
  • Upcoming
  • Verification for PL1
slide-63
SLIDE 63

THANKS! Any questions?

You can find me at robertog@kth.se http://prosper.sics.se/

References