End-to-End Verification of Information-FlowSecurity for C and Assembly Programs

AbstractProtecting the confidentiality of information manipulated bya computing system is one of the most important challengesfacing today’s cybersecurity community. A promising steptoward conquering this challenge is to formally verify thatthe end-to-end behavior of the computing system really sat-isfies various information-flow policies. Unfortunately, be-cause today’s system software still consists of both C andassembly programs, the end-to-end verification necessarilyrequires that we not only prove the security properties of in-dividual components, but also carefully preserve these prop-erties through compilation and cross-language linking.

In this paper, we present a practical, general, and novelmethodology for formally verifying end-to-end security ofa software system that consists of both C and assemblyprograms. We introduce a general definition of observa-tion function that unifies the concepts of policy specifica-tion, state indistinguishability, and whole-execution behav-iors. We show how to use different observation functions fordifferent levels of abstraction, and how to link different se-curity proofs across abstraction levels using a special kindof simulation that is guaranteed to preserve state indistin-guishability. To demonstrate the effectiveness of our newmethodology, we have successfully constructed an end-to-end security proof, fully formalized in the Coq proof as-sistant, of a nontrivial operating system. Some parts of theoperating system are written in C and some are written inassembly; we verify all of the code, regardless of language.

1. IntroductionInformation flow control (IFC) [20, 22] is a form of analysisthat tracks how information propagates through a system.It can be used to state and verify important security-relatedproperties about the system. In this work, we will focuson the read-protection property known as confidentiality orprivacy, using these terms interchangeably with security.

Security is desirable in today’s real-world software.Hackers often exploit software bugs to obtain informationabout protected secrets, such as user passwords or privatekeys. A formally-verified end-to-end security proof canguarantee such exploits will never be successful. There aremany significant roadblocks involved in such a verification,however, and the state-of-the-art is not entirely satisfactory.

Consider the setup of Figure 1, where a large system(e.g., an operating system) consists of many separate func-tions (e.g., system call primitives) written in either C or as-sembly. Each primitive has a verified atomic specification,

x86AssemblyMachine

UserProcess

P1

OSSyscallSpec

CModules

Asm.s

CompCert

CMods.s

AsmSpec

primi5ve&func5oncalls

“implements”

“li>ing”

UserProcess

P2

High-levelinforma0on-flowsecuritypolicyspecifica0on

Low-levelend-to-endsecurityguarantee

Figure 1. An end-to-end software system that consists of both OSmodules (in C and assembly) and user processes.

and there is a verified compiler, such as CompCert [13],that can correctly compile C programs into assembly. Wewish to prove an end-to-end security statement about somecontext program that can call the primitives of the system,which ultimately guarantees that the concrete execution (i.e.,the whole-program assembly execution) behaves securely.There are many challenges involved, such as:

• Policy Specification — How do we specify a clear andprecise security policy, describing how information is al-lowed to flow between various domains? If we expressthe policy in terms of the high-level primitive specifica-tions, then what will this imply for the whole-programassembly execution? We need some way of specifyingpolicies at different levels of abstraction, as well as trans-lating between or linking separate policies.• Propagating Security — It is well known [10, 16] that

simulations and refinements may not propagate securityguarantees. How, then, can we soundly obtain a low-levelguarantee from a high-level security verification?• Cross-Language Linking — Even if we verify security

for all atomic primitive specifications and propagate theproofs to implementations, there still may be incompati-bilities between the proofs for C primitives and those forassembly primitives. For example, a security proof for anassembly primitive might express that some data storedin a particular machine register is not leaked; this prop-erty cannot be directly chained with one for a C primi-tive since the C memory model does not contain machineregisters. We therefore must support linking the specifi-cations of primitives implemented in different languages.

1

In this paper, we present a practical, general, and novelmethodology for formally verifying end-to-end security ofa system like the one shown in Figure 1. First, security isproved for each high-level specification in a standard way,establishing noninterference by showing that a state indistin-guishability relation is invariant across the specification (thisis the standard unwinding condition [6, 7]). Then we applysimulation techniques to automatically obtain a sound secu-rity guarantee for the low-level machine execution, which isexpressed in terms of whole-execution observations. Simu-lations are used both for connecting specifications with im-plementations, as well as for connecting C implementationswith assembly implementations.

The central idea of our methodology is to introduce aflexible definition of observation that unifies the conceptsof policy specification, state indistinguishability, and whole-execution observations. For every level of abstraction, wedefine an observation function that describes which portionsof a program state are observable to which principals. Forexample, an observation function might say that “x is ob-servable to Alice” and “y is observable to Bob”.

Different abstraction levels can use different observationfunctions. We might use one observation function mention-ing machine registers to verify an assembly primitive, and asecond observation function mentioning program variablesto verify a C primitive. These observation functions are thenlinked across abstraction levels via a special kind of simula-tion that preserves state indistinguishability.

We demonstrate the efficacy of our approach by applyingit to the mCertiKOS operating system [8] to prove securitybetween user processes with distinct IDs. mCertiKOS guar-antees full functional correctness of system calls by chainingsimulations across many abstraction layers. We implementour general notion of observation function over the existingsimulation framework, and then verify security of the high-level system call specifications. The result of this effort is anend-to-end security guarantee for the operating system —we specify exactly which portions of high-level state are ob-servable to which processes, and we are guaranteed that thelow-level assembly execution of the whole system is securewith respect to this policy.

Note that, while most of the mCertiKOS code is written inC and compiled into assembly by CompCert, there are someprimitives that must be written directly in assembly. Contextswitch is a classic example of such a primitive. The primaryfunctionality of a context switch involves copying valuesbetween machine registers and kernel objects; hence boththe implementation and specification of the primitive mustrefer to low-level machine state. A key goal and contributionof our security verification is that assembly primitives likecontext switching are fully handled within the framework,and thus do not need to be trusted.

To summarize, the primary contributions of this work are:

• A novel methodology for end-to-end security verifica-tion of complex systems written in different languagesextending across various levels of abstraction.• An end-to-end security proof, completely formalized in

the Coq proof assistant [26], of a nontrivial operatingsystem. Some parts of the operating system are writtenin C and some are written in assembly; we verify all ofthe code, regardless of language.

The rest of this paper is organized as follows. Sec. 2 intro-duces the observation function and shows how to use it forpolicy specification, security proof, and linking. Sec. 3 for-malizes our simulation framework and shows how we provethe end-to-end security theorem. Sec. 4 and 5 describe thesecurity property that we prove over mCertiKOS, highlight-ing the most interesting aspects of our proofs. Finally, wediscuss related work and then conclude.

2. The Observation FunctionThis section will explore our notion of observation, describ-ing how it cleanly unifies various aspects of security verifi-cation. Assume we have some set L of principals or securitydomains that we wish to fully isolate from one another, anda state transition machine M describing the single-step op-erational semantics of execution at a particular level of ab-straction(e.g., in the context of the discussion in Section 1,M could represent single-step execution of atomic specifi-cations, C implementations, or assembly implementations).For any type of observations, we define the observation func-tion of M to be a function mapping a principal and programstate to an observation. For a principal l and state σ, we ex-press the state observation notationally as OM ;l(σ), or justOl(σ) when the machine is obvious from context.

2.1 High-Level Security PoliciesWe use observation functions to express high-level policies.Consider the following C primitive (assume variables areglobal for the purpose of presentation):

void add() a = x + y;b = b + 2;

Clearly, there are flows of information from x and y to a,but no such flows to b. We express these flows in a policyinduced by the observation function. Assume that programstate is represented as a partial variable store, mapping vari-able names to either None if the variable is undefined, orSome v if the variable is defined and contains integer valuev. We will use the notation [x → 7; y → 5] to indicate thevariable store where x maps to Some 7, y maps to Some 5,and all other variables map to None.

We consider the value of a to be observable to Alice(principal A), and the value of b to be observable to Bob(principal B). Since there is information flow from x and yto a in this example, we will also consider the values of x and

2

y to be observable to Alice. Hence we define the observationtype to be partial variable stores (same as program state), andthe observation function is:

OA(s)4= [a → s(a); x → s(x); y → s(y)]

OB(s)4= [b → s(b)]

This observation function induces a policy over an execu-tion, stating that for each principal, the final observation isdependent only upon the contents of the initial observation.This means that Alice can potentially learn anything aboutthe initial values of a, x, and y, but she can learn nothingabout the initial value of b. Similarly, Bob cannot learn any-thing about the initial values of a, x, or y. It should be fairlyobvious that the add primitive is secure with respect to thispolicy; we will discuss how to prove this fact shortly.

Alternative Policies Since the observation function can beanything, we can express various intricate policies. For ex-ample, we might say that Alice can only observe parities:

OA(s)4= [a → s(a)%2; x → s(x)%2; y → s(y)%2]

We also do not require observations to be a portion ofprogram state, so we might express that the average of xand y is observable to Alice:

OA(s)4= (s(x) + s(y))/2

Notice how this kind of observation expresses a form ofdeclassification, saying that the average of the secret valuesin x and y can be declassified to Alice.

One important example of observation is a representationof the standard label lattices and tainting used in many secu-rity frameworks. Security domains are arranged in a latticestructure, and information is only allowed to flow up the lat-tice. Suppose we attach a security label to each piece of datain a program state. We can then define the observation func-tion for a label l to be the portion of state that has a labelat or below l in the lattice. As is standard, we define the se-mantics of a program such as a = x + y to set the resultinglabel of a to be the least upper bound of the labels of x and y.Hence any label that is privileged enough to observe a willalso be able to observe both x and y. We can then prove thatthis semantics is secure with respect to our lattice-aware ob-servation function. In this way, our observation function candirectly model label tainting.

2.2 Security FormulationHigh-Level Security As mentioned in Section 1, we provesecurity at a high abstraction level by using an unwindingcondition. Specifically, for a given principal l, this unwind-ing condition says that state indistinguishability is preservedby each step of an execution, where two states are said to beindistinguishable just when their observations are equal:

σ1l∼ σ2

4= Ol(σ1) = Ol(σ2)

Intuitively, if a step of execution always preserves indistin-guishability, then the final observation of the step can benever be influenced by changing unobservable data in theinitial state (i.e., high-security inputs cannot influence low-security outputs).

More formally, for any principal l and state transitionmachine M with single-step transition semantics TM , wesay that M is secure for l if the following property holdsfor all states σ1, σ2, σ′1, and σ′2:

Ol(σ1) = Ol(σ2) ∧ (σ1, σ′1) ∈ TM ∧ (σ2, σ

′2) ∈ TM

=⇒ Ol(σ′1) = Ol(σ′2)

Consider how this property applies to an atomic specificationof the add primitive above, using the observation functionwhere only the parities of a, x, and y are observable toAlice. Two states are indistinguishable to Alice just whenthe parities of these three variables are the same in the states.Taking the entire primitive as an atomic step, we see thatindistinguishability is indeed preserved since a gets updatedto be the sum of x and y, and addition is homomorphicwith respect to parity. Hence the policy induced by thisobservation function is provably secure.

Low-Level Security Notice that the non-atomic implemen-tation of add also satisfies the above security property. Thatis, if we consider a machine where a single step correspondsto a single line of C code, then both of the two steps in-volved in executing add preserve indistinguishability. How-ever, this is not true in general. Consider an alternative im-plementation of add with the same atomic specification:

void add() a = b;a = x + y;b = b + 2;

The first line of this implementation may not preserveindistinguishability since the unobservable value of b is di-rectly written into a. Nevertheless, the second line immedi-ately overwrites a, reestablishing indistinguishability. Thisexample illustrates that we cannot simply prove the unwind-ing condition for high-level atomic specifications, and ex-pect it to automatically propagate to a non-atomic imple-mentation. We therefore must use a different security defi-nition for low-level implementations.

We will express low-level security as an equality betweenthe whole-execution observations produced by two execu-tions starting from indistinguishable states. There are twochallenges involved in formalizing this definition, relating toindistinguishability and whole-execution observations.

Low-Level Indistinguishability For high-level security,we defined state indistinguishability to be equality of thestate-parameterized observations. This definition may notmake sense at a lower level of abstraction, however. Forexample, suppose we attach security labels to data in a high-level state, for the purpose of specifying a policy based on

3

label tainting (described above). Further suppose that wetreat the labels as purely logical, erasing them when simu-lating the high-level specification with an implementation.This means that the observation function of the implementa-tion machine cannot be dependent on security labels in anyway, and hence equality of observations is not a sensiblenotion of indistinguishability at the implementation level.

We solve this challenge by defining low-level state indis-tinguishability in terms of high-level indistinguishability andsimulation. We say that, given a simulation relation R relat-ing specification to implementation, two low-level states areindistinguishable if there exist two indistinguishable high-level states that are related to the low-level states by R. Thisdefinition will be formalized in Section 3.

Whole-Execution Observations We define the observa-tions made by an entire execution in terms of external events,which are in turn defined by a machine’s observation func-tion. Many traditional automaton formulations define an ex-ternal event as a label on the step relation. Each individualstep of an execution may or may not produce an event, andthe whole-execution observation, or behavior, is the con-catenation of all events produced across the execution.

We use the observation function to model external events.The basic idea is to equate an event being produced by a tran-sition with the state observation changing across the tran-sition. This idea by itself does not work, however. Whenevents are expressed externally on transitions, they defini-tionally enjoy an important monotonicity property: when-ever an event is produced, that event cannot be “undone” or“forgotten” at any future point in the execution. When eventsare expressed as changes in state observation, this propertyis no longer guaranteed.

We therefore explicitly enforce a monotonicity conditionon the observation function of an implementation. We re-quire a partial order to be defined over the observation typeof the low-level semantics, as well as a proof that everystep of the semantics respects this order. For example, ourmCertiKOS proof represents the low-level observation as anoutput buffer (a Coq list). The partial order is defined basedon list prefix, and we prove that execution steps will al-ways respect the order by either leaving the output bufferunchanged or appending to the end of the buffer.

Note that we only enforce observation monotonicity onthe implementation. It is crucial that we do not enforce it onthe high-level specification; doing so would greatly restrictthe high-level policies we could specify, and would poten-tially make the unwinding condition of the high-level secu-rity proof unprovable. Intuitively, a non-monotonic observa-tion function expresses which portions of state could poten-tially influence the observations produced by an execution,while a monotonic observation function expresses which ob-servations the execution has actually produced. We are inter-ested in the former at the specification level, and the latter atthe implementation level.

2.3 Security-Preserving SimulationThe previous discussion described how to use the observa-tion function to express both high-level and low-level secu-rity properties. With some care, we can automatically derivethe low-level security property from a simulation and a proofof the high-level security property.

It is known that, in general, security is not automaticallypreserved across simulation. One potential issue, known asthe refinement paradox [10, 16, 17], is that a nondetermin-istic secure program can be refined into a more determin-istic but insecure program. For example, suppose we havea secret boolean value stored in x, and a program P thatrandomly prints either true or false. P is obviously se-cure since its output has no dependency on the secret value,but P can be refined by an insecure program Q that directlyprints the value of x. We avoid this issue by ruling out Pas a valid secure program: despite being obviously secure,it does not actually satisfy the unwinding condition definedabove and hence is not provably secure in our framework.Note that the seL4 security verification [19] avoids this is-sue in the same way. In that work, the authors frame theirsolution as a restriction that disallows specifications fromexhibiting any domain-visible nondeterminism. Indeed, thiscan be seen clearly by specializing the unwinding conditionabove such that states σ1 and σ2 are identical:

(σ, σ′1) ∈ TM ∧ (σ, σ′2) ∈ TM =⇒ Ol(σ′1) = Ol(σ′2)

The successful security verifications of both seL4 and mCerti-KOS provide solid evidence that this restriction on specifi-cations is not a major hindrance for usability.

Unlike the seL4 verification, however, our frameworkruns into a second issue with regard to preserving securityacross simulation. The issue arises from the fact that bothsimulation relations and observation functions are defined interms of program state, and they are both arbitrarily general.This means that certain simulation relations may, in somesense, behave poorly with respect to the observation func-tion. Figure 2 illustrates an example. Assume program stateat both levels consists of three variables x, y, and z. Theobservation function is the same at both levels: x and y areunobservable while z is observable. Suppose we have a de-terministic specification of the swap primitive saying thatthe values of x and y are swapped, and the value of z is un-changed. Also suppose we have a simulation relation R thatrelates any two states where x and y have the same values,but z may have different values. Using this simulation rela-tion, it is easy to show that the low-level swap implementa-tion simulates the high-level swap specification.

Since the swap specification is deterministic, this exam-ple is unrelated to the issue described above, where domain-visible nondeterminism in the high-level program causestrouble. Nevertheless, this example fails to preserve securityacross simulation: the high-level program clearly preserves

4

42 27 0 swap(x,y)

x y z

z = x; x = y; y = z

R R

42 27 0

27 42 0

27 42 42

x y z

x y z

x y z

Figure 2. Security-Violating Simulation. The shaded part of stateis unobservable, while the unshaded part is observable.

indistinguishability, while the low-level one leaks the secretvalue of x into the observable variable z.

As mentioned above, the root cause of this issue is thatthere is some sort of incompatibility between the simulationrelation and the observation function. In particular, securityis formulated in terms of a state indistinguishability rela-tion, but the simulation relation may fail to preserve indistin-guishability. Indeed, for the example of Figure 2, it is easy todemonstrate two indistinguishable program states that are re-lated by R to two distinguishable ones. Thus our solution tothis issue is to restrict simulations to require that state indis-tinguishability is preserved. More formally, given a principall, in order to show that machine m simulates M under simu-lation relation R, the following property must be proved forall states σ1, σ2 of M , and states s1, s2 of m:

OM ;l(σ1) = OM ;l(σ2) ∧ (σ1, s1) ∈ R ∧ (σ2, s2) ∈ R=⇒ Om;l(s

′1) = Om;l(s

′2)

3. End-to-End Security FormalizationIn this section, we describe the formal proof that some notionof security is preserved across simulation.

Machines with Observations In the following, assume wehave a set L of isolated principals or security domains.

Definition 1 (Machine). A state transition machine M con-sists of the following components (assume all sets may befinite or infinite):

• a type ΣM of program state• a set of initial states IM and final states FM• a transition (step) relation TM of type P(ΣM × ΣM )• a type ΩM of observations• an observation functionOM ;l(σ) of type L×ΣM → ΩM

When the machine M is clear from context, we use thenotation σ 7→ σ′ to mean (σ, σ′) ∈ TM . For multiple steps,we define σ 7→n σ′ in the obvious way, meaning that thereexists a chain of states σ0, ..., σn with σ = σ0, σ′ = σn,and σi 7→ σi+1 for all i ∈ [0, n). We then define σ 7→∗ σ′to mean that there exists some n such that σ 7→n σ′, andσ 7→+ σ′ to mean the same but with a nonzero n.

Notice that our definition is a bit different from mosttraditional definitions of automata, in that we do not defineany explicit notion of actions on transitions. In traditional

definitions, actions are used to represent some combinationof input events, output events, and instructions/commandsto be executed. In our approach, we advocate moving allof these concepts into the program state — this simplifiesthe theory, proofs, and policy specifications. The followingdescribes standard ways to support such concepts withinprogram state:

• input events — We can represent inputs as an infinitestream (oracle) stored within program state. Whenever aprogram needs to read input, it dequeues the head of thisstream.• output events — Outputs can be represented as a finite

list (output buffer). As mentioned in Section 2.2, wewill actually use a more general notion of output events,defined in terms of a monotonic observation function.• instructions — Our model of program state will include

everything relevant for execution. For assembly execu-tion, this includes machine registers and the memorywhere code is stored; thus instructions will be implicitlyrepresented in the program semantics by looking up anddereferencing the value of the instruction pointer regis-ter. For execution in a higher-level language, the statewill include an explicit representation of the code beingexecuted (i.e., we consider the program state to be whatmany other systems would call the whole-machine con-figuration).

Initial States vs Initialized States Throughout our for-malization, we do not require anything regarding initialstates of a machine. The reason is related to how we willactually carry out security and simulation proofs in prac-tice(described with respect to the mCertiKOS security proofin Sections 4 and 5). We never attempt to reason about thetrue initial state of a machine; instead, we assume that someappropriate setup/configuration process brings us from thetrue initial state to some properly initialized state, and thenwe perform all reasoning under the assumption of properinitialization.

Safety and Determinism We will often need to refer totwo additional concepts: safety (relative to an invariant) anddeterminism. In our context, we define these as follows:

Definition 2 (Safety). We say that a machine M is safeunder state predicate I , written M I , when the followingprogress and preservation properties hold:

1.) ∀σ ∈ I − FM . ∃σ′ . σ 7→ σ′

2.) ∀σ, σ′ . σ ∈ I ∧ σ 7→ σ′ =⇒ σ′ ∈ I

Definition 3 (Determinism). We say that a machine M isdeterministic, written ↓ M , when the following propertieshold:

1.) ∀σ, σ′, σ′′ . σ 7→ σ′ ∧ σ 7→ σ′′ =⇒ σ′ = σ′′

2.) ∀σ ∈ FM . ¬∃σ′ . σ 7→ σ′

5

High-Level Security We can now formally define what itmeans for a machine to be secure with respect to its obser-vation function. As discussed in Section 2, we must considertwo definitions of security: a high-level notion based on thestandard unwinding condition, and a low-level notion basedon whole-execution behaviors.

We begin with the high-level definition. As mentionedabove, we will actually only prove the property for programstates that have been properly initialized. Hence safety underthe initialization invariant must be proved prior to security.

Definition 4 (High-Level Security). Machine M is securefor principal l under invariant I , written ∆M I

l , just when:

1.) M I

2.) ∀σ1, σ2 ∈ I, σ′1, σ′2 .Ol(σ1) = Ol(σ2) ∧ σ1 7→ σ′1 ∧ σ2 7→ σ′2

=⇒ Ol(σ′1) = Ol(σ′2)

3.) ∀σ1, σ2 ∈ I .Ol(σ1) = Ol(σ2) =⇒ (σ1 ∈ FM ⇐⇒ σ2 ∈ FM )

The first property of this definition requires that we havealready established safety before considering security. Thesecond property is the unwinding condition restricted toinvariant I . The third property says that the finality of a stateis observable to l (again under invariant I); it is needed toclose a potential termination-related security leak.

Low-Level Security For low-level security, the definition ismore complex. As discussed in Section 2, we first must de-fine whole-execution behaviors with respect to a monotonicobservation function.

Definition 5 (Behavioral State). Given a machine M and apartial order over the observation type ΩM , we say that aprogram state σ is behavioral for principal l, written [M l(σ),if all executions starting from σ respect the partial order; i.e.,the following monotonicity property holds:

∀σ′ . σ 7→∗ σ′ =⇒ Ol(σ) Ol(σ′)

Definition 6 (Behavioral Machine). We say that a machineM is behavioral for principal l, written [M l, when the ma-chine has the following components:

• a partial order over the observation type ΩM• a proof that all states of M are behavioral for l

For presentation purposes, we will give a somewhat infor-mal definition of whole-execution behaviors here. The for-mal Coq definition involves a combination of inductive andcoinductive types (to handle behaviors of both terminatingand non-terminating executions). Note that our definition isquite similar to the one used in CompCert [14], except thatwe use state observations as the basic building block, whileCompCert uses traces, which are input/output events labeledon transitions.

Definition 7 (Whole-Execution Behaviors). Given a ma-chine M with a partial order defined over ΩM , and a stateσ that is behavioral for principal l, we write BM ;l(σ) to rep-resent the (potentially infinite) set of whole-execution be-haviors that can arise from some execution of M startingfrom σ. The behaviors (elements of this set) can be one offour kinds: fault, termination, silent divergence, and reactivedivergence. In the following, variable o ranges over observa-tions and os ranges over infinite streams of observations:

1. Fault(o) ∈ BM ;l(σ) indicates that there is an executionσ 7→∗ σ′ where σ′ is not a final state, σ′ cannot take astep to any state, and o = Ol(σ′).

2. Term(o) ∈ BM ;l(σ) indicates that there is an executionσ 7→∗ σ′ where σ′ is a final state and o = Ol(σ′).

3. Silent(o) ∈ BM ;l(σ) indicates that there is an exe-cution σ 7→∗ σ′ where o = Ol(σ′) and it is possiblefor M to take infinitely many steps from σ′ without anychange in observation (i.e., no new observations are everproduced).

4. React(os) ∈ BM ;l(σ) indicates that there is an infi-nite execution starting from σ that “produces” each ofthe infinitely-many observations of os in order. An ob-servation o is “produced” in an execution when there ex-ists some single step in the execution σ′ 7→ σ′′ witho = Ol(σ′′) and Ol(σ′) 6= Ol(σ′′).

We can now define whole-execution security of a behav-ioral machine as behavioral equality. Note that, in our fi-nal end-to-end security theorem, the low-level executionsin question will be obtained from relating indistinguishablehigh-level states across simulation. We hide this detail fornow inside of an abstract indistinguishability relation ρ, andwill revisit the relation later in this section.

Definition 8 (Low-Level Security). Given a machineM thatis behavioral for principal l, we say that M is behaviorallysecure for l under state relation ρ, written ∇Mρ

l , just when:

∀σ1, σ2 . ρ(σ1, σ2) =⇒ BM ;l(σ1) = BM ;l(σ2)

Simulation We next formalize our definition of simula-tion. It is the same as the standard definition, except for thefollowing aspects:

1. As explained above, we do not require any relationshipsto hold between initial states.

2. As described informally in Section 2, we require simula-tion relations to preserve state indistinguishability.

Definition 9 (Simulation, Attempt 1). Given two machinesM and m, a principal l, and a relation R of type P(ΣM ×Σm), we say thatM simulatesm usingR, writtenM vR;l m,

6

when:

1.) ∀σ, σ′ ∈ ΣM , s ∈ Σm .

σ 7→ σ′ ∧R(σ, s)

=⇒ ∃s′ ∈ Σm . s 7→∗ s′ ∧R(σ′, s′)

2.) ∀σ ∈ ΣM , s ∈ Σm .

σ ∈ FM ∧R(σ, s) =⇒ s ∈ Fm3.) ∀σ1, σ2 ∈ ΣM , s1, s2 ∈ Σm .

OM ;l(σ1) = OM ;l(σ2) ∧R(σ1, s1) ∧R(σ2, s2)

=⇒ Om;l(s1) = Om;l(s2)

The first property is the main simulation, the second relatesfinal states, and the third preserves indistinguishability. Notethat, for presentation purposes, we omit details here regard-ing the well-known “infinite stuttering” problem for simula-tions (described, for example, in [14]). Our Coq definition ofsimulation includes a well-founded order that prevents infi-nite stuttering. Also notice that, contrary to our discussionearlier, we do not define simulations to be relative to an in-variant. It would be completely reasonable to require safetyof the higher-level machine under some invariant, but thisactually ends up being redundant. Since R is an arbitrary re-lation, we can simply embed an invariant requirement withinR. In other words, one should think of R(σ, s) as saying notonly that σ and s are related, but also that σ satisfies an ap-propriate invariant.

It is easy to show that simulations are reflexive and tran-sitive.

Lemma 1 (Reflexivity).

∀M . M vId M

Lemma 2 (Transitivity).

∀M1,M2,M3, R1, R2 .

M1 vR1;l M2 ∧M2 vR2;l M3

=⇒M1 vR1R2;l M3

Furthermore, we can easily show that our high-level securitydefinition above is a particularly strong bisimulation for safemachines, where a single step is always simulated by a singlestep:

Definition 10 (Bisimulation). Given principal l, we say thatM bisimulates m using R, written M ≡R;l m just whenM vR;l m and m vR−1;l M .

Definition 11 (Invariant-Aware Indistinguishability).

ΘIl (σ1, σ2)

4= σ1 ∈ I ∧ σ2 ∈ I ∧ Ol(σ1) = Ol(σ2)

Lemma 3 (High-Level Security Bisimulation).

∀M, I, l . ∆M Il =⇒M ≡ΘI

l ;l M

End-to-End Security We are almost ready to formalize theend-to-end security guarantee. First, we will need to estab-lish some lemmas regarding behaviors and how they are pre-served across simulations. For example, if we have a sim-ulation from M to m, we ideally would like to prove thatthe possible behaviors of M from some state σ are a subsetof the behaviors of m from a related state s. There is onesignificant technical detail that needs to be addressed: be-haviors are defined in terms of observations, and the typesof observations of two different machines may be different.Hence we cannot compare behavior sets directly using stan-dard subset or set equality. We will therefore introduce asecond relation into our simulations, relating observationsof one machine to observations of the other.

Definition 12 (Simulation, Attempt 2). Given two machinesM , m, a principal l, a relation R between states of M andstates ofm, and a relation R between observations ofM andobservations of m, we say that there is a simulation from Mto m using R and R, written M vR;R;l m, when:

1.) ∀σ, σ′ ∈ ΣM , s ∈ Σm .

σ 7→ σ′ ∧R(σ, s)

=⇒ ∃s′ ∈ Σm . s 7→+ s′ ∧R(σ′, s′)

2.) ∀σ ∈ ΣM , s ∈ Σm .

σ ∈ FM ∧R(σ, s)

=⇒ s ∈ Fm3.) ∀σ ∈ ΣM , s ∈ Σm .

R(σ, s) =⇒ R(OM ;l(σ),Om;l(s))

4.) ∀σ1, σ2 ∈ ΣM , s1, s2 ∈ Σm .

OM ;l(σ1) = OM ;l(σ2)

∧ R(OM ;l(σ1),Om;l(s1))

∧ R(OM ;l(σ2),Om;l(s2))

=⇒ Om;l(s1) = Om;l(s2)

The first two properties are the same as the previous def-inition, while the previous indistinguishability preservationproperty has now been split into two new properties. It turnsout that we can simplify this definition significantly. Thefourth property above actually just states that R always re-lates equal inputs to equal outputs; i.e., R is functional. Thisleads us to our final, simpler definition for simulation:

Definition 13 (Simulation). Given two machines M , m, aprincipal l, a relation R between states of M and states ofm, and a function R from observations ofM to observationsof m, we say that there is a simulation from M to m using

7

R and R, written M vR;R;l m, when:

1.) ∀σ, σ′ ∈ ΣM , s ∈ Σm .

σ 7→ σ′ ∧R(σ, s)

=⇒ ∃s′ ∈ Σm . s 7→+ s′ ∧R(σ′, s′)

2.) ∀σ ∈ ΣM , s ∈ Σm .

σ ∈ FM ∧R(σ, s)

=⇒ s ∈ Fm3.) ∀σ ∈ ΣM , s ∈ Σm .

R(σ, s) =⇒ R(OM ;l(σ)) = Om;l(s)

Definition 14 (Bisimulation). Given two machines M , m,a principal l, a relation R between states of M and statesof m, and an invertible function R from observations of Mto observations of m, we say that there is a bisimulationfrom M to m using R and R, written M ≡R;R;l m, whenM vR;R;l m and m vR−1;R−1;l M .

In the following, we will overload the R function toapply to behaviors in the obvious way (e.g., R(Term(o)) =Term(R(o))). Given a simulation M vR;R;l m, with bothM and m behavioral for l, we define subset and equalityrelations between sets of behaviors by applying R to everyelement of the first set:

Definition 15 (Behavior Subset).

BM ;l(σ) vR Bm;l(s)4=

∀b . b ∈ BM ;l(σ) =⇒ R(b) ∈ Bm;l(s)

Definition 16 (Behavior Equality).

BM ;l(σ) ≡R Bm;l(s)4=

∀b . b ∈ BM ;l(σ) ⇐⇒ R(b) ∈ Bm;l(s)

Note that this equality relation is asymmetric since R canonly apply to behaviors in the first set, and R is not guaran-teed to have an inverse.

We now state the relevant lemmas relating behaviors andsimulations, omitting proofs here. For the most part, theproofs are reasonably straightforward, requiring some stan-dard case analyses, as well as applications of induction andcoinduction hypotheses.

Lemma 4 (Behavior Exists).

∀M, l, σ . [M l(σ) =⇒ BM ;l(σ) 6= ∅

Lemma 5 (Behavior Determinism).

∀M, l, σ . [M l(σ)∧ ↓M =⇒ |BM ;l(σ)| = 1

Lemma 6 (Simulation Implies Behavior Subset).

∀M,m, I,R, R, l, σ, s .

[M l(σ) ∧ [ml(s)

∧M I ∧M vR;R;l m ∧ σ ∈ I ∧R(σ, s)

=⇒ BM ;l(σ) vR Bm;l(s)

Lemma 7 (Bisimulation Implies Behavior Equality).

∀M,m,R, R, l, σ, s .

[M l(σ) ∧ [ml(s)

∧M ≡R;R;l m ∧R(σ, s)

=⇒ BM ;l(σ) ≡R Bm;l(s)

Finally, we state and prove the end-to-end security theorem.We assume there is a specification machine M that is securefor principal l under invariant I , a deterministic implemen-tation machine m that is behavioral for l, and a simulationfrom M to m. The theorem then says that if we take anytwo indistinguishable states σ1, σ2 of M (which satisfy I),and relate them down to two states s1, s2 of m, then thewhole-execution behaviors of s1 and s2 are equal. Note thatwe require the implementation to be deterministic — this isa reasonable requirement since the implementation is sup-posed to represent the real machine execution, and real ma-chines are deterministic. Crucially, the specification may stillbe nondeterministic.

Since the statement of this theorem is a bit unwieldy, wewill reformulate it below to directly express that high-levelsecurity implies low-level security.

Theorem 1 (End-to-End Security).

∀M,m, I,R, R, l, σ1, σ2, s1, s2 .

∆M Il ∧ [ml∧ ↓ m ∧M vR;R;l m

∧ σ1 ∈ I ∧ σ2 ∈ I ∧ OM ;l(σ1) = OM ;l(σ2)

∧R(σ1, s1) ∧R(σ2, s2)

=⇒ Bm;l(s1) = Bm;l(s2)

Proof. We prove this theorem by defining a new machineN in between M and m, and proving simulations fromM to N and from N to m. N will mimic M in terms ofprogram states and transitions, while it will mimic m interms of observations. More formally, we define N to havethe following components:

• program state ΣM• initial states IM• final states FM• transition relation TM• observation type Ωm

• observation function ON ;l(σ)4= R(OM ;l(σ))

First, we establish the simulation M vId;R;l N . Refer-ring to Definition 13, the first two properties hold triviallysince N has the same transition relation and final state setas M . The third property reduces to exactly our definition ofON ;l(−) given above.

Next, we establish the simulation N vR;Id;l m.The first two properties of Definition 13 are exactly thesame as the first two properties of the provided simulation

8

M vR;R;l m, and thus they hold. For the third prop-erty, assuming we know R(σ, s), we have Id(ON ;l(σ)) =ON ;l(σ) = R(OM ;l(σ)) = Om;l(s), where the final equal-ity comes from the third property of the provided simulation.

The next step is to relate the behaviors of N with thoseof m. In order to do this, we first must show that N haswell-defined behaviors for executions starting from σ1 or σ2.In other words, we must prove [N l(σ1) and [N l(σ2). Wewill focus on the proof for σ1; the other proof is analogous.We use the same partial order as provided by the assump-tion [ml. Consider any execution σ1 7→∗ σ′1 in N . SinceR(σ1, s1), we can use the simulation N vR;Id;l m estab-lished above, yielding an execution s1 7→∗ s′1, for somes′1 (technically, the simulation property only applies to sin-gle steps in the higher machine; however, it can easily beextended to multiple steps through induction on the step re-lation). Additionally, we have R(σ1, s1) and R(σ′1, s

′1), im-

plying by the third property of simulation that ON ;l(σ1) =Om;l(s1) and ON ;l(σ

′1) = Om;l(s

′1). Since m is behavioral,

we also have Om;l(s1) Om;l(s′1). Hence we conclude

ON ;l(σ1) ON ;l(σ′1), as desired.

We now know that [N l(σ1) and [N l(σ2). Notice thatwhen R is Id , our definitions of behavior subset and equal-ity (Definitions 15 and 16) reduce to standard subset andset equality. Therefore, applying Lemma 6 to the establishedsimulationN vR;Id;l m tells us that BN ;l(σ1) ⊆ Bm;l(s1)and BN ;l(σ2) ⊆ Bm;l(s2) (note that the safety precondi-tion of Lemma 6 holds because M and N have the samestate type and transition relation). Furthermore, since m isdeterministic, Lemma 5 gives us |Bm;l(s1)| = |Bm;l(s2)| =1. Since Lemma 4 guarantees that neither BN ;l(σ1) norBN ;l(σ2) is empty, we conclude that BN ;l(σ1) = Bm;l(s1)and BN ;l(σ2) = Bm;l(s2).

To complete the proof, we now just need to show thatBN ;l(σ1) = BN ;l(σ2). Recall Lemma 3, which expressesa security proof as a bisimulation. Extending that lemmawith an observation relation of Id , we have the bisimula-tion M ≡ΘI

l ;Id;l M . We would like to apply Lemma 7,but we first need to convert this bisimulation into one onN , since M is not behavioral. Since M and N share pro-gram state type, final states, and transition relation, it isnot difficult to see that the first two required properties ofthe simulation N vΘI

l ;Id;l N hold. If we can establishthe third property, then we will obtain the desired bisimula-tion N ≡ΘI

l ;Id;l N since Id is obviously invertible andΘIl is symmetric. The third property requires us to prove

that ΘIl (σ1, σ2) =⇒ ON ;l(σ1) = ON ;l(σ2). By defini-

tion, ΘIl (σ1, σ2) implies that OM ;l(σ1) = OM ;l(σ2). No-

tice that ON ;l(σ1) = ON ;l(σ2) following from this fact isexactly the indistinguishability preservation property we dis-cussed earlier. Indeed, utilizing the third property of the es-tablished simulation M vId;R;l N , we have ON ;l(σ1) =R(OM ;l(σ1)) = R(OM ;l(σ2)) = ON ;l(σ2).

Finally, we instantiate Lemma 7 with both machines be-ing N . Notice that we technically need to establish the pre-condition of ΘI

l (σ1, σ2) before we can apply the lemma.By definition, this reduces to σ1 ∈ I ∧ σ2 ∈ I ∧ON ;l(σ1) = ON ;l(σ2). The first two facts hold by assump-tion, and the third one follows from OM ;l(σ1) = OM ;l(σ2)by exactly the same reasoning we just used above. Now, ap-plying Lemma 7 yields the conclusionBN ;l(σ1) ≡Id BN ;l(σ2).As mentioned earlier, behavior equality reduces to stan-dard set equality when R is Id , and so we get the desiredBN ;l(σ1) = BN ;l(σ2), completing the proof.

To reformulate the theorem, we wrap up many of thepreconditions into a low-level indistinguishability relation.The relation is parameterized by a high-level machine, aprincipal, a high-level invariant, and a simulation relation. Itsays that two low-level states are indistinguishable if we canfind two indistinguishable high-level states that are relatedvia the simulation relation.

Definition 17 (Low-Level Indistinguishability).

φ(M, l, I, R)4=

λs1, s2 . ∃σ1, σ2 ∈ I .OM ;l(σ1) = OM ;l(σ2) ∧R(σ1, s1) ∧R(σ2, s2)

End-to-end security is now reformulated to explicitly saythat high-level security implies low-level security.

Corollary 1 (End-to-End Security, Reformulated).

∀M,m, I,R, R, l .

[ml∧ ↓ m ∧M vR;R;l m

=⇒(

∆M Il =⇒ ∇mφ(M,l,I,R)

l

)4. Security Definition of mCertiKOSWe will now discuss how we applied our methodology toprove an end-to-end security guarantee between separateprocesses running on top of the mCertiKOS kernel [8]. Dur-ing the proof effort, we had to make some changes to theoperating system to close potential security holes. We referto our secure variant of the kernel as mCertiKOS-secure.

4.1 mCertiKOS OverviewThe starting point for our proof effort was the basic versionof the mCertiKOS kernel, described in detail in Section 7of [8]. We will give an overview of the kernel here. It is com-posed of 32 abstraction layers, which incrementally build upthe concepts of physical memory management, virtual mem-ory management, kernel-level processes, and user-level pro-cesses. Each layer L consists of the following components:

• a type ΣL of program state, separated into machine reg-isters, concrete memory, and abstract data of type DL

• a set of initial states IL and final states FL

9

• a set of primitives PL implemented by the layer, includ-ing two special primitives called load and store• for each p ∈ PL, a specification of type P(ΣL × ΣL)

• (if L is not the bottom layer) for each p ∈ PL, an im-plementation written in either LAsm(L′) or ClightX(L′)(defined below), where L′ is the layer below L

The top layer is called TSysCall, and the bottom is calledMBoot. MBoot describes execution over the model of the ac-tual hardware; the specifications of its primitives are taken asaxioms. Implementations of primitives in all layers are writ-ten in either a layer-parameterized variant of x86 assemblyor a layer-parameterized variant of C.

The assembly language, called LAsm(L), is a direct ex-tension of CompCert’s [13] model of x86 assembly that al-lows primitives of layer L to be called atomically. Whenan atomic primitive call occurs, the semantics consults thatprimitive’s specification to take a step. Note that primitivespecifications are the only part of the language semanticsthat utilize or alter the abstract data component of programstate.

The C variant, called ClightX(L), is a direct extensionof CompCert’s Clight language [2] (which is a slightly-simplified version of C). Like LAsm(L), the semantics isextended with the ability to call the primitives of L atom-ically. ClightX(L) programs can be compiled to LAsm(L)in a verified-correct fashion using the CompCertX com-piler [8], which is an extension of CompCertthat supportsper-function compilation.

Each layer L induces a machine ML of the kind de-scribed in Section 3. The state type and initial/final statesof ML come directly from L. The transition relation of typeP(ΣL ×ΣL) is the operational semantics of LAsm(L). Themachine’s observation function will be discussed later, asit is an extension that we implemented over the existingmCertiKOS specifically for the security proof.

Load/Store Primitives Before continuing, there is onesomewhat technical detail regarding the LAsm(L) seman-tics that requires explanation. While most layer primitivesare called in LAsm(L) using the call syntax, the specialload and store primitives work differently. Whenever anassembly command dereferences an address, the LAsm(L)semantics consults the load/store primitives to decide howthe dereference is actually resolved. This allows TSysCall tointerpret addresses as virtual, while MBoot interprets themas physical. As an example, consider the following snippetof assembly code, taken from the implementation of the pagefault handler TSysCall primitive:

call trap_getmovl %eax, 0(%esp)call ptfault_resv

The layer below TSysCall is called TDispatch, and thus thiscode is written in the language LAsm(TDispatch). The firstand third lines call primitives of TDispatch atomically. The

ML

ML’

spawn() yield()

ClightX(L’)

CompCertX

LAsm(L’) LAsm(L’)

Figure 3. Simulation between adjacent layers. Layer L containsprimitives spawn and yield, with the former implemented inClightX(L′) and the latter implemented in LAsm(L′).

second line ostensibly writes the value of %eax into thememory location pointed to by %esp. The actual semanticsof this line, however, will call TDispatch’s store primi-tive with the value of %eax and the address in %esp as pa-rameters. This primitive will translate the destination addressfrom virtual to physical by walking through the page tablesof the currently-executing process.

Layer Simulation Figure 3 illustrates how machines in-duced by two consecutive layers are connected via simula-tion. Each step of machine ML is either a standard assemblycommand or an atomic primitive call. Steps of the formercategory are simulated inML′ by exactly the same assemblycommand. Steps of the latter are simulated using the prim-itive’s implementation, supplied by layer L. If the primitiveis implemented in LAsm(L′), then the simulation directlyuses the semantics of this implementation. If the primitive isimplemented in ClightX(L′), then CompCertX is used firstto compile the implementation into LAsm(L′). CompCertXis verified to provide a simulation from the ClightX(L′) ex-ecution to the corresponding LAsm(L′) execution, so thissimulation is chained appropriatelyto get an end-to-end sim-ulation from the ML execution to the ML′ execution.

As a general convention, the simulation relation betweenconsecutive machines only represents an abstraction of someconcrete memory into abstract data. In other words, someportion of memory in the lower-level machine is related tosome portion of abstract data in the higher-level machine. Inthis way, as we move up the layers, we have some monotonicnotion of abstraction from concrete memory to abstract data.For all intents and purposes, concrete memory has been fullyabstracted away at the TSysCall level — user processes haveno mechanism for interacting with the memory directly.

Once every pair of consecutive machines is connectedwith a simulation, they are combined to obtain a simulationfrom TSysCall to MBoot. Since the TSysCall layer providesmCertiKOS’s system calls as primitives, user process execu-tion is specified at the TSysCall level. To get a better senseof user process execution, we will now give an overview ofthe TSysCall program state and primitives.

TSysCall State The TSysCall abstract data is a Coq recordconsisting of 32 separate fields. We will list here those fields

10

that will be relevant to our discussion. In the following,whenever a field name has a subscript of i, this indicates thatthe field is a finite map from process ID to some data type.

• outi — The output buffer for process i, represented as alist of 32-bit integers.• ikern — A global boolean flag stating whether the

machine is currently in kernel mode or user mode.• HP — A global, flat view of the user-space memory

heap(physical addresses between 230 and 3 × 230). Apage is defined as the 4096-byte sequence starting froma physical address that is divisible by 4096.• AT — A global allocation table, represented as a bitmap

indicating which pages in the global heap have beenallocated. Element n of this map corresponds to the 4096-byte page starting from physical address 4096n.• pgmapi — A representation of the two-level page map

for process i. The page map translates a virtual addressbetween 0 and 232 − 1 into a physical address.• containeri — A representation of process i that main-

tains information regarding spawned status, children, par-ents, and resource quota. A container is itself a Coqrecord containing the following fields:

used — A boolean indicating whether process i hasbeen spawned.

parent — The ID of the parent of process i(or 0 forroot process 0).

nchildren — The number of children of process i.

quota — The maximum number of pages that pro-cess i is allowed to dynamically allocate.

usage — The current number of pages that processi has dynamically allocated.

• ctxti — The saved register context of process i, con-taining the register values that will need to be restoredthe next time process i is scheduled.• cid — The currently-running process ID.• rdyQ — An ordered list of process IDs that are ready to

be scheduled.

TSysCall Primitives There are 9 primitives in the TSysCalllayer, including the load/store primitives. The primitivespecifications operate over both the TSysCall abstract dataand the machine registers. Note that they do not interact withconcrete memory since all relevant portions of memory havealready been abstracted into the TSysCall abstract data.

• Initialization — proc init sets up the various kernelobjects to get everything into a working state. We neverattempt to reason about anything that happens prior to ini-tialization; it is assumed that the bootloader will alwayscall proc init appropriately.

• Load/Store — Since paging is enabled at the TSysCalllevel, the load and store primitives walk the page ta-bles of the currently-running process to translate virtualaddresses into physical. If no physical address is founddue to no page being mapped, then the faulting virtualaddress is written into the CR2 control register, the cur-rent register context is saved, and the instruction pointerregister is updated to point to the entry of the page faulthandler primitive.• Page Fault — pgf handler is called immediately after

one of the load/store primitives fails to resolve a virtualaddress. It reads the faulting virtual address from the CR2register, allocates one or two new pages as appropriate,increases the current process’s page usage, and plugs thepage(s) into the page table (two pages may need to beallocated because the machine uses a two-level page tablestructure). It then restores the register context that wassaved when the load/store primitive faulted. If the currentprocess does not have enough available quota to allocatethe required pages, then the instruction pointer registeris updated to point to the entry of the yield primitive(see below). This means that the process will end uppage faulting infinitely, but it will not interfere with theexecution of other processes.• Get Quota — get quota returns the amount of remain-

ing quota for the currently-executing process. This isuseful to provide as a system call since it gives processesthe power to divide their quota among children in anyway they wish.• Spawn Process — proc create attempts to spawn a

new child process. It takes a quota as a parameter, spec-ifying the maximum number of pages the child processwill be allowed to allocate. This quota allowance is takenfrom the current process’s available quota.• Yield — sys yield performs the first step for yield-

ing to the next process in the ready queue. It enters ker-nel mode, disables paging, saves the current registers,and changes the currently-running process ID to the headof the ready queue. It then context switches by restor-ing the newly-running process’s registers. The newly-restored instruction pointer register is guaranteed (provedas an invariant) to point to the function entry of thestart user primitive.• Start User — start user performs the simple sec-

ond step of yielding. It enables paging for the currently-running process and exits kernel mode. The entire func-tionality of yielding must be split into two primitives(sys yield and start user) because context switch-ing requires writing to the instruction pointer register, andtherefore only makes sense when it is the final operationperformed by a primitive. Hence yielding is split into oneprimitive that ends with a context switch, and a secondprimitive that returns to user mode.

11

• Output — print appends its parameter to the currently-running process’s output buffer. Note that output buffersexist in all layers’ abstract data, including MBoot. Hencethey are never actually implemented in memory; instead,they are assumed to be an accurate representation of someexternal devices (e.g., monitors).

4.2 Security OverviewWe have now provided enough background on mCertiKOSto begin discussing the security verification. We considereach process ID to be a distinct principal or security domain.The high-level security policy expresses which portions ofTSysCall state are observable to which principals. The secu-rity verification then guarantees complete isolation betweenall principals: no process’s observable state can ever be in-fluenced by the execution of another process.

High-Level Semantics As explained in Sections 2 and 3,high-level security is proved by showing that every step ofexecution preserves an indistinguishability relation sayingthat the observable portions of two states are equal. In themCertiKOS context, however, this property will not holdover the TSysCall machine.

To see this, consider any process ID (i.e., principal) l,which we call the “observer process”. For any TSysCall stateσ, we say that σ is “active” if cid(σ) = l, and “inactive”otherwise. Now consider whether the values in machineregisters should be observable to l. Clearly, if l is executing,then it can read and write registers however it wishes, so theregisters must be considered observable. On the other hand,if some other process l′ is executing, then the registers mustbe unobservable to l if we hope to prove that l and l′ areisolated. We conclude that registers should be observable tol only in active states.

What happens, then, if we attempt to prove that indistin-guishability is preserved when starting from inactive indis-tinguishable states? Since the states are inactive, the regis-ters are unobservable, and so the instruction pointer registerin particular may have a completely different value in thetwo states. This means that the indistinguishable states mayexecute different instructions. If one state executes the yieldprimitive while the other does not, we may end up in a situ-ation where one resulting state is active but the other is not;clearly, such states cannot be indistinguishable since the reg-isters are observable in one state but not in the other. Thusindistinguishability may not be preserved in this situation.

The fundamental issue here is that, in order to prove thatl cannot be influenced by l′, we must show that l has noknowledge that l′ is even executing. We accomplish thisby defining a higher-level machine above the TSysCall ma-chine, where every state is active. We call this the TSysCall-local machine — it is parameterized by principal l, and itrepresents l’s local view of the TSysCall machine.

Figure 4 gives a visual representation of how the se-mantics of TSysCall-local is defined. The solid arrows are

active state inactive state

Figure 4. The TSysCall-local semantics, defined by taking bigsteps over the inactive parts of the TSysCall semantics.

transitions of the TSysCall machine, white circles are ac-tive TSysCall states, and shaded circles are inactive states.The TSysCall-local semantics is then obtained by combin-ing all of the solid arrows connecting active states with allof the dotted arrows. Note that in the TSysCall layer, theyield primitive is the only way that a state can change fromactive to inactive, or vice-versa. Thus one can think of theTSysCall-local machine as a version of the TSysCall ma-chine where the yield semantics takes a big step, immedi-ately returning to the process that invoked the yield.

Given all of this discussion, our high-level security prop-erty is proved over the TSysCall-local machine, for anychoice of observer principal l. We easily prove simulationfrom TSysCall-local to TSysCall, so this strategy fits cleanlyinto our simulation framework.

Observation Function We now define the high-level ob-servation function used in our verification, which maps eachprincipal and state to an observation. For a given process IDl, the state observation of σ is defined as follows:

• Registers — All registers are observable if σ is active. Noregisters are observable if σ is inactive.• Output — The output buffer of l is observable.• Virtual Address Space — We can dereference any virtual

address by walking through l’s page tables. This willresult in a value if the address is actually mapped, orno value otherwise. This function from virtual addressesto option values is observable. Importantly, the physicaladdress at which a value resides is never observable.• Spawned — The spawned status of l is observable.• Quota — The remaining quota (max quota minus usage)

of l is observable.• Children — The number of children of l is observable.• Active — It is observable whether cid(σ) is equal to l.• Reg Ctxt — The saved register context of l is observable.

Notice how the virtual address space component of observa-tion exploits the generality of our framework. It is not simplya portion of program state, as it refers to both the pgmap andHP components of state in a nontrivial way.

5. Security Verification of mCertiKOSNow that we have presented all of the relevant setup, we candiscuss the details of the mCertiKOS proof effort. The finaltheorem is the end-to-end security theorem of Section 3,using the simulation from TSysCall-local to MBoot, the

12

Load 147

Store 258

Page Fault 188

Get Quota 10

Spawn 30

Yield 960

Start User 11

Print 17

Total 1621

Primitives 1621

Glue 853

Framework 2192

Invariants 1619

Total 6285

Security Proof (LOC)

Security of Primitives (LOC)

Figure 5. Approximate Coq LOC of proof effort.

high-level observation function described in Section 4, anda low-level observation function that simply projects theoutput buffer. Thus the following facts must be established:

1. MBoot is deterministic.

2. MBoot is behavioral for any principal.

3. The simulation relation from TSysCall-local to MBootpreserves indistinguishability.

4. TSysCall-local satisfies the high-level security property.

Determinism of the MBoot machine is already proved inmCertiKOS. Behaviorality of MBoot is easily establishedby defining a partial order over output buffers based onlist prefix, and showing that every step of MBoot eitherleaves the buffer untouched or appends to the end of thebuffer. To prove that the simulation preserves indistinguisha-bility, we first prove that simulation between consecutivelayers in mCertiKOS always preserves the output buffer. In-distinguishability preservation then follows as a corollary,since the high-level observation function includes the outputbuffer as a component.

The largest part of the proof effort is, unsurprisingly,establishing the high-level unwinding condition over theTSysCall-local semantics. The proof is done by showingthat each primitive of the TSysCall layer preserves indistin-guishability. The yield primitive requires some special treat-ment since the TSysCall-local semantics treats it differently;this will be discussed later in this section.

Figure 5 gives the number of lines of Coq definitionsand proof scripts required for the proof effort. The entireeffort is broken down into security proofs for primitives,glue code to interface the primitive proofs with the LAsm(L)semantics, definitions and proofs of the framework describedin Section 3, and proofs of new state invariants that wereestablished. We will now discuss the most interesting aspectsand difficulties of the TSysCall-local security proof.

State Invariants While mCertiKOS already verifies anumber of useful state invariants, some new ones are neededfor our security proofs. The new invariants established overTSysCall-local execution are:

1. In all saved register contexts, the instruction pointer reg-ister points to the entry of the start user primitive.

2. No page is mapped more than once in the page tables.

3. We are always either in user mode, or we are in kernelmode and the instruction pointer register points to theentry of the start user primitive (meaning that wejust yielded and are going to enter user mode in one step).

4. The sum of the available quotas (max quota minus usage)of all spawned processes is less than or equal to thenumber of unallocated pages in the heap.

Additionally, for a given observer principal l, we assumethe invariant that process l has been spawned. Anythingoccurring before the spawning of l is considered part of theinitialization/configuration phase; we are not interested inreasoning about the security of process l before the processeven exists in the system.

Security of Load/Store Primitives The main task for prov-ing security of the 100+ assembly commands of LAsm(TSys-Call) is to show that the TSysCall layer’s load/store prim-itives preserve indistinguishability. This requires showingthat equality of virtual address spaces is preserved. Reason-ing about virtual address spaces can get quite hairy since wealways have to consider walking through the page tables,with the possiblity of faulting at either of the two levels.

To better understand the intricacies of this proof, considerthe following situation. Suppose we have two states σ1 andσ2 with equal mappings of virtual addresses to option values(where no value indicates a page fault). Suppose we arewriting to some virtual address v in two executions on thesestates. Consider what happens if there exists some othervirtual address v′ such that v and v′ map to the same physicalpage in the first execution, but map to different physicalpages in the second. It is still possible for σ1 and σ2 tohave identical views of their virtual address space, as longas the two different physical pages in the second executioncontain the same values everywhere. However, writing to vwill change the observable view of v′ in the first execution,but not in the second. Hence, in this situation, it is possiblefor the store primitive to break indistinguishability.

We encountered this exact counterexample while at-tempting to prove security, and we resolved the problemby establishing the second state invariant mentioned above.The invariant guarantees that the virtual addresses v and v′

will never be able to map to the same physical page.

Security of Process Spawning The proc create prim-itive was the only one whose security depended on makinga major change to the existing mCertiKOS. When the inse-cure version of mCertiKOS creates a new child process, itchooses the lowest process ID that is not currently in use.The system call returns this ID to the user. Hence the IDcan potentially leak information between different users. Forexample, suppose Alice spawns a child process and storesits ID into variable x. She then calls yield. When execu-tion eventually returns back to her, she again spawns a childand stores the ID into variable y. Since mCertiKOS always

13

chooses the lowest available process ID, the value of y−x−1is exactly the number of times that other processes spawnedchildren while Alice was yielded. In some contexts, this in-formation leak could allow for direct communication be-tween two different processes.

To close this information channel, we had to revamp theway process IDs are chosen in mCertiKOS-secure. The newID system works as follows. We define a global parametermc limiting the number of children any process is allowed tospawn. Suppose a process with ID i and c children (c < mc)spawns a new child. Then the child’s ID will always bei∗mc+c+1. This formula guarantees that different processescan never interfere with each other via child ID: if i 6= j,then the set of possible child IDs for process i is completelydisjoint from the set of possible child IDs for process j.

Security of Page Fault There are two different interestingaspects of page fault security. The first is that it is a perfectexample of a primitive whose implementation does not pre-serve indistinguishability with each individual step. When apage fault occurs, either one or two new pages must be al-located from the global heap. Because all user processes usethe same global heap for allocation, and mCertiKOS alwaysallocates the first available page, the physical address of anallocated page can potentially leak information between pro-cesses. The page fault handler, however, must make use ofthe physical address of a newly-allocated page when insert-ing a new virtual address mapping into the page table. There-fore, at some point during the actual (non-atomic) execu-tion of the page fault handler, an observable register containsthe insecure physical page address. Since we prove that theprimitive’s atomic specification is secure, however, we knowthat the insecure value must be overwritten by the time theprimitive finishes executing.

The second interesting aspect of the page fault handlerinvolves some trickiness with running out of heap space. Inparticular, the global allocation table AT must be unobserv-able since all processes can affect it; this means that the pagefault handler may successfully allocate a page in one execu-tion, but fail to allocate a page in an execution from an in-distinguishable state due to there being no pages available.Clearly, the observable result of the primitive will be differ-ent for these two executions. To resolve this issue, we re-late available heap pages to available quota by applying thefourth state invariant mentioned above. Recall that the in-variant guarantees that the sum of the available quotas of allspawned processes is always less than or equal to the num-ber of available heap pages. Therefore, if an execution everfails to allocate a page because no available page exists, theavailable quota of all spawned processes must be zero. Sincethe available quota is observable, we see that allocation re-quests will be denied in both executions from indistinguish-able states. Therefore, we actually can end up in a situationwhere one execution has pages available for allocation whilethe other does not; in both executions, however, the available

C: confidentiality I: integrity CR: confidentiality restore

σ1

σ2

σ1’

σ2’

I I I

I I I I I I I

C

CR

Figure 6. Applying the three lemmas to prove security ofTSysCall-local yielding.

quota will be zero, and so the page allocator will deny the re-quest for allocation.Security of Yield Yielding is by far the most complexprimitive to prove secure, as the proof requires reasoningabout the relationship between the TSysCall semantics andTSysCall-local semantics. Consider Figure 6, where activestates σ1 and σ2 are indistinguishable, and they both callyield. The TSysCall-local semantics takes a big step overthe executions of all non-observer processes; these big stepsare unfolded in Figure 6, so the solid arrows are all of theindividual steps of the TSysCall semantics. We must es-tablish that a big-step yield of the TSysCall-local machinepreserves indistinguishability, meaning that states σ′1 and σ′2in Figure 6 must be proved indistinguishable.

We divide this proof into three separate lemmas, provedover the TSysCall semantics:

• Confidentiality — If two indistinguishable active statestake a step to two inactive states, then those inactive statesare indistinguishable.• Integrity — If an inactive state takes a step to another

inactive state, then those states are indistinguishable.• Confidentiality Restore — If two indistinguishable inac-

tive states take a step to two active states, then those ac-tive states are indistinguishable.

These lemmas are chained together as pictured in Figure 6.The dashed lines indicate indistinguishability. Thus the con-fidentiality lemma establishes indistinguishability of the ini-tial inactive states after yielding, the integrity lemma estab-lishes indistinguishability of the inactive states immediatelypreceding a yield back to the observer process, and the con-fidentiality restore lemma establishes indistinguishability ofthe active states after yielding back to the observer process.

In the mCertiKOS proof, we actually generalize the con-fidentiality lemma to apply to other primitives besides yield.

• Generalized Confidentiality — Two indistinguishable ac-tive states always take a step to indistinguishable states.

We frame all of the high-level security proofs for theother primitives as instances of this confidentiality lemma.This means that we derive high-level security of the entireTSysCall-local machine by proving this generalized con-fidentiality lemma along with integrity and confidentialityrestore.

14

Note that while the confidentiality and confidentiality re-store lemmas apply specifically to the yield primitive (sinceit is the only primitive that can change active status), the in-tegrity lemma applies to all primitives. Thus, like the secu-rity unwinding condition, integrity is proved for each of theTSysCall primitives. The integrity proofs are simpler sincethe integrity property only requires reasoning about a singleexecution, whereas security requires comparing two.

The confidentiality restore lemma only applies to thesituation where two executions are both yielding back to theobserver process. The primary obligation of the proof is toshow that if the saved register contexts of two states σ1 andσ2 are equal, then the actual registers of the resulting statesσ′1 and σ′2 are equal. There is one interesting detail relatedto this proof: a context switch in mCertiKOS does not saveevery machine register, but instead only saves those registersthat are relevant to the local execution of a process (e.g.,%eax, %esp, etc.). In particular, the CR2 register, which thepage fault handler primitive depends on, is not saved. Thismeans that, immediately after a context switch from someprocess i to some other process j, the CR2 register couldcontain a virtual address that is private to i. How can wethen guarantee that j is not influenced by this value? Indeed,if process j immediately calls the page fault handler withoutfirst triggering a page fault, then it may very well learn someinformation about process i. We resolve this insecurity bymaking a very minor change to mCertiKOS: we add a lineof assembly code to the implementation of context switchthat clears the CR2 register to zero.

Security of Other Primitives We do not need to reasonabout security of proc init since we assume that initial-ization occurs appropriately, and no process is ever allowedto call the primitive again after initialization finishes. Noneof the primitives get quota, start user, or printbrought up any difficulties for security verification.

6. Related Work and ConclusionsObservations and Indistinguishability Our flexible notionof observation is similarly powerful to purely semantic andrelational views of indistinguishability, such as the ones usedin Sabelfeld’s PER model [24] and Nanevski’s RelationalHoare Type Theory [21]. In those systems, for example, avariable x is considered observable if its value is equal intwo related states. In our system, we directly say that x isan observation, and then indistinguishability is defined asequality of observations. Our approach may at first glanceseem less expressive since it uses a specific definition forindistinguishability. However, we do not put any restrictionson the type of observation: for any given indistinguishabilityrelation R, we can represent R by defining the observationfunction on σ to be the set of states related to σ by R.

Our observation function is a generalization of the “con-ditional labels” presented in [3]. In that work, everything inthe state has an associated security label, but there is allowed

to be arbitrary dependency between values and labels. Forexample, a conditional label may say that x has a low label ifits value is even, and a high label otherwise. In the method-ology presented here, we do not need the labels at all: thestate-dependent observation function observes the value ofx if it is even, but observes no value if x is odd.

Our approach is also a generalization of Delimited Re-lease [23] and Relaxed Noninterference [15]. Delimited Re-lease allows declassifications only according to certain syn-tactic expressions (called “escape hatches”). Relaxed Non-interference uses a similar idea, but in a semantic setting:a security label is a function representing a declassificationpolicy, and whenever an unobservable variable x is labeledwith function f , the value f(x) is considered to be observ-able. Our observation function can easily express both ofthese concepts of declassification.

Security Across Simulation/Refinement As explained inSections 1 and 2, refinements and simulations may fail topreserve security. There have been a number of solutionsproposed for dealing with this so-called refinement paradox,e.g. [10, 16, 17]. The one that is most closely related to oursetup is Murray et al.’s seL4 security proof [19], where themain security properties are shown to be preserved acrossrefinement. As we mentioned in Section 2, we employ a sim-ilar strategy for security preservation in our framework, dis-allowing high-level specifications from exhibiting domain-visible nondeterminism. Because we use an extremely flex-ible notion of observation, however, we encounter anotherdifficulty involved in preserving security across simulation;this is resolved with the natural solution of requiring simu-lation relations to preserve state indistinguishability.

Security of OS Kernels The most directly-related work inthe area of formal operating system security is the seL4 ver-ified kernel [11, 18, 19, 25]. There are a lot of similaritiesbetween the security proof of seL4 and the security proof ofmCertiKOS, as both proofs are conducted over a high-levelspecification and then propagated down to a concrete imple-mentation. There are two main aspects of our methodologythat are novel in comparison to seL4. First, the seL4 verifica-tion uses a classic notion of observation, similar to externalevents; the type of observations are the same at the abstractand concrete levels, and the refinement property guaranteesthat high-level specifications and low-level implementationsproduce identical observations; our work generalizes obser-vations, allowing them to express different notions of secu-rity at different abstraction levels. Second, the seL4 verifi-cation only goes down to the level of C implementation; forkernel primitives implemented in assembly, such as contextswitch, security is verified with respect to an atomic speci-fication that is assumed to be correct; the security guaranteewe prove about mCertiKOS, on the other hand, applies to theactual assembly execution of the operating system.

Another related work is the information-flow securityverification of the PROSPER separation kernel [4]. The goal

15

of that verification effort is to prove isolation of separatecomponents that are allowed to communicate across autho-rized channels. They do not formulate security as standardnoninterference, since some communication is allowed. In-stead, they prove a property saying that the machine ex-ecution is trace-equivalent to execution over an idealizedmodel where the communicating components are running onphysically-separated machines. Their setup is fairly differentfrom ours, as we disallow communication between processesand hence prove noninterference. Furthermore, they conductall verification at the assembly level, whereas our methodol-ogy works at both the C and assembly levels, using verifiedcompilation to link implementations in different languages.

The Ironclad [9] system aims for full correctness andsecurity verification of an entire system stack. That workshares a similar goal to ours: provide guarantees that apply tothe low-level assembly execution of the machine. The over-all approaches are quite different, however. One difference isthat Ironclad uses Dafny [12], Boogie [1], and Z3 [5] for ver-ification, whereas our approach uses Coq. This means thatIronclad relies heavily on SMT solving, which allows for alarge amount of automation in the verification, but does notproduce machine-checkable proof evidence like Coq does.Another difference is in the treatment of high-level specifi-cations. While Ironclad allows some verification to be donein Dafny using high-level specifications, a trusted transla-tor converts them into low-level specifications expressed interms of assembly execution. The final security guaranteeapplies only to the assembly level; one must trust that theguarantee corresponds to the high-level intended specifica-tions. Contrast this to our approach, where we verify thatlow-level execution conforms to the high-level policy.

HiStar HiStar [27] is an operating system that attaches se-curity labels onto all objects. When one object communi-cates with another, the kernel performs relevant label checksor taints labels appropriately. Certain trusted processes candeclassify labels. HiStar has a lot of promise as a security-oriented operating system, but it does not currently comewith any formal guarantees. One future goal for mCertiKOS-secure is to implement some of HiStar’s features like labelchecking, and then verify their security. The methodologypresented in this work demonstrates an important step to-wards achieving this goal.

Conclusion In this paper, we presented a framework forverifying end-to-end security of C and assembly programs.A flexible observation function is used to specify the secu-rity policy, to prove noninterference via unwinding, and tosoundly propagate the security guarantee across simulation.We demonstrated the efficacy of our approach by verifyingthe security of a nontrivial operating system kernel. We suc-cessfully developed a fully-formalized Coq proof that guar-antees security of the kernel’s assembly execution.

One important area for future work regards inter-processcommunication. Currently, mCertiKOS-secure does not al-

low any form of communication between processes. It wouldbe nice to allow some well-specified and disciplined formsof IPC. We have actually already started adding IPC — theversion of mCertiKOS-secure submitted in the anonymoussupplementary material includes an IPC primitive that al-lows communication between all processes with ID at mostk (a parameter that can be modified). The security theoremthen holds for any observer process with ID greater than k.Ideally, we would like to extend this theorem so that it guar-antees some nontrivial properties about an observer processwith ID less than or equal to k.

16

References[1] M. Barnett, B. E. Chang, R. DeLine, B. Jacobs, and K. R. M.

Leino. Boogie: A modular reusable verifier for object-orientedprograms. In Formal Methods for Components and Objects,4th International Symposium, FMCO 2005, Amsterdam, TheNetherlands, November 1-4, 2005, Revised Lectures, pages364–387, 2005.

[2] S. Blazy and X. Leroy. Mechanized semantics for the Clightsubset of the C language. J. Automated Reasoning, 43(3):263–288, 2009.

[3] D. Costanzo and Z. Shao. A separation logic for enforcingdeclarative information flow control policies. In POST, pages179–198, 2014.

[4] M. Dam, R. Guanciale, N. Khakpour, H. Nemati, andO. Schwarz. Formal verification of information flow secu-rity for a simple arm-based separation kernel. In 2013 ACMSIGSAC Conference on Computer and Communications Se-curity, CCS’13, Berlin, Germany, November 4-8, 2013, pages223–234, 2013.

[5] L. M. de Moura and N. Bjørner. Z3: an efficient SMT solver.In Tools and Algorithms for the Construction and Analysis ofSystems, 14th International Conference, TACAS 2008, Held asPart of the Joint European Conferences on Theory and Prac-tice of Software, ETAPS 2008, Budapest, Hungary, March 29-April 6, 2008. Proceedings, pages 337–340, 2008.

[6] J. A. Goguen and J. Meseguer. Security policies and securitymodels. In IEEE Symposium on Security and Privacy, pages11–20, 1982.

[7] J. A. Goguen and J. Meseguer. Unwinding and inferencecontrol. In Proceedings of the 1984 IEEE Symposium onSecurity and Privacy, Oakland, California, USA, April 29 -May 2, 1984, pages 75–87, 1984.

[8] R. Gu, J. Koenig, T. Ramananandro, Z. Shao, X. N. Wu,S. Weng, H. Zhang, and Y. Guo. Deep specifications and cer-tified abstraction layers. In Proceedings of the 42nd AnnualACM SIGPLAN-SIGACT Symposium on Principles of Pro-gramming Languages, POPL 2015, Mumbai, India, January15-17, 2015, pages 595–608, 2015.

[9] C. Hawblitzel, J. Howell, J. R. Lorch, A. Narayan, B. Parno,D. Zhang, and B. Zill. Ironclad apps: End-to-end securityvia automated full-system verification. In 11th USENIX Sym-posium on Operating Systems Design and Implementation,OSDI ’14, Broomfield, CO, USA, October 6-8, 2014., pages165–181, 2014.

[10] J. Jurjens. Secrecy-preserving refinement. In FME 2001:Formal Methods for Increasing Software Productivity, In-ternational Symposium of Formal Methods Europe, Berlin,Germany, March 12-16, 2001, Proceedings, pages 135–152,2001.

[11] G. Klein, J. Andronick, K. Elphinstone, T. Murray, T. Sewell,R. Kolanski, and G. Heiser. Comprehensive formal verifica-tion of an OS microkernel. ACM Transactions on ComputerSystems, 32(1), Feb. 2014.

[12] K. R. M. Leino. Dafny: An automatic program verifier forfunctional correctness. In Logic for Programming, ArtificialIntelligence, and Reasoning - 16th International Conference,

LPAR-16, Dakar, Senegal, April 25-May 1, 2010, RevisedSelected Papers, pages 348–370, 2010.

[13] X. Leroy. The CompCert verified compiler. http://compcert.inria.fr/, 2005–2014.

[14] X. Leroy. A formally verified compiler back-end. Journal ofAutomated Reasoning, 43(4):363–446, 2009.

[15] P. Li and S. Zdancewic. Downgrading policies and relaxednoninterference. In POPL, pages 158–170, 2005.

[16] C. Morgan. The shadow knows: Refinement and security insequential programs. Sci. Comput. Program., 74(8):629–653,2009.

[17] C. Morgan. Compositional noninterference from first princi-ples. Formal Asp. Comput., 24(1):3–26, 2012.

[18] T. C. Murray, D. Matichuk, M. Brassil, P. Gammie, T. Bourke,S. Seefried, C. Lewis, X. Gao, and G. Klein. sel4: Fromgeneral purpose to a proof of information flow enforcement.In IEEE Symposium on Security and Privacy, pages 415–429,2013.

[19] T. C. Murray, D. Matichuk, M. Brassil, P. Gammie, andG. Klein. Noninterference for operating system kernels. InCertified Programs and Proofs - Second International Confer-ence, CPP 2012, Kyoto, Japan, December 13-15, 2012. Pro-ceedings, pages 126–142, 2012.

[20] A. C. Myers and B. Liskov. A decentralized model for infor-mation flow control. In SOSP, pages 129–142, 1997.

[21] A. Nanevski, A. Banerjee, and D. Garg. Verification of infor-mation flow and access control policies with dependent types.In IEEE Symposium on Security and Privacy, pages 165–179,2011.

[22] A. Sabelfeld and A. C. Myers. Language-based information-flow security. IEEE Journal on Selected Areas in Communi-cations, 21(1):5–19, 2003.

[23] A. Sabelfeld and A. C. Myers. A model for delimited infor-mation release. In ISSS, pages 174–191, 2003.

[24] A. Sabelfeld and D. Sands. A per model of secure informationflow in sequential programs. In ESOP, pages 40–58, 1999.

[25] T. Sewell, S. Winwood, P. Gammie, T. C. Murray, J. Andron-ick, and G. Klein. sel4 enforces integrity. In Interactive The-orem Proving - Second International Conference, ITP 2011,Berg en Dal, The Netherlands, August 22-25, 2011. Proceed-ings, pages 325–340, 2011.

[26] The Coq development team. The Coq proof assistant. http://coq.inria.fr, 1999 – 2015.

[27] N. Zeldovich, S. Boyd-Wickizer, E. Kohler, and D. Mazieres.Making information flow explicit in histar. In OSDI, pages263–278, 2006.

17