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

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

The Goal Hypervisor • Context switch: Fixed round-robin scheduling, assume two guests, statically allocated • Asynchronous message passing through hypercall (swi) • Paravirtualization Dam, Guanciale, Khakpour, Nemati, Schwarz: Formal Verification of Information Flow Security for a Simple ARM-Based Separation Kernel, CCS’13

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

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

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 CPU CPU guests through communication and instruction cycle counting

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, CPU CPU instead of restoring receiver invoke user level handler Restoring receiver: • Once message processing done invoke swi 0 to restore receiver

Ideal Model: Scheduling Scheduler Sender Receiver Scheduling round : Normal sender execution : Message processing : Send hypercall : Resume hypercall : Normal receiver execution

Ideal Model 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 •

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

Ideal Model, Initial State 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 • • These are defined later

Ideal Model, Transitions User step: User step, symmetric case: Many symmetric cases below, mostly omitted

Ideal Model, Transitions 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 Guest switch, no message pending: • cycles for handler • • Similar transition rule for

restoreUser, restoreCtx Some helper functions: • • •

Ideal Model, Transitions Guest switch, receive message: • , : • Entry points for guest 0/guest 1 message handlers •

Ideal Model, Transitions Guest resume: • • + symmetric rule, as always

Ideal Model, Transitions Guest send: • • + symmetric rule • Note: Up to guests to implement flow control

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 of the guests are in privileged state • To prove such properties use a suitable invariant

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 only 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.:

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 output, in the single-sided trace.

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.

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 Hypervisor explicitly represented in memory • Code store in memory

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

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

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

Kernel Region: Stacks Stack roots: – – Size? – – Each stack assigned a memory region with delimiters in: – – – –

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

Kernel Region: Handlers In kernel memory: – – – – – In vector region: – – – –

Initialisation Processor initialised with: – Register 0,…,3, mode, time zeroed – – , ??? – , – – • as processor, but with , • • • • • •

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

Handlers Show irq_entry.pseudo, swi1_entry (mask). (Find them in the course directory) Exercise 6. Give similar pseudo-code implementations of the other 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 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|.

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

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: When is a guest active? – 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