[PPT] - Provably Secure Execution Platforms - Lecture Four: A Simple PowerPoint Presentation

SLIDE 1

Provably Secure Execution Platforms

Lecture Four:

A Simple Separation Kernel and Its Verification

Mads Dam

KTH Royal Institute of Technology

BISS spring school, Bertinoro 2018

SLIDE 2

The Goal

Context switch: Fixed round-robin scheduling, assume two

guests, statically allocated

Asynchronous message passing through hypercall (swi)
Paravirtualization

Hypervisor

Dam, Guanciale, Khakpour, Nemati, Schwarz: Formal Verification of Information Flow Security for a Simple ARM-Based Separation Kernel, CCS’13

SLIDE 3

Kernel Basics

Q: What is a kernel? A: A set of event handlers and some data structures for support Three types of events:

Exceptions

– arise as result of a processor error conditions

Software interrupts

– arise when a user program wants to invoke some service

Hardware interrupts

– Arise when a piece of hardware (e.g. USB device, NIC, …) wants to invoke some service

SLIDE 4

Kernel Basics

Upon an event a handler routine is invoked, user state stored on stack and privilege level is raised Upon return user state is restored – In some suitable form Parameters transferred in registers – When applicable … Results returned in registers – When applicable … During handler execution, exceptions and interrupt may be disabled or not – Non-preemptive kernel: No nesting of interrupts Our kernel is preemptive

SLIDE 5

Ideal Model

Describes the abstract functionality of the system, here:

CPUs are virtual, with only user

level functionality

All privileged execution replaced

by ideal handlers

CPUs are ”physically separated”
Only communication between

guests through communication and instruction cycle counting

CPU CPU

SLIDE 6

Ideal Model

Context switching:

Only one of user CPUs active at any

time Sending a message:

Hypercall swi 1 causes content of

reg 0 to be written to msgbox Receiving a message:

If msgbox full on switch to receiver,

instead of restoring receiver invoke user level handler Restoring receiver:

Once message processing done

invoke swi 0 to restore receiver

CPU CPU

SLIDE 7

: Normal sender execution : Message processing : Send hypercall : Resume hypercall : Normal receiver execution

Ideal Model: Scheduling

Scheduling round

Sender Receiver Scheduler

SLIDE 8

Ideal model state:

: User CPU states
: Messaging data structures
: Elapsed time
: Activity flag

Messaging data structures:

: Indicates if guest i is ready to receive a message
: User context pointer used to switch

between message processing and normal execution

: message box

Ideal Model

SLIDE 9

Context fields are stored consecutively in memory is field accessor is field update Also use tuple notation:

Records and Contexts

SLIDE 10

Initial state :

: Initial states with

– Registers zeroed – initialized to make the user address spaces disjoint and not contain the vector jump addresses – suitably initialized within user address space – initialized to suitably large number (return to that)

Message data structures initialized with

, for suitable

Ideal Model, Initial State

These are defined later

SLIDE 11

User step: User step, symmetric case: Many symmetric cases below, mostly omitted

Ideal Model, Transitions

SLIDE 12

Guest switch, message processing in progress:

: Pop context from stack, return to user mode
: Fixed number of cycles for handler, to be set later
Similar transition rule for

Ideal Model, Transitions

SLIDE 13

Guest switch, no message pending:

cycles for handler
Similar transition rule for

Ideal Model, Transitions

SLIDE 14

Some helper functions:

restoreUser, restoreCtx

SLIDE 15

Guest switch, receive message:

, :

Entry points for guest 0/guest 1 message handlers

Ideal Model, Transitions

SLIDE 16

Guest resume:

+ symmetric rule, as always

Ideal Model, Transitions

SLIDE 17

Guest send:

+ symmetric rule
Note: Up to guests to implement flow control

Ideal Model, Transitions

SLIDE 18

Ideal Model, Exercises

Exercise 1: Convince yourself that the transition semantics makes sense by mentally executing a few simple scenarios (and report to me any bugs you find!) Exercise 2: Prove some simple sanity properties, such as:

For any reachable state (state

reachable from the initial state): – At most one of is in privileged state – If is in privileged state then ’s program counter is jump vector address – Stack pointers differ from their initial values only when one

f the guests are in privileged state
To prove such properties use a suitable invariant

SLIDE 19

Ideal Model, Exercises

Exercise 3: Does the transition semantics pose any constraints on the choice of ? Exercise 4 (harder): Devise a ”single-sided” semantics in which

nly one guest is executing, sending and receiving data through

transition labelled IO. States would have the shape . For transitions we would have a user transition: For privileged transitions, e.g.:

SLIDE 20

Ideal Model, Exercises

Exercise 4, continued: Show that for each trace of the ideal system there exists a corresponding pair of traces in the single-sided system such that the sequence of words exchanged in the ideal system trace corresponds to the sequence of words input, respectively

utput, in the single-sided trace.

SLIDE 21

Ideal Model, Exercises

Exercise 5: Propose an ideal model transition rule for exceptions. You may assume a pair of guest exception handler entry points fooo , . The exception handler needs to receive as parameter in register 0 the address of the offending instruction.

SLIDE 22

Real Model

Task:

Use only single processor
No ideal functionality (the

handlers)

Handlers explicitly

represented as code executing at privileged level

Data structures (e.g.

channels, stacks) to be explicitly represented in memory

Code store in memory

Hypervisor

SLIDE 23

Memory Layout

Two partitions/guests Execute in disjoint memory regions

Guest

is active when Kernel memory regions

Vector region

– Contains exception and interrupt jump addresses

Kernel region

– Contains kernel code and data structures ,…: Kernel addresses holding the corresponding values

SLIDE 24

Guest Memory

Guest entry points: – – Guest message handlers: – – Guest exception handlers: – –

SLIDE 25

Contexts: – ref /* ”Normal” context for guest 0 – ref /* Do. For guest 1

Kernel Region: Task Switching

SLIDE 26

Stack roots: – – – – Each stack assigned a memory region with delimiters in: – – – –

Kernel Region: Stacks

Size?

SLIDE 27

Channels: – /* ? /* Resume context – –

Kernel Region: Channels

SLIDE 28

In kernel memory: – – – – – In vector region: – – – –

Kernel Region: Handlers

SLIDE 29

Initialisation

Processor initialised with: – Register 0,…,3, mode, time zeroed – – – , ??? – , –

as processor, but with

,

SLIDE 30

Handlers

Handlers are now executed on the ”real” machine, using the

transition rules of lecture 3

Handler tasks:

– Extract state information:

Which guest? Not trivial since irq’s/exception’s can be
nested. Use the stack pointer memory region.
Which state? Need to figure some state information to

determine what action to take. – Update state: Channels, contexts – Prepare stack – Return from exception loads registers including pc in one atomic (!) step

SLIDE 31

Show irq_entry.pseudo, swi1_entry (mask). (Find them in the course directory) Exercise 6. Give similar pseudo-code implementations of the

ther handlers.

Exercise 7. Find a suitable Hoare-style specification of the irq_entry routine. Use weakest preconditions to show that it holds, under the assumption that it is never preempted.

Handlers

SLIDE 32

Handlers

Exercise 8. t_sw1, t_sw2, t_rcv, t_res, t_send: The ideal model transition rules leave these numbers unspecified. Explain how to calculate them, and estimate t_rcv. Exercise 9. t_max: We have also left t_max unspecified. Propose a lower bound. Exercise 10. Stacks: Stacks can grow in an unbounded fashion in pathological cases. Present a simple condition that will prevent stacks from growing larger than 2|ctx|.

SLIDE 33

Verification

Goal: – Want to prove that, when running on top of the kernel, the two guest systems do not interfere in unintended ways. – What does ”interfere” mean? – What does ”in unintended ways” mean?

Hypervisor

SLIDE 34

Noninterference

Proposal #1: Noninterference Can adapt definition of noninterference mod system variables, lecture 2, in the following way:

Variables:

– High variables – content of guest 1 memory – System variables – content of kernel memory – Low variables – content of guest 0 memory

Observations:

– Content of low memory + activity of guest

Recapping:

– Kernel (content of kernel memory) is NI, if whenever started in states s_0,s_1 for which kernel and low variables are identical, the observations are the same

When is a guest active?

SLIDE 35

Noninterference

Pictorially:

Unfortunately this does not work
Why? Would declassification help? Why not?

Hypervisor Hypervisor

SLIDE 36

Our Approach

Equivalence: Each guest “sees” the same observations
When guest G is active, the user mode observable parts of the

machine state are identical

Separation kernel CPU CPU CPU

SLIDE 37

= Vanilla NI in Absence of Communication

Separation kernel CPU CPU CPU

CPU

CPU

Separation kernel

CPU (By ”our approach”) (By ”our approach”) (Since there is no communication)

SLIDE 38

Pick an initial ideal model state
Pick an initial real model state
Need the states to be ”suitably related”, for instance:

– , , , , III , , etc. – , etc. – , whenever – (same for guest 1 memory) – , etc. – iff guest 0 scheduled in

Note: This holds when guest 0 is first scheduled in both ideal

and real model

Formally

SLIDE 39

Trace of ideal model: Trace of real model: Show that:

Top Level Verification Goal

1 2 n n+1

. . . . . .

1 2 n n+1

. . . . . .

SLIDE 40

Like the ”NI modulo system variables” notion from lecture 2 Define relation on states in ideal and real model as for the initial states: – iff – Observations of guest in = observations of guest in and the system states are suitably related – Guest is scheduled in iff guest is scheduled in IIIIIIII , the channel states in the guest systems are ”compatible”, etc. etc. Exercise 11: Propose a suitable definition of . In particular, what to do about time?

Proof Strategy

SLIDE 41

Unwinding Relation

Identical:

User mode readable memory
User mode observable registers
Channels
Time

SLIDE 42

Unwinding Relation

Ide Weak bisimulation

Per partition
User mode observations to be preserved
Weak handler transitions

SLIDE 43

Unwinding Relation

Ide Weak bisimulation

Per partition
User mode observations to be preserved
Weak handler transitions
What about preemption?

SLIDE 44

Ide Boot Lemma

Boot code terminates and establishes the relation for the initial

states

Establish hypervisor invariant
Machine code verification
Left out

Unwinding Relation

SLIDE 45

Ide User Lemma

No infiltration/no exfiltration for user mode transitions
Independent of handler code, independent of guest code
Property of user mode execution in underlying machine

Unwinding Relation

SLIDE 46

Ide Switch Lemma

No infiltration/no exfiltration for exceptions/interrupts
Independent of handler code, independent of guest code
Property of user mode execution in underlying machine

Unwinding Relation

SLIDE 47

Ide Handler Lemmas

Handlers satisfy their contracts
Dependent on handler code, independent of guest code
Machine code verification

Unwinding Relation

SLIDE 48

Switch Lemma

Suppose again Suppose that and are both in user mode Switch Lemma: if and is in privileged mode then in privileged mode and , and vice versa Exercise 13: Prove the Switch Lemma for one or two cases using again the relational method.

SLIDE 49

Handler Lemma

Suppose again Suppose that and are both in privileged mode Let , if the execution of the handler invoked in ”returns to the state” IIIIII Handler Lemma: if and is in privileged mode then and IIII , and vice versa Exercise 13: Prove the Handler Lemma for irq_entry using the Hoare specification obtained in exercise 7 with some additional reasoning.

SLIDE 50

The relation induces a bijective correspondence over paths in the ideal and real models Exercise 14. Show this. We obtain the following lemma: TEL Preservation Lemma. For each pair of points in the ideal and real models respectively, such that IIIII , if then . Exercise 15. Prove the TEL Preservation Lemma

Temporal Epistemic Justification

SLIDE 51

In particular we can show:

Corollary. A temporal epistemic property is valid in the ideal

model if and only if it is valid in the real model Since we view TEL as a sort of canonical security logic the above corollary serves as the key justification for our approach. For instance, if we can show in the ideal model that no information dependent on any bit in some key K ever leaves guest 0, then the same holds for the real model.

Temporal Epistemic Justification

SLIDE 52

The Missing Link

We glossed over preemption Preemption: An exception handler is interrupted by some other exception (This is avoided in most real kernels AFAIK) We have the following handlers: – irq, scheduling – swi0, resume – swi1, send – exn, exceptions

SLIDE 53

Interrupts/Exceptions

Let if can preempt Who can preempt who? And when? – irq irq? – exn exn? – swi0 swi0? swi1 swi1? – exn swi0? exn swi1? exn irq? – swi0 exn? swi0 swi1? swi0 irq? swi1 exn? Etc? – irq exn? irq swi0? irq swi1? Some combinations can be ruled out using reasonable design goals What about the other cases?

SLIDE 54

Linearisability

Show that: Behaves as if either: Or:

Guest 1 Guest 2 irq swi0 Guest 1 Guest 2 irq swi0 Guest 1 Guest 2 irq swi0

SLIDE 55

How?

Identify linearisation points Points where call ”takes effect” Show that execution steps can be commuted