formal proof of dynamic memory isolation based on mmuseminaire-dga.gforge.inria.fr › 2016 ›...
TRANSCRIPT
Formal Proof of Dynamic MemoryIsolation Based on MMU
David Nowak
CRIStAL, CNRS & Lille 1 University, France
SoSySecSeptember 23, 2016
Joint work withNarjes Jomaa, Gilles Grimaud, and Samuel Hym
1 / 40
Memory isolation between processes
Why? For safety and security
How? By software (kernel of an OS), andby hardware (MMU, kernel mode)
Correct? Ensured by a formal proof
Doable? Yes, by reducing the Trusting Computing Base
2 / 40
Outline
Formally proving memory isolationMicrokernel and MMUMonad and Hoare logicMemory isolation and consistency
A proof-oriented minimal kernel (work in progress)Memory isolation in PipImplementation of Pip
3 / 40
Outline
Formally proving memory isolationMicrokernel and MMUMonad and Hoare logicMemory isolation and consistency
A proof-oriented minimal kernel (work in progress)Memory isolation in PipImplementation of Pip
4 / 40
Reduced TCB with a microkernel
Image from Wikipedia — ©Wooptoo5 / 40
Virtual memory
Image from Wikipedia — ©en:User:Dysprosia
6 / 40
Memory Management Unit (MMU)1 1 0 0 0 10 0 0 0 0 0 0 00 0
0 0 0 0 0 10 0 0 0 0 0 0 01 0
0000 0
0000 0
0000 0
0000 0
1110 1
0000 0
1010 1
0000 0
0000 0
0000 0
0011 1
0100 1
0000 1
1100 1
0010 1
0100 1
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
1100
Incoming
virtual
address
Outgoing
physical
address
n-bit offset
copied directly
from input
to output
2: index into the
page table
Present/absent bit
0
0
0
0
1
0
1
0
0
0
1
1
1
1
1
1kernel bit
Pagetable
É The MMU is a hardwarecomponent.
É It translates virtualaddresses into physicaladdresses.
É It is reconfigured whenthe running processchanges.
⚠ It does not ensure byitself memory isolationbetween processes.
7 / 40
Memory management by the microkernelWe apply our approach on a simple but realisticmemory manager.
0 1 2 3 4
first free page1
3 4 5
used page free page
pointer to the position (as a number)of the next free page
Physicalmemory
The first word of a free memory page is used as apointer to the next free memory page (linked list).
É Allocated page: taken at the beginning of the list
É Freed page: put back at the beginning of the list
8 / 40
Undefined hardware behavior
É Examples:É Accessing a reserved flag in a register
É Using an unspecified assembly instruction
É Accessing an out-of-bound physical address
É Store a value of a certain type and access it as if ithad another type
É An undefined hardware behavior can causevulnerabilities.
É They must be dealt with in formal proof of security.
9 / 40
Outline
Formally proving memory isolationMicrokernel and MMUMonad and Hoare logicMemory isolation and consistency
A proof-oriented minimal kernel (work in progress)Memory isolation in PipImplementation of Pip
10 / 40
Modeling hardware and software
É Gallina, the specification language of the proofassistant Coq, is a purely functional language.
É But, in order model hardware (MMU, kernel mode)and software (microkernel), we need imperativefeatures:É updatable state,
É undefined behaviors, and
É halting.
É We model those imperative features with a monad.
11 / 40
The H monad (1/2)É A term of type M A is called a computation:
It depends on the current state and can change it.
Definition M (A :Type) : Type :=state → result (A ∗ state).
Inductive result (X : Type) : Type :=| val : X → result X| hlt : result X| undef : result X.
É In our model the are three kinds of computations:É A hardware component models the behavior of a
piece of hadware;É an instruction is code for an atomic CPU instruction;É a subroutine is a piece of code that should not be
interrupted.
É M is an abstract datatype.12 / 40
The H monad (2/2)The H monad is equipped with 6 primitives:
(* trivial computation *)Definition ret {A : Type}(a : A) : M A := ...
(* sequence *)Definition bind {A B : Type} (m : M A) (f : A → M B) : M B := ...
(* writing the state *)Definition put (s : state) : M unit := ...
(* reading the state *)Definition get : M state := ...
(* halting *)Definition halt {A : Type} : M A := ...
(* undefined behavior *)Definition undefined {A : Type} : M A := ...
13 / 40
Hoare logic on top of the H monad (1/2)
We define a variant of Hoare logic.
Definition hoare_triple {A : Type}(P : state → Prop) (c : M A) (Q : A → state → Prop) : Prop :=...
Notation "{{ P }} c {{ Q }}" := (hoare_triple P c Q)
“When the precondition P is met, executing thecommand c establishes the postcondition Q.”
É P is a unary predicate on the starting state;
É c is a computation;
É Q is a binary predicate on the returned value andthe resulting state.
14 / 40
Hoare logic on top of the H monad (2/2)
Definition hoare_triple {A : Type}(P : state → Prop) (c : M A) (Q : A → state → Prop) : Prop :=∀ s, P s → match c s with
| val (a, s’) ⇒ Q a s’| hlt ⇒ True| undef ⇒ Falseend.
If a a triple holds then:
É either the postcondition holds orthe computer halts; and
É there is no undefined behavior.
15 / 40
Weakest precondition
Definition wp{A : Type} (Q : A → state → Prop) (c : M A) : state → Prop :=fun s ⇒ match c s with| val (a, s’) ⇒ Q a s’| hlt ⇒ True| undef ⇒ Falseend.
Lemma wp_is_precondition(A : Type) (Q : A → state → Prop) (c : M A) :{{ wp Q c }} c {{ Q }}.
Lemma wp_is_weakest_precondition (A : Type)(P : state → Prop) (Q : A → state → Prop) (c : M A) :{{ P }} c {{ Q }} → ∀ s, P s → (wp Q c) s.
16 / 40
Outline
Formally proving memory isolationMicrokernel and MMUMonad and Hoare logicMemory isolation and consistency
A proof-oriented minimal kernel (work in progress)Memory isolation in PipImplementation of Pip
17 / 40
Memory isolation (1/2)
É not from the point of view of information flow
É but at the lower level of page table management
É A state is isolated iff, for any two distinctprocesses P1 and P2, any page used by P1 is notused by P2.É By pages used by a process Pi, we mean the pages
referenced in its page table ptp(Pi) and the pageptp(Pi) itself.
É By two distinct processes P1 and P2, we meanptp(P1) 6= ptp(P2)
É Our goal is to show that this property is preserved.
18 / 40
Memory isolation (2/2)É We would be satisfied if we could prove the
following triple for each command c:
{{ fun s ⇒ Isolated s }} c {{ fun a s’ ⇒ Isolated s’ }}
É But it is false in general:É The precondition must be strenghened with
consistency properties.
É Those consistency properties must also bepreserved
{{ fun s ⇒ Isolated s ∧ Consistent s }}c{{ fun a s’ ⇒ Isolated s’ ∧ Consistent s’ }}
19 / 40
All marked-free pages should be really free
Without this consistency property, we cannot prove thatthe subroutine for allocating a page preserves isolation.
Counterexample:
0 1 2 3 4
first free page1
3 4 2
used page free page
pointer to the position (as a number)of the next free page
Physicalmemory
a used page is marked as the next
free page of the 4 th free page
An already allocated page could be re-allocated to adifferent process.
20 / 40
No cycle in free-pages list
Without this consistency property, we cannot prove thatthe subroutine for allocating a page preserves isolation.
Counterexample:
0 1 2 3 4
first free page1
3 4 1
used page free page
pointer to the position (as a number)of the next free page
Physicalmemory
the page at position 1 is referenced twicethrough the free-page linked list
The same page could be allocated to differentprocesses.
21 / 40
No duplication in process used pagesÉ For any process, all its used pages must be
referenced only once in its page table.
É Counterexample:0 1
3
3
5
4
first free page1
0 1
3
2
page table
3
5
4currentptp
2
page table
used page
free page pointer to the position (as a number)of the next free page
mapping
Remove pte execution
Physicalmemory
first free page4
1
currentptp
0 1
3
3
5
4
first free page1
0 1
3
2
page table
3
5
4currentptp
2
page table
used page
free page pointer to the position (as a number)of the next free page
mapping
Remove pte execution
Physicalmemory
first free page4
1
currentptp
The subroutine that deallocates a page would onlydeallocate the first one.
É Alternative: Have the subroutine scan for all thereferences of the page to be deallocated
22 / 40
The current page table is of a process
É The number currentptp(s) of the physical pagestoring the page table of the current process mustbe the ptp of one of the runnable processes.
É counterexample: The scheduler would notpreserve isolation when it put the current processat the end of its queue.
23 / 40
Page 0 is never used or marked-free
É 0 is used to mark empty entries in page tables.
É Counterexample: The page 0 would appear to beshared by many processes, thus breaking isolation.
É Other pages must be neither used nor marked-freeÉ to isolate some part of the memory from all
processes
É to store the code of the microkernel and its data
24 / 40
Physical memory large enough
É All physical addresses must exist.
É Counterexample: If a virtual address weremapped to a physical address that does not exist,then it would cause an undefined hardwarebehavior.
⚠ This would be a vulnerability.
25 / 40
Outline
Formally proving memory isolationMicrokernel and MMUMonad and Hoare logicMemory isolation and consistency
A proof-oriented minimal kernel (work in progress)Memory isolation in PipImplementation of Pip
26 / 40
Pip: a minimal kernel
É Here, we verify an implementation, not a model.
source code in Gallina (the language of Coq)
É The TCB is minimal: smaller than an exokernel.É Scheduling and IPC are pushed into user mode.
É Multiplexing is also pushed into user mode.
É Kernel mode is only for:É multi-level MMU configuration,
É catching and forwarding interruptions.
É Pip does not provide any hardware abstraction.
They are provided by a user-level library.
27 / 40
Outline
Formally proving memory isolationMicrokernel and MMUMonad and Hoare logicMemory isolation and consistency
A proof-oriented minimal kernel (work in progress)Memory isolation in PipImplementation of Pip
28 / 40
Partitions tree (1/2)
The memory is organized into hierarchical partitions.
Example
multiplexer
Xen
Linux
p1 p2 p3
Linux
p4 p5
FreeRTOS
t1 t2
29 / 40
Partitions tree (2/2)
Pip does not know what is in each partition.
Proot
P1
P1.1
P1.1.1 P1.1.2 P1.1.3
P1.2
P1.2.1 P1.2.2
P2
P2.1 P2.2
30 / 40
Horizontal isolation and vertical sharing
Proot
P1
P1.1
P1.1.1 P1.1.2 P1.1.3
P1.2
P1.2.1 P1.2.2
P2
P2.1 P2.2
31 / 40
Horizontal isolation
Different children have distinct used pages.
Definition partitionsIsolation s : Prop :=
∀ parent child1 child2 : page,
In parent (getPartitions root s) →
In child1 (getChildren parent s) →
In child2 (getChildren parent s) →
child1 <> child2 →
disjoint (getUsedPages child1 s) (getUsedPages child2 s).
32 / 40
Vertical sharing
All the used pages (configuration tables and mappedpages) of a partition are mapped into its parentpartition.
Definition verticalSharing s : Prop :=
∀ parent child : page,
In parent (getPartitions root s) →
In child (getChildren parent s) →
incl (getUsedPages child s) (getMappedPages parent s).
33 / 40
Outline
Formally proving memory isolationMicrokernel and MMUMonad and Hoare logicMemory isolation and consistency
A proof-oriented minimal kernel (work in progress)Memory isolation in PipImplementation of Pip
34 / 40
Software layers
Hardware
Memory Abstraction Layer Interruption Abstraction Layer
Pip
A sub-partition
Root partition
Another sub-partition
A sub-sub-partitionAnother
sub-sub-partition
Kernel mode
User mode
35 / 40
Example: An MMU with three-level page table
1010101010
111111111111
1213141516171819
222324252627
101010
112021
11
1128112911301131
current pd
3
6
virtual
28 8
physical address
Level 1Level 2 Level 0
Example : MMU with 3 levels of indirections
address index = index = index = offset PAddr =2 1 6 8
4
36 / 40
Pip system calls for memory management
createPartition create a partition
removePartition delete a partition
addVaddr map an address
removeVaddr remove a mapping
pageCountreturn the number of indirections tomap an address
prepareadd the indirections to map an ad-dress
collect delete all empty indirections
37 / 40
Pip system calls for control flow
Pip redirects:É a sofware interrupt to the parent of the caller,
É a hardware interrupt to the root partition.
dispatch give control to another partition
resume return control to another partition
38 / 40
Internal data structureÉ The MMU pages tables (used by Pip and MMU)
É Two shadow MMUs (used only by Pip):É same structure than MMU page tables,
but different data at leafs.
É Shadow 1: flags related to vertical sharing⇒ To ensure horizontal isolation
É Shadow 2: virtual address in the parent of a page⇒ To optimize removeVaddr
É A linked list of pairs of:É physical address of a configuration page, and
É its virtual address in the parent partition.
⇒ To optimize collect39 / 40
Conclusions
É Part 1: A preliminary study on microkernelsÉ A formal model of a hardware architecture
É A formal model of microkernels
É A proof that they ensure memory isolation
É Part 2: Lesson learned: we design the Pip kernelÉ smallest possible TCB:
even multiplexing is pushed outside the kernel.
É Source code in Gallina (the language of Coq)
É Same proof technique as in the preliminary study
40 / 40