Int J Softw Tools Technol Transfer
DOI 10.1007/s10009-011-0195-9
VSTTE 2009-2010
Formal methods for security in the Xenon hypervisor
Leo Freitas · John McDermott
© Springer-Verlag 2011
Abstract This paper reports on the Xenon project’s use of
formal methods. Xenon is a higher-assurance secure hypervi-
sor based on re-engineering the Xen open-source hypervisor.
The Xenon project used formal specifications both for assur-
ance and as guides for security re-engineering. We formally
modelled the fundamental definition of security, the hyper-
call interface behaviour, and the internal modular design. We
used three formalisms: CSP, Z, and Circus for this work.
Circus is a combination of Standard Z, CSP, with its seman-
tics given in Hoare and He’s unifying theories of program-
ming. Circus is suited for both event-based and state-based
modelling. Here, we report our experiences to date with using
these formalisms for assurance.
Keywords Xenon · Circus · Theorem proving · Formal
modelling · Separation kernel · Virtualisation
1 Introduction
Xenon is a higher-assurance hypervisor derived from the con-
ventional Xen hypervisor [3,5,31] with an emphasis on secu-
rity. Conventional Xen was initially developed as a research
platform by the University of Cambridge Computer Labo-
ratory. Currently, conventional Xen has been implemented
on x86, Itanium, ARM, and Power PC processors, on scales
ranging from individual mobile devices to entire cloud archi-
tectures and supercomputers. Conventional Xen remains an
open-source product but has grown to commercially sup-
L. Freitas (B)
School of Computing Science,
Newcastle University, Newcastle upon Tyne, UK
e-mail: leo.freitas@newcastle.ac.uk
J. McDermott
Naval Research Laboratory, Washington, DC, USA
ported products by Citrix, Oracle, Virtual Iron, and Novell.
Conventional Xen has a relatively good security record
against typical adversaries and is thus a good basis for a
higher-assurance hypervisor. Higher-assurance hypervisors
like Xenon provide robust information flow control, tamper-
resistance, and self-protection for communities of users that
share execution on a single piece of hardware. To date, only
one vulnerability has been found in the hypervisor per se. All
other reported vulnerabilities have been in the guest operat-
ing systems.
The primary goal of the Xenon project is to investi-
gate issues in re-engineering an open source software prod-
uct into higher security assurance than conventional open
source [24]. In this paper, we present some results from
our modelling of part of the Xenon API for event channel
(i.e., virtual interrupts) communication across guest domains
(i.e., contexts for the virtual machines provided to guest OSs)
and virtual instruction set processors.
Xen is neither safety-critical, nor formally defined. The
relative high quality of the existing Xen source code makes
this re-engineering an interesting research topic, though. That
is because most of the Xen code is relatively easy to mod-
ify into higher-assurance Xenon form, given Xen’s modu-
lar, self documenting, and simple architecture. For design
recovery, we use a program slicing and inspection tool called
CodeSurfer. Our use of CodeSurfer is reported in [22]. The
CodeSurfer tool provides deep general understanding that
facilitates discovery of the designer’s intent, but does not
capture the intent as specifications; it provides navigational
facilities for code investigation. This paper reports how we
capture and formalise the original designer’s and/or program-
mer’s intent from available source code, using a formal nota-
tion. Thus, capturing intent here means formally specifying
what the designer’s code behavioural intent is. Obviously
one can make mistakes in such capture, in a similar manner
123

that one could mistaken interpret some elicited requirement
into a formal specification. The point here is that the captured
intent becomes “the” specification of Xenon for further proof
analysis. We rely on NRL’s expertise on Xen and our exper-
tise in formal modelling for the accuracy (and usefulness) of
such process. Once this concrete specification of the code’s
intent is analysed, various design decisions get properly doc-
umented and some times modified due to counter examples
arising from failed proofs.
We are at a point where most of the Xenon code for virtual
interrupts has been processed. We envisage applying refine-
ment calculation techniques from this concrete specification
in order to reach the code, now with rigour in the code gener-
ation process gained through the proof scrutiny of the intent
captured as the concrete specification. In the use of formal
modelling it is important to distinguish safety-critical from
security-critical software, as they are not equivalent, and we
are concerned here with security. For instance, a fire-alarm
that never works (e.g., is deadlocked) is secure in the sense it
does not leak any confidential information, yet it is not safe
in the sense it does not do anything useful.
In the Xenon project, we used formalisms to capture
(code’s) intent, define security, and describe the hypervisor’s
external interface, i.e. its hypercalls [5]. This formalism is
Circus, a combination of Z, CSP, and the refinement calcu-
lus (see Sect. 2, and the next two subsections). The security
we are concerned with is strict isolation or separation of host
execution of the virtual machines, i.e., separation of domains.
The most common abuse cases that we seek to rule out are
the hypervisor becoming the path of least resistance for one
guest operating system to attack another; and the hypervisor
becoming the path of least resistance for an intruder on one
network to gain access to another network.
We can summarise this in terms of the events that take
place in the domains. Informally, the Xenon security policy
is that no untrusted domain should be able to cause, enable,
or prevent any event in another domain. Conceptually, events
include not only the host execution of instructions but also
traps, exceptions, and interrupts. The practical implication of
this is that we rule out not only externally induced crashes or
lockups, administrative control of guest operating systems,
and direct copies of information between guests but also
exploitation of hypervisor features to indirectly leak infor-
mation between guest operating systems. The policy does
not apply to hardware, so we are not addressing side channel
attacks. Also, our policy applies to host execution, not net-
work security. Like its parent Xen, the Xenon hypervisor per
se does not handle network processing or security. Network
features are implemented by guest operating systems.
In this paper we report on our current work with not only
capturing Xenon’s intent with formal modelling but also
using Circus and the Z/Eves theorem prover to develop a
specification pattern for verifying the security of the hypervi-
123
L. Freitas, J. McDermott
sor’s external interface. Given Xenon’s scale (e.g., even after
simplifying the Xen code into its Xenon form there will still
be over 200 hypercalls), we report here part of the work, in
particular our approach to specifying and verifying security
for a representative subset of the hypercall interface.
It would be unwise to construct a complete formal spec-
ification of all the Xenon hypercalls, literally thousands
of pages, without first using our automated tools to verify
the intended security properties for a representative sub-
set. Verification of such a large interface requires efficient
proofs, which in turn require delicate choices of specification
approach. Automated verification of a representative subset
provides critical insight into potential difficulties and reveals
approaches that should be avoided. The complete specifi-
cation can then be constructed by repeating the success-
ful pattern developed in the automated verification of the
representative subset. This paper reports a successful spec-
ification pattern and shows how proof revealed the changes
needed for verification of the larger specification.
First, we describe our approach to applying formal meth-
ods within the Xenon project, as well as the notion of intent
within the open-source software. Next, in Sect. 2 we define
Xenon’s notion of security, which is an extension of a similar
notion for CSP, as well as presenting the formalism used,
namely Circus. In Sect. 3 we present our approach to con-
structing the specification and verification pattern we will use
for hypercall behaviour: it contains an example of how the
rest of our model for the Xenon hypercall interface will be
constructed and verified. We also summarise findings from
theorems proved along the formalisation process using the
Z/Eves theorem prover and the CZT Circus tools1 in Sect. 5.
After that, we present our non-interference definition of secu-
rity within Xenon in Sect. 4. Finally, we present some conclu-
sions in Sect. 6. This work is a joint effort between the Naval
Research Laboratory (US), and Newcastle University (UK).2
1.1 Applying formal methods in the Xenon project
Understanding all possible behaviours, as well as uncovering
hidden and/or mistaken assumptions about requirements or
the environment are the reason we apply formal methods to
the problem of higher assurance software security. Without
formal methods, we believe it is not feasible to even attempt
understanding of this scale. Currently, there are two practical
ways to apply formal methods to higher assurance software
security. The first is on a product that is designed and con-
structed using formal methods throughout its lifecycle. The
alternative is to apply them to a suitable product that has been
developed without formal methods, but is widely used and
1 http://czt.sourceforge.net.
2 Some of modelling work also took place while the first author worked
at the University of York (UK).
Formal methods for security in the Xenon hypervisor
thus merits the additional effort. The Xenon project is taking
the latter approach and, as we will explain shortly, has also
been taken by two other significant related projects.
Practical systems, constructed with or without formal
methods, even those of high-quality that have very few flaws,
lack consistency and security checks and contain complex
constructions that are difficult to verify. Even in high-quality
software, the checks must be omitted and complexity added,
for performance reasons. Practical formal methods must be
able to cope with both of these realities.
Related work. The seL4 project [18] has demonstrated
that it is possible to use formal methods to show that the cor-
ner cases relating to the omitted checks never happen [17].
The seL4 project is a formally verified microkernel targeted
at mobile and embedded devices. The implementation of
seL4 is manually developed high-performance C, running
on the ARM processor, a much simpler target than the full
x86 64 instruction set architecture targeted by Xenon. (Con-
ventional Xen supports many processors besides the x86,
not only ARM processors but also the IA64 instruction set
architecture. This introduces additional complexity that the
Xenon project must address.) It is also important to under-
stand that the seL4 project uses a much simpler definition
of security, the take-grant model [20], and does not enforce
information-flow security. The seL4 approach is both similar
and different from the Xenon project. Unlike the Xenon pro-
ject, the seL4 project designed its microkernel using formal
methods from the beginning and applied them all the way
down to the source code. However, the seL4 microkernel is
actually a re-implementation of the open-source L4 micro-
kernel, which has been implemented many times before. So
the seL4 project is in fact working with previously developed
open source that has been shown to be very practical. Like the
Xenon project, the final step in constructing the operational
seL4 microkernel is manual development of C source code.
Unlike the Xenon project, the seL4 project has verified all
of the implementation of the lowest level of the microkernel
source code. Since the Xenon software is an order of mag-
nitude larger than seL4, complete verification of the infor-
mation-flow security policy over all source is not practical,
even though the Circus formalism can be carried down to the
source code by refinement, for any subset of practical size.
Another related project that worked from the source code,
rather than having started from formal methods like seL4, is
the Microsoft Hypervisor [19]. From the low-level C source
code, they constructed a specification using the verifying C
compiler (VCC). It is used as a code-level extended static
analysis tools that handles both behavioural aspects of under-
lying data structures, as well as concurrency issues. Their
effort is similar to ours in the sense that it is an attempt to
formally document the code’s intent. It is different from ours
in the sense that we want to have a more high-level notion of
security properties (see [23]), which we want to prove that
the Xenon code conforms to.
Xenon. In the Xenon project, we used formal methods to
both define security and to specify what that definition means
for the hypercall interface to Xenon. The rest of this paper
reports our experiences to date with these applications. The
application of formal methods is expensive, too expensive
to be applied to a large product that may not achieve signif-
icant market share. For this reason, refining a new product
from correct formal modelling over its complete life cycle is
unlikely to result in anything that is used on a practical basis,
hence our reporting of its key aspects here.
We constructed specifications for the external visible
behaviour of hypercalls using Circus [26,27,33], as it is suit-
able for reasoning with both state-based description of hyper-
calls, as well as describing and reasoning about concurrency,
locking, and race conditions. Circus is also suitable for con-
structing an unwinding theorem for our refinement of the
security properties (see Sect. 3). Circus allows us to bypass
unwinding theorems whilst retaining our definition of secu-
rity [23], and to use its refinement calculus to establish the
link between this definition of security and our model.
Grand Challenge. In applications of formal methods to
security, an interface specification is not just an intermedi-
ate refinement on the path to secure code. It also serves as a
standalone means of ruling out design insecurities. Practical
examples of this are found in the formal treatment of network
security protocols [30], where apparently simple network
interfaces have been shown to be vulnerable to attacks based
on race conditions or interleaving. These practical attacks
are effective without regard to any flaws in the code level
implementation, that is, they are design flaws. In our case,
we use the formal hypercall interface specification in a simi-
lar manner. We want to be sure that the defined behaviour of
the complete set of hypercalls cannot be exploited in some
source-code-independent manner. This is essential for a large
complex hypercall interface like Xenon. Furthermore, var-
ious general theories and reusable lemmas, like those for
pointer, injective functions, and set partitioning have been
created as a result of this work. A simple (and abstract) the-
ory of security is also discussed. This shows the great ben-
efits of such a large case-study. For instance, some of these
lemmas have been reused in other projects within the Grand
Challenge in software verification [11].
Given the significant market share of Xen, we believe
it is worthwhile pursing formal verification and certifica-
tion of a higher assurance form. Furthermore, given its sheer
size (potentially 4500 pages of Circus in its final form), the
underlying complexity and intricacy is self-evident, hence
justifying formal modelling.
123

Common Criteria evaluation. The Xenon project is not
planning for a Common Criteria evaluation [8]. There are
several reasons for this. First, conducting an actual evalua-
tion is expensive and beyond the scale of the available fund-
ing. A significant portion of this expense is the cost of the
independent evaluation staff and the cost of providing full-
time internal project staff to interact with the evaluators. Of
even greater importance is the fact that the higher Evaluation
Assurance Levels [7] (EALs) 5, 6, and 7 of the Common
Criteria are not comparable over different nations. So, for
example, an EAL of 5 achieved under US evaluation does
not necessarily compare to an EAL 5 achieved under UK
evaluation. Furthermore, there are no published protection
profiles for EAL 5, the most likely Evaluation Assurance
Level for Xenon. Because of its size, an evaluated version of
Xenon is unlikely to satisfy an EAL above 5.
1.2 Capturing intent in open-source software
The key characteristic of higher-assurance software is we
have greater confidence it satisfies some specific properties
[16], such as information-flow security. Properties are a more
precisely defined instance of “intent”: what the software is
supposed to do, as opposed to what it actually does.
Open source typically does not capture intent, and the
Xen hypervisor is no exception. By intent here we mean the
designer’s objectives when making decisions, which can be
(or here we claim usually is) not as accurate as intended. Open
source assumes that cases where the code does not satisfy the
intent are so infrequent and obvious that it is not cost effective
to document. It is expected in conventional open source best
practice that there is a small group of developers who deeply
understand the intent of the code. This may give a (false)
intrinsic perception that there is no need for specification.
However, this is not sufficient for higher-assurance. Docu-
mented intentions and design decisions must be subjected to a
constructive but adversarial third-party review [1, Chap. 26],
for higher-assurance. For that, we see formal specification as
our best device.
Capturing intent is a key part of the Xenon project. We
have used a variety of means to accomplish this. Some
intent has been captured using an informal Wiki format. We
have used MoinMoin3 to capture both a security architec-
ture description and an assurance argument. Some intent
has been recorded there as well, in the form of a module
guide written in informal natural language, that explains
the intended modularity of the implementation. The Xen
implementation modules do not correspond to the source file
structure, i.e., there is nothing corresponding to the pack-
age or class structure of an object-oriented language. Nev-
ertheless, Xen (and its child Xenon) have a well-defined
3 http://moinmo.in.
123
L. Freitas, J. McDermott
and high-quality modular structure. For example, the source
file xen/.../multi.c actually contains 16 distinct
modules.
The intent that is most challenging to capture is the
intended behaviour of the software. We have used Dot dia-
grams and natural language recorded in several formats,
including both a custom web-based tool and the open-source
Trac project management system. This paper reports how
we also use formal methods to capture the behaviour of the
Xenon source code. The most abstract behaviour to be cap-
tured, for software systems that have security properties, is
the overarching meaning of security. In addition to this, we
have also captured the behaviour of the hypercall interface.
2 Background
We chose the Circus formalism [26,27,33] to define secu-
rity, i.e., what it means for the Xenon hypervisor to be secure.
Xenon enforces information-flow security. Most formal def-
initions of information flow security are not preserved by
refinement. Our first choice of formal security definition
was chosen from the family of CSP-based4 independence
definitions of Roscoe, Woodcock, and Wulf [29] as fur-
ther developed by Roscoe [28], since it preserves refine-
ment. Definitions of information flow are subtle and are not
addressed simply, even in a powerful notation like CSP. The
basic notion of non-interference is that events taking place
in one domain should not flow/leak information into another
domain, via host execution on shared hardware. For a con-
crete instance, a compromised guest operating system vir-
tualised on an information-flow secure hypervisor should not
be able to leak medical records it processes, to another guest
operating system running in a different domain but virtua-
lised on the same hypervisor. That is, the shared hypervisor
should not become a path of least resistance for information
flow. Without this kind of security, an adversary could leak
information without violating network security, by exploiting
the shared execution environment. Information-flow security
is of particular interest in cloud computing infrastructures,
where cloud users expect their virtual machines to be sepa-
rated as though they were separate physical machines.
In many cases, information-flow security disallows all
information flows between all entities. An example would
be cloud platforms that expect their computation to be kept
separate from each other. However, there are applications of
information-flow security where some flows are allowed. In
these cases, the entities are considered to have a partial order
defined for their information flow. Informally, if we have
entities x and y (for Xenon this would be domains) whose
4 Unless otherwise specified, this paper is referring to Roscoe’s CSP
semantics [28].
Formal methods for security in the Xenon hypervisor
information flow policy is x < y then information is allowed
to flow from x into y but not vice-versa. When discussing
a general case, we refer to entity x as “low” and entity y as
“high”. The “high” entity’s information has “higher” sensi-
tivity than the “low” entity. In many cases, the partial order
is defined to be a lattice, with the system software being at
the bottom of the lattice [9].
What we are trying to achieve here is extending an elegant
notion of noninterference through refinement. The original
paper [29] discusses non-interference in CSP, which encom-
passes (concurrent) behaviour over simple states, whereas
our specification uses Circus, which includes both cur-
rent behaviour and state-rich and trace-rich specifications of
abstract data types used by the concurrent system.
2.1 Defining security
From this family of definitions, we have chosen a defini-
tion based on the stable failures model of CSP. That is, we
consider neither divergences nor infinite traces. These dif-
ferences do not matter for our application of independence
to Xenon. There are three reasons for this choice: (1) lazy
abstractions (see below) can introduce infinite nondetermin-
ism through hiding, and we wish to avoid this theoretical
complexity; (2) because we will ultimately carry this defi-
nition of security into the state-rich Circus formalism, thus
introducing state complexity into our model, and we wish to
minimise trace complexity in practice; and (3) for practical
engineering reasons we assume that any attempts to flow
information in an unauthorised manner, via divergences or
infinite traces, will be easily detected in a hypervisor. In other
applications of independence, this may not be the case. Yet,
for the hypervisor, divergence or infinite traces will manifest
themselves as a malfunction, which is then investigated by
the user, and hence game over for the attacker: he has been
discovered. Again, remember the difference between secu-
rity and safety (e.g., it is perfectly safe to do nothing, albeit
useless), and our emphasis on the former.
This CSP-based definition of Xenon security defines sep-
aration between Low and High as the independence of Low’s
view from anything High might do, where Low and High are
just sets of possible events from the hypervisor (Low) and
the user OS domain (High) that are disjoint, and partition
the whole set of visible events (F). In the context of Xenon
(or Xen), Low and High are hypervisor domains [3,6,31]
that contain the guest operating systems hosted by Xenon
(or Xen). So the formal definition says that events caused
or observed by a Low guest operating system are indepen-
dent of (or not influenced by) events caused by a High guest
operating system. In CSP, we express our definition of secu-
rity as follows: if S represents the hypervisor and its guest
operating systems as a (composite) CSP process, where F is
the complete set of visible events, H is the set of High CSP
events, and L = F \ H is the set of Low CSP events, then the
stable-failures lazy-abstraction of S with respect to H will
have the form
LH (S) = (S
F
|| HCHAOSH ) \ H (1)
Given this lazy abstraction, we can define the CSP inde-
pendence definition of security as the deterministic lazy
abstraction of the system S with respect to High,
LH (S) det (2)
where the equivalence is a stable-failures equivalence, and
the notation P det means the process P is deterministic. Fol-
lowing [28,29], a CSP process is deterministic when
s a ∈ traces(P) ⇒ (s, {a}) ∈ failures(P) (3)
because we are using the stable-failures and trace models of
CSP, Eq. 3 does not mention freedom from divergence.
Informally, the interesting part of this definition is the use
of failures to define security. A trace approximates a sequence
or history of events that a system has already performed; the
failures of a trace are the events that a system is not prepared
to do, at each point in the trace. So our definition says that
security can be violated by disabling or temporarily denying
a service or feature. This failure-based definition of security
has a built-in means of addressing attacks based on faults or
crashes, in addition to attacks based on successful requests.
The best explanation of Eq. 1’s definition can be found in
Chap. 12 of Roscoe’s text [28]. This definition “subsumes”
the High user (guest operating system) with the CSP constant
CHAOSH that not only can perform all possible sequences of
High events, i.e., including event sequences a well-behaved
user would not generate, but also can arbitrarily refuse to per-
form any of them as well. If this kind of arbitrary behaviour
by the High part of the system cannot cause the Low part of
the system to behave in a non-deterministic way, then High
cannot influence what Low sees and no information flows
from High to Low.
This CSP based independence definition is a good one
for practical information-flow security, but it is difficult to
relate it to the state-rich implementation of an actual hy-
pervisor. For this reason, we chose an alternative formalism
that can express independence definitions in a natural way,
while providing for a state-rich implementation of concur-
rent behaviour formally. In this context the choice for Circus
is quite natural, given it already is a state-rich extension of
CSP with similar notions of refinement, traces, and failures.
Circus is explained in more detailed next.
123

2.2 Circus
Circus is a combination of (ISO Standard) Z [15], impera-
tive5 CSP [13,28] and the refinement calculus [2]. Like Z,
Circus models are formed by a sequence of paragraphs that
define types, sets, relations, and schemas. Unlike Z, Circus
paragraphs may not only be Z paragraphs, but also chan-
nel, channel set, or process paragraphs, which are CSP
constructs. Channels organise the events of Circus spec-
ifications. An event in Circus is a (<name>, <value>)
pair; <value> gives the value communicated by the event
over a channel <name>. All channels must be named and
their types specified using Z expressions (generic channels
are also allowed). Previously defined channels may be col-
lected into channel sets. Process paragraphs define Circus
processes that may contain Z-style (private) state declara-
tions, actions, guarded actions, communication prefix, and
other actions. Each process must end with a nameless “main”
action that defines behaviour of the process. Actions and
whole processes may be operated on by CSP-style opera-
tors, such as parallel (x), external choice (), etc.
Readers familiar with Z or CSP will find Circus mod-
els to be nearly “self-documenting”. For Circus, the next
example shows a specification of the a state-based vending
machine6 for cookies. In what follows, we explain both the
Z and CSP aspects of this example in detail. We assume the
reader is somewhat familiar with both Z [32] and CSP [28]
when discussing the Xenon model later on. First, we define
bounds for the price and amount of cookies available as a
natural number
cookieVal, cookieQuant, MAX QUANT : N
cookieQuant ≤ MAX QUANT
We also add a status flag determining if a cookie was dis-
pensed or not.
COOKIE ::= ok | notok
There are three channels: channel in synchronises with the
user process when inputing money; channel out gives the
cookie request status; and channel change returns to the user
the amount of change involved.
channel in, change : N
channel out : COOKIE
5 Processes may contain guarded commands, e.g.,
if a > 0 −→ x , y := a, b fi .
6 The classic CSP example, here augmented with state.
123
L. Freitas, J. McDermott
The cookie machine is a process with state as follows:
process CookieMachine =
 begin
it contains the amount of cookies the machine has, which is
bounded, and the amount of money entered by the user.
State
quantity, money : N
quantity ≤ MAX QUANT
The state is local to the process CookieMachine and is not
accessible from other processes.
state State
Next, we define two state operations for cookie delivery as
Z schemas, which are labelled records with invariants, where
new lines represent conjunction. It is often used to repre-
sent a relational view of the state as before (x) and after (x  )
values. OutputCookieOk returns on output variable o!7 the
cookie delivery status. It is ok, providing there is at least as
much money as the cookieVal constant (e.g., the user pro-
vided enough coins), and the quantity of cookies is not 0
(e.g., the machine is not empty). It then reduces the money
by this value, and quantity by one. The Δ means both State
and State are in context, where State is a copy of State with
all variables and invariants dashed.
OutputCookieOk
ΔState
o! : COOKIE
money ≥ cookieVal
money = money − cookieVal
quantity > 0
quantity = quantity − 1
o! = ok
If these conditions are not met, i.e., if either there is not
enough money (money < cookieVal) or the machine is empty
(quantity = 0), then State remains unchanged (as given by
ΞState, which includes ΔState and that quantity = quantity
and money = money ), and o! returns a not okay status.
7 Like in Z, output variable names have a shriek (!) in their name by
convention. Similarly, input variable names have a question mark (?) in
their name.
Formal methods for security in the Xenon hypervisor
OutputCookieNotOk
ΞState
o! : COOKIE
One can also add comments.
money < cookieVal ∨ quantity = 0
o! = notok
The overall OutputCookie operation is the disjunction of
these two operations. One can imagine this as an API function
that computes successful and error cases.
OutputCookie =
 OutputCookieOk ∨
OutputCookieNotOk
The state is initialised next using a schema. The visible (trace)
behaviour of a schema is just Skip (e.g., no event followed
by termination), yet it changes the private/local state of the
process. It simply sets money to zero, and the quantity as
the fixed, yet underspecified, quantity within the maximum
bounds (cookieQuant ≤ MAX QUANT ).
InitState
State 
money = 0 ∧ quantity = cookieQuant
In Z, state initialisation usually comes right after state dec-
laration, but one can add it at any point after the state dec-
laration. Next, we define the state operation associated with
the user inputing money: it is executed right after the user
communicates the input value x below, which is bound to x?,
providing there is not enough money yet.
InputMoney
ΔState; x? : N
money ≤ cookieVal ∧ money = money + x?
After declaring the state operations using Z schemas, we can
define the behaviour of the process using Circus actions.
Action Input is a guarded input communication action: when-
ever the guard about enough money available being true,
money input through in is read on x, and after that the
InputMoney schema is executed, where the x read is bound
to the x? input of InputMoney
 (money ≤ cookieVal)
Input =
in ?x −→ (InputMoney)
As in CSP, guarded actions in Circus are deadlocked (as in
process Stop that terminates refusing all events) if the guard
is false. This communication at channel in affects the trace
of the process visible outside the process. Another guarded
action needed is about the cookie status output, providing
there is enough money. Because all input and output variables
in Z must be in context, we define a local variable o, which
is bound to o! in OutputCookie executed next. It updates
the state and terminates (e.g., behaves like Skip). This is
followed by sequential (action) composition to the output
communication over channel out the calculated cookie sta-
tus in o!. After that, change is returned to user, even if zero,
and the action successfully terminates.
 (money ≥ cookieVal)
Output =
(var o : COOKIE • (OutputCookie);
(out !o −→ change !money −→ Skip))
Finally, the main behaviour of process CookieMachine is
defined by the next main action, which follows from the (big-
spot) “•” token.
• InitState ; (µ X • (Input  Output) ; X)
It initialises the state first, followed by a loop of an external
choice between input and output actions by the user or envi-
ronment. Loops are specified using the usual µ construct,
and external choice means the process waits for the envi-
ronment on available events, rather than internally deciding
which event to choose.
end
The process is then enclosed with end. Note the literate style
of specification, where textual documentation and formal text
are intermixed: and the Circus and Z tools used in Xenon
actually process the very LATEX where the specifications are
created and documented (with English commentary).8 The
next step would be to model the user process or the environ-
ment requesting cookies and providing money, which is then
put in parallel with the CoockieMachine process given the
right channels to synchronise; we leave this out.
2.3 Lazy abstraction in Circus
Even though Circus incorporates CSP semantics, we can-
not (re-)use Roscoe’s CSP independence definition directly
(see Eq. 1). The CSP definition of independence requires
the lazy abstraction of the separation hypervisor system to
remain deterministic in the presence of a Chaos process at
High events. There is a Circus action named Chaos but it
has semantics that are unsuitable for our independence-based
8Apart from the “informal” ellipsis (. . .), all else is recognised by the
Circus tools and Z/Eves prover.
123
 L. Freitas, J. McDermott

definition of information-flow security. In Circus, the action concurrency, locking, and race conditions. This was one rea-
Chaos is defined [26] as Chaos =  R(false  true), a reactive
process that providing the impossible (false), may do any-
thing (true) at any point in its execution, including diverge.9
Chaos as used by [28,29] is a process that can do anything
but diverge, namely ChaosA = Stop
(?x : A −→ ChaosA ). The other reason for switching to Circus was the difficulty
We define in Circus Balagan10 that has the desired
divergence-free behaviour. Circus process Balaganc is pre-
pared to engage in any possible sequence of events within the
type T of channel c (c?x), or (nondeterministically,
) block rules that show how the trace-based definition applies to indi-
(Stop) instead. The µ operator represents recursion over X,
whereas the first (big) spot (“•”) marks the starting point of
the process main action. The second spot opens the scope for
the recursive definition using µ.
channel c : T
process Balaganc = begin
• (µX • (c?x −→ X)
Stop) example unwinding rule (a simplified example, not a rule we
end
If we denote channel set F as the set of all channels used in a
(composite) secure process S, and channel set H as the set of
channels used by the High part of process S, we can define a
lazy abstraction for Circus in lieu of Eq. 1 as
 (S  H  BalaganH ) \ H
LazyAbstractionH =
Just as in the CSP lazy abstraction, this definition subsumes
the High process with a Circus process that can perform arbi-
trary sequences of events on the applicable channels as well
as deadlock. It cannot, however, interfere with the system
Low events.
3 Defining secure hypercall interface behaviour
In the Xenon project, we constructed two interface specifi-
cations of the hypervisor, i.e., a specification describing the
visible behaviour of the hypercall interface. The first spec-
ification was constructed using Standard Z in the Oxford
Style [32]. It did not document the precise structure of the
implementation but did describe its externally visible behav-
iour. The resulting model would be significantly smaller than
the internal design-level specification. We estimated its final
size as about half the size of the internal design specifica-
tion (to be described in the next section), that is 4500 pages
of ISO-Standard Z, including English commentary. We also
encountered difficulties in describing and reasoning about
9 Its semantics expanded is interpreted as if wait then Π else tr ≤ tr  ,
which means if the process is waiting, nothing changes and it is in
deadlock; else, anything can happen and the trace history is preserved.
10 A modern Hebrew word for chaos.
123
son we abandoned this approach and switched to the Circus
tool chain for a second interface-level specification. Since
Circus contains ISO-Standard Z, as well as CSP, it is well
suited as the target formalism to use.
in constructing an unwinding theorem for our refinement of
the security properties. Since our definition of security is
trace-based, we need an unwinding theorem or unwinding
vidual states and state transitions. This can be awkward when
mapping from an event-based formalism (the original CSP
model) to a state-based formalism (Z). Use of the Circus for-
malism allows us to bypass unwinding theorems but retain
our definition of security, also in Circus [23], and to use its
refinement calculus to establish the link between this defi-
nition of security and our model. To clarify, we present an
claim applies to any Xenon specification). Recall our defi-
nition of security is given in Eq. 3 and is based on traces.
One needed unwinding rule defines an equivalence relation
on states (rather than traces) that calls two states equivalent
when both states, with the High parts left out, have the same
possibilities for transition into a future state. Here, instead of
the failures over trace of events, we have refusals associated
with a specific state. Informally, refusals are the input, next
state, output combinations that would not happen in a given
state of a process.
∀ Qi , Qj : States • Qi ≈ Qj ⇒
refusals(Qi ) \ H = refusals(Qj ) \ H
This one unwinding rule (Qi ≈ Qj ) probably would not suf-
fice by itself. We would have to show that the collection of
rules is sound for all of the language features we use in our
specifications for Xenon.
Our second, Circus-based specification, is about the same
size as the Z-based specification, but also describes concur-
rency. That is because we reuse almost all the Z model, but
add process-algebraic features from CSP to describe how
the Xenon state is to change. If we tried to accomplish this
description of state transitions in Z alone, we would need to
define concurrency explicitly in our specification, including
theories about traces, parallel execution, and interleaving.
Since the second specification represents a significant
industrial use of Circus, we describe it in some detail. The
complete specification is quite large, so we only present
selected portions of it. For the most part, our presentation
follows the order of presentation in the specification itself.
The Circus tool suite allows the natural language to be
interspersed with the formal specifications, like in literate
programming. We shorten the example by omitting parts of
Formal methods for security in the Xenon hypervisor
the specification. In Sect. 5, we present a summary of the
effort involved.
3.1 Specification sections organisation
From its Standard Z heritage, Circus inherits the concept
that allows us to organise the specification in sections. This
sectioning resembles the underlying C code directory struc-
ture. Textually, they are just markers with a name and a list
of parent sections. We omit them here to save space, yet we
briefly discuss the (transitive and acyclic) parenting relation-
ship between these sections.
Our specification begins with some of the definitions from
the Xen Security Modules (XSM) subsystem: in Xenon they
are used to characterise allowable information flows. When
Xenon is configured to allow some information flows, then
XSM defines the “high” and “low” partial order relation of
the allowed flows. Security enforcement in Xenon, like its
parent Xen, is largely inherent in the virtualisation, rather
than being in some specific security module. The design of
Xen enforces a “no flows allowed” policy, without any use of
XSM. However, XSM encapsulates additional logic to define
“some flows allowed” policies on top of this inherent mech-
anism. Once some information flows are allowed, we need
to not only prove that XSM provides the correct definition
of allowable flows, but that it also does not introduce nonde-
terminism and thus violate the fundamental noninterference
security policy.
We also partially present the Xenon programmer’s model
defining concepts of the underlying hardware and compilers
and hence giving a modular structure to the whole specifi-
cation. In a hypervisor, what is usually considered low-level
hardware detail becomes instead the principal abstraction to
be exported. For example, in Xenon the page dirty bit is not to
be hidden but instead manipulated and exported as an exter-
nally visible abstraction. The abstraction lies in whether a
particular page dirty bit is a virtual page dirty bit or a real
hardware page dirty bit. So we need to talk about bits, bytes,
and machine words early on and they never really disap-
pear. We borrow the term programmer’s model from the Intel
assembly language programming guides [14].
Both these sections inherit the Circus toolkit section
containing an extension of the Standard Z mathematical tool-
kit. Next, a section for Xenon defines basic types and con-
stants that are provided by the Xenon implementation. It
inherits both the XSM and programmer’s model sections
and hence (transitively) the Circus toolkit as well. Next we
have the hypervisor section containing the various parts of
the local/global state and their operations, as well as a guest
domain section including the guest OS specification. The
hypervisor section inherits Xenon, whereas the guest section
inherits the hypervisor section. Finally, the system is the com-
bination of the whole of these sections. Notice that some of
these top-level sections themselves inherit other smaller sec-
tions, which are the ones closely related to the underlying C
code file structure. These last three sections define both the
specific hypercalls and the supporting structures needed to
define overall hypervisor behaviour.
3.2 Capturing key relationships
We want to not only verify security from our abstract
model [23], but also identify problems with the implementa-
tion, so our specification is organised to capture some of the
essential relationships of the implementation. We are work-
ing from the code upwards to a concrete Circus specifica-
tion, which we are currently proving refinement with respect
to a previously published abstract specification for security
through non-interference already mentioned.
Foremost of these is the triangular dependency between
the three major entities from the Xenon state space: virtual
contexts for guest domains, virtual instruction set processor
VCPUs, and virtual interrupts or event channels. These three
entities depend on and refer to each other. For example, a
specific domain contains “tables” that “manage” the VCPUs
and event channels of that domain—the implementation even
allocates space for event channels through their domain struc-
ture. So it would seem natural to make domains the defin-
ing entity. However, in the implementation, event channels
refer to VCPUs and domains. VCPUs refer to domains as
well. This mutual dependence between key components is a
common feature within kernel design (e.g., a similar depen-
dency exists for the seL4 kernel). Some hypercalls do not
have a parameter for the applicable domain, but determine
it internally, from the scheduler. We have tried to reflect this
structure in the specification as much as possible, as they are
essential relationships to be captured.
The first step in doing this is to define identifiers for
domains, VCPUs, and event channels. Then we define for
each specific component state schemas name as: Domain,
VCPU, and Evtchn. Triangular references, e.g., VCPU to
domain to event channel to VCPU, are addressed by hav-
ing identifiers to the appropriate entity in the referring state
schema. These specific state space schemas are then pro-
moted (e.g., using Z state promotion [32, Ch. 13]) into a
general state space schema HypState containing functions
dmns, vcpus, and evtChns that uniquely identify the respec-
tive entities for the hypervisor. Such mutual dependence is
quite common in kernel design, since we are mostly always
working without recourse to any defined entity.
An interesting complication occurs because a specific
Domain state must contain “tables” of event channels and
VCPUs, from the global state. Update of a specific local state
then appears to be changing the global state, e.g., evtchn =
evtchn ⊕ {p! → local evtchnID }. That is, the after state
of the event channel table (evtchn ) is the original state
123
 L. Freitas, J. McDermott

(evtchn) updated on a nondeterministically chosen mapping require signed words.

between a port number p!, which is also an output, and the
(local evtchnID ) local event channel id. On the other hand,
BIT == 0 . . 1
from local operation schema on event channels, it appears to
WORD == { w : N →
 BIT | ∃ n : N • dom w = 0 . . n }
be updating global state since the function evtchn maps to
event channel identifiers from the global state. However, at
this local level, no more is said than necessary about event With this definition, which is close enough to the Z definition
channel identifier. Conditions relating the specific operations for sequences, we prove useful rewrite rules like
on a specific state’s evtchn function to the global state are
given in the corresponding framing or generalisation schema, WORD ∈ N →
  BIT
as usual in Z promotion, when these local state operations ∀ w : WORD • dom w = 0 . . # w − 1
update the global state where they belong. For instance, a
typical example of promotion is a system like a simple mail That is, a word is a finite partial function (→)
  with domain
server, where the global state control system-wide opera- from 0 to its size minus 1. These lemmas are very important
tions regarding user mailboxes like creation of a new user to make proofs about WORD smooth.
account, whereas the local state are user-level operations on Fundamental data types from the x86 64 hardware and
their mailboxes like sending or receiving an email. Thus, C programming language are defined as words of specific
when a user-level operation is promoted into the global state, size. (Recall that Xenon code is restricted to 64-bit imple-
it gets “framed” into the specific user mail box. A similar, mentations.) We also define a type Bound to be used in places
yet slightly more complicated approach, is taken here to pro- where the implementation is using boolean-valued functions
mote VCPUs and event channel updates within Domain and for decision making.
the global hypervisor state—in a way, Xenon has a kind of
double-layered promotion.
As in the Xenon implementation, the operations on a Byte == { w : WORD | # w = 8 }
specific state are not cleanly organised into operations on Word == { w : WORD | # w = 16 }
either VCPUs, event channels, or domains. Instead, for each Doubleword == { w : WORD | # w = 32 }
hypercall, an operation on the specific state affected by that Quadword == { w : WORD | # w = 64 }
hypercall is built up from local-state schemas partially defin- Unsigned == Doubleword
ing each aspect of the operation. This state-specific hypercall UnsignedLong == Quadword
is then promoted or generalised, to relate it to the general state Bound == {0, 1}
of the hypervisor process, accordingly.
Other functions about least and most significant bits for
3.3 Programmer’s model endianness calculations are also defined, and omitted here
for simplicity.
This section contains types and other definitions for the
underlying hardware, as seen by the Xenon programmer. It
3.4 Hypercall interface
also provides types and definitions for constructs and arte-
facts provided by the C programming language, as defined
The hypercall interface is modelled using Circus channels.
by gcc 4.4 using the std=gnu99 flag. This program-
Like its parent Xen, the Xenon hypervisor interface has a
mer’s model defines the hardware details that are exported to
“signature” comprising a collection of hypercall operation
the hypervisor interface. As we discussed earlier, all of the
codes and hypercall parameter structures. The hypercalling
bits, bytes, and words provided by an x86 64 instruction set
domain is an implicit parameter, defined by the VCPU cur-
processor must be exported to the “user” interface, i.e., the
rently scheduled to run.
hypercall interface. Rather than define these as we go, we
The first step in defining the Circus channels of the
encapsulate them into the programmer’s model section, to
hypercall interface is to define the types of the values that are
increase modularity in our specification. We shorten some of
communicated by the Circus channel events.12 The val-
the specification names in the paper to save space.
ues communicated through the hypercall interface include
We begin with basic bit and byte-level data types. A
domain identifiers, VCPU identifiers, and event channel port
unsigned word is defined as a partial function (→), rather
than as sequence, so that the least significant bit (LSB) is
at position 0.11 This version of the specification does not 12 Xen virtual interrupts are called event channels, whereas Circus
channels are modelling devices used for synchronisation purposes
11 Z sequences have 1-based indexes. between guests and the hypervisor processes.

123
Formal methods for security in the Xenon hypervisor

numbers. The hypercall interface also includes “operation MAX EV TCHNS, DOMID SELF : N
codes” or “sub-command” names. For example, there is only MAXdomID, MAXvcpuID : N
one hypercall covering event channels, but each event chan- MAXevtchnID, MAXhypercallOP : N
nel hypercall has a parameter that determines the specific
MAX EV TCHNS = 4096
operation that is performed by the event channel hypercall,
DOMID SELF = 32752
e.g., allocate an event channel, close an event channel, send
MAXdomID ≥ 2 ∧ MAXvcpuID ≥ 6
on an event channel, etc.
MAXevtchnID ≥ MAX EV TCHNS ∗ MAXdomID
We define unique identifiers for domains (i.e., Xen and
MAXhypercallOP ≥ 11
Xenon term for virtual machine), VCPU’s (i.e., a virtual
machine can have more than 1 VCPU), and event chan-
nels. In the implementation, VCPU identifiers are not unique We define “types” for the domain, VCPU, and event channel
outside of a specific domain, but we do not specify that. identifiers, and hypercall operation codes. We add constants
DOMID SELF is a constant for self-reference when the for specific VCPU identifiers to be used in renaming. We also
hyper-caller does not know its domain ID. The value of define the port number type, based on MAX EVTCHNS.
this constant is taken from the implementation; no domain
has this value as its recorded domain identifier. We have an DomID == 0 . . MAXdomID
axiom about the lower bound of domain ids (MAXdomID), VCPUID == 0 . . MAXvcpuID
since we need to have at least three domains. Domain0 EvtchnID == 0 . . MAXevtchnID
(dom0) is a trusted guest outside the hypervisor that serves HypercallOP == 0 . . MAXhypercallOP
as the management interface to the actual hypervisor. It is PortNumber == 0 . . MAX EV TCHNS − 1
allowed to perform security privileged hypercalls. That is,
any hypercall made by dom0 will be allowed access, whereas and some specific operation codes
some hypercalls made made by unprivileged guests will
be disallowed. Unprivileged guests (or user domains, say doEvtchnAllocUnbound : HypercallOP
dom1 . . domMax) are for user operating systems. In prac- doEvtchnBindInterdomain : HypercallOP
tice, the number of guests is an important factor for the sca-
lability of the technology and its importance to industry. For
3.5 Error codes
example, dom0 can make event channel hypercalls to cre-
ate and link event channels to arbitrary domains, including
Xen and Xenon hypercalls use error codes based on the
itself. Unprivileged domains can only send and receive via
Linux definitions. We also follow the Linux/Xen practice
their event channels. Domain zero is created by hand, so to
of reporting success as the “error” rcok. We include some
speak, in the Xen boot code. Other domains are then cre-
of them here to support documentation of errors reported by
ated by dom0, as requested through its trusted user inter-
the hypervisor interface. This definition assumes values as
face.
found in the header file errno.h. A complete discussion
We establish the maximum number of event channels
of what file precisely constitutes the effective errno.h is
per-domain here because event channels are referenced in
beyond the scope of this specification.
the domains by their port number, thus making event ids
known to the hypervisor only. Notice that even though
the maximum number of event channels for a domain is RC ::= rcok | eperm | enoent | esrch | enomem
defined as MAX EVTCHNS, we need at least that many | eexis | einval | enospc | emediumtype
event channels for each domain because port numbers are | xsmAccessDenied
not unique outside a domain. That is, the same port num-
ber 1 . . MAX EVTCHNS can be used in more than one This version of the specification combines XSM error codes
domain, but the event channels in each domain are unique to with the error codes in errno.h.
that domain. Duplex communication between two domains
requires two event channels, one for each direction, where a 3.6 Hypercall parameters
per-domain port number is associated with each end of each
channel. Each domain’s view of its channel’s remote port Hypercall parameters are passed as “lists”, and they are
number must be consistent with the remote domain’s view described by finite functions. Each hypercall has its own
of its local port number for that same channel. To repeat for specific parameter structure. We use a single parameter list
clarity, the hypervisor can “see” the two event channels, with type to simplify the channel structure. Since Xenon has well
one event channel in each domain, but the domains can only over 200 hypercalls, per-hypercall channel types would be
see the port numbers. unwieldy.

123

Since each hypercall will contain different types (e.g.,
domain IDs, port numbers, grant table handles, memory allo-
cation sizes, etc.), in different positions on the list, we do not
want to apply too much type structure to the parameter list
elements per se. We do limit the size of the possible parame-
ters, yet present them here with a specific limit to the size of
parameter lists.
MAX HCParam : N
MAX HCParamList : N
MAX HCParamList = 128
Given a bound, we define the type.
HCParam == 0 . . MAX HCParam
The current Xen/Xenon code uses no more than five param-
eters for a hypercall, but a formal specification may need
auxiliary parameters. We define the “parameter list” type as
a finite function, with a maximum list size of 128. We used
(p = ∅) instead of (# p > 0) to avoid finiteness proofs
involving set cardinality (#).
HCParamDom == 0 . . MAX HCParamList
HCParamList ==
{ p : HCParamDom →
  HCParam | p = ∅ }
The implementation’s evtchn_alloc_unbound.c
hyper call has three parameters: the local domain and remote
domain IDs as input, and the number of the allocated event
channel port as an output We define these parameters as spe-
cific “lists”. As these lists are reused across various points,
we have a general type to represent all of them, followed by
appropriate type-aliases.
evtchnParamIN == 0 . . 1 → HCParam
evtchnParamOUT == 0 . . 0 → HCParam
evtchnAllocUnboundParamOUT == evtchnParamOUT
evtchnAllocUnboundParamIN == evtchnParamIN
3.7 Xenon security modules
Besides the proof labels used to show that high informa-
tion does not flow into low domains, there are two signifi-
cant structures: the scheduler schemas, and the Xen Security
Modules (XSM) functions. The scheduler does not model
a complete Xen scheduler, but merely generates the com-
plete set of Circus traces. Xenon’s actual scheduler is com-
plex; too complex for this initial version where our chief
concern is discovering a way to verify the security of the
interface with respect to non-interference in the context of
123
L. Freitas, J. McDermott
(local-)state updates. We are working on a version of the
specification to include a scheduler that faithfully captures
implementation issues in the scheduler. Xen Security Mod-
ules is a policy decision point in the Xenon internals; if Xenon
is configured to allow some information flows, it checks a
requested hypercall to see if the it should be denied, accord-
ing to the configured information-flow partial order. XSM
supports complex configurable policies. A complete speci-
fication would model this. In our specification, XSM has a
fixed policy, as described in Sects. 3.7.1, 3.7.2, and 3.7.3.
Recall that Xenon (and its parent Xen) by default enforce a
strong no-flow policy, without XSM. We need to add XSM
to not only check that allowable flows happen as configured
but also that the XSM mechanism does not introduce nonde-
terminism. In practical systems, the introduction of a secu-
rity feature can, through unintended consequences, make the
overall system less secure. Formal methods help to rule out
these unintended consequences.
The security properties of the specification depend on
being able to partition events into classes between which no
information should flow. Following tradition and with no loss
of generality, we name these classes High and Low. Part of
our scaffolding is the free type PROOF LABEL that defines
these labels.
PROOF LABEL ::= Low | High
Values of type PROOF LABEL are used as types of chan-
nels, to label the (Circus) events of our specification, which
will form the system traces.
AllLbl, HighLbl : P PROOF LABEL
AllLbl = {Low, High} ∧ HighLbl = {High}
Security labels do not appear in the hypercall parameters of
the implementation, but are implicit. These labels are part
of the communication protocol through the hypervisor chan-
nels. We make them explicit in the specification because they
are used later for proofs about security.
3.7.1 Xen security modules
Xen Security Modules (XSM) provides a substantial portion,
but not all of the security enforcement mechanisms for both
Xenon and its parent Xen. XSM offers a choice between two
mechanisms: XSM proper, which functions like the secu-
rity enhancements of SE Linux; and Access Control Module
(ACM), which functions like security models such as the Chi-
nese-walls model or a type-enforcement non-discretionary
access control model [31]. XSM policy decisions are imple-
mented as C function calls at key points in the Xenon imple-
mentation. There is one function for each security decision
Formal methods for security in the Xenon hypervisor
that must be made inside the hypervisor. Security (yes-or-
no) decisions are based on the (usually pairs of) identifiers
of the domains involved in a request. Our specification fol-
lows the same approach, defining one function for each policy
decision that must be checked. This function-based approach
can model either IBM’s Access Control Module [31], or
NSA’s Xen Security Module [6]. Instead of defining a func-
tion directly, as one would do in a HOL-like theorem prover,
we use a relational space approach, which is more tuned to
the set-theoretical notions in Z and the Z/Eves prover, as this
makes proof easier (e.g., descriptions are closer to what the
tool at hand handles well). We begin our (fixed) example
description of security by defining a space of domain identi-
fiers of interest. These are all the reflexive domains (i.e., secu-
rity is not breached by a domain requesting a virtual interrupt
for itself); all the domains can make requests to the security
priviledged control domain (dom0). Finally for the sake of
our explanation, we make our notion of security for other
allowed domains quite lenient: it only imposes that between
two different domains, the target domain (t) is not the privi-
leged control domain (dom0), as this already covered by the
basic domains. These are composed together using set the-
ory to make the minimum relationships of domains covered
by the XSM as the enabled (basic and reflexive) domains,
together with other domains. This abstract notion of security
gets rather trickier at (high-performance) C code-level!
REFLEXIVE == (λ s : DomID • s)
BASIC == (λ s : DomID • 0)
ENABLED == REFLEXIVE ∪ BASIC
OTHER == {s, t : DomID | s = t ∧ t = 0}
MIN XSM == ENABLED ∪ OTHER
Now we can define spaces of valid XSM security policy deci-
sion functions, one space for each XSM security decision
check, where such functions must cover at least the (rather
larger) minimum number of XSM domain pairs related. They
are all those (boolean-)functions from a pair of domain to
the configured security policy decision space, i.e., 0 or 1;
the requested operation is either not permitted or is per-
mitted. An alternative, even more set-theoretical version of
these functions could be constructed by having sets alone,
instead of boolean-functions (xsmFcn (d0, d1) ∈ { 0, 1 }),
where set membership ((d0, d1) ∈ xsmFcn) could dic-
tate whether the given pair of domains are allowed or not.
Although this would make proofs in Z easier (e.g., mostly
because one does not need to worry about function appli-
cation within their allowed inputs), it would diverge too
much from the implementation that does use boolean-func-
tions and hence we keep them here. To circumvent the extra
proving incurred by this, we need to add a collection of
rewrite rules, which are quite simple easy, if laborious to
prove.
3.7.2 XSM check allocate unbound event channel
For the allocation of unbound event channels, defined later
in Sect. 3.14 (see schema EvtchnAllocUnboundSuccess), the
XSM policy permits the hypercall (e.g., returns 1) if the
requester is either domain ID zero, the hypervisor itself, or
the request is for a loopback channel (i.e., a domain request-
ing a virtual interrupt for itself). For every other domain
known within this XSM security policy space, the hypercall
request is denied (e.g., returns 0). A request for an unpriv-
ileged domain to allocate an unbound channel destined for
another unprivileged domain is denied. What we want is a
partial order over all domains except domain zero, such that
none of the domains are related (x < y), as in the example in
Sect. 2). Essentially, this is XSM duplicating here a built-in
policy. Apart from domain zero, no two domains are allowed
to flow information. This is a good configuration for proving
that XSM, as a mechanism, does not introduce nondeter-
minism. In the definitions presented here, only the dom0 is
considered a privileged domain. Other security policies may
want to relax that restriction by defining appropriate domain
relation spaces accordingly. We define a function space for
this policy below
XSM EV TCHN ALLOC UNBOUND ==
{xsm : DomID × DomID →  Bound |
MIN XSM ⊆ dom xsm
∧ (∀ src : DomID • xsm(src, src) = xsm(src, 0) = 1)
∧ (∀ pair : dom xsm ∩ OTHER • xsm pair = 0)}
Now we can use the function space to axiomatically define
our XSM decision point for allocating an unbound event
channel as one of such functions, so long as it covers at least
the minimal XSM domains of interest.
xsmEvtchnAllocUnbound :
XSM EV TCHN ALLOC UNBOUND
MIN XSM ⊆ dom xsmEvtchnAllocUnbound
For these definitions we prove a theorem that such instances
exists. For that it is enough to show that they are non-empty,
which is trivially true given the definitions.
3.7.3 XSM check bind inter-domain event channel
In this version of the interface specification, we do not
model the full bind interdomain check because it is so com-
plex, i.e., the actual code-level function has a signature of
DomID × PortNumber × DomID × PortNumber →  Bound.
Temporarily, for the purposes of our explanation, we describe
123

it with the same check as the functionality for unbound
channels above.
XSM EV TCHN BIND INTERDOM ==
XSM EV TCHN ALLOC UNBOUND
Similarly, now we can use the function space to axiomatically
define our XSM decision point for binding an inter-domain
event channel.
xsmEvtchnBindInterdomain :
XSM EV TCHN BIND INTERDOM
MIN XSM ⊆ dom xsmEvtchnBindInterdomain
Again, we need a proof that such choices are significant
(e.g., these spaces are not empty).
3.8 Hypervisor channels
The actual Circus channels that organise the events of the
Xenon interface specification provide both synchronisation
and hypercalling. Synchronisation is provided by a spe-
cial channel that marks the advancing computation of the
hypervisor. This scheduling channel is not part of the hy-
pervisor implementation, which advances computation via
the hardware clocks of its CPU’s, but a construction that
allows us to make the interleaving of the hypervisor and its
guests visible. Hypercalling is modelled using the types we
have just described above. The scheduling channel cpu will
be used to “control” or define when a guest is executing.
In the description of the guests, actions will be restricted
to only have an effect when the value of cpu matches their
own domain ID. We define a channel set for the scheduling
channel to facilitate organising the synchronisation proto-
col of top-level compound Circus processes of our specifi-
cation: it characterises all communications through channel
cpu (e.g., cpu.dom0, . . . , cpu.n).
channel cpu : DomID
channelset cpuChanSet == {| cpu |}
There are two hypercalling channels, hyp to model “passing
in” opcodes and IN parameters and another, ret, to model
“returning” a status code and the OUT parameters. Both
hyp and ret have corresponding “sub-channels” for High
as highhyp and highret. These channels are organised into
corresponding channel sets for construction of the top-level
123
L. Freitas, J. McDermott
compound Circus processes.
channel hyp : AllLbl × HypercallOP × HCParamList
channel highhyp : HighLbl × HypercallOP × HCParamList
channel ret : AllLbl × RC × HCParamList
channel highret : HighLbl × RC × HCParamList
channelset HCInterface == {| hyp, ret |}
channelset HighHCInterface == {| highhyp, highret |}
channelset HypervisorInterface ==
HCInterface ∪ cpuChanSet
channelset HighHypervisorInterface ==
HighHCInterface ∪ cpuChanSet
3.9 Parameter schemas
Given our set of channels, we need to connect them to the rich
encapsulated state of the Circus processes that drive them.
In the Xenon specification, we use schemas as parameter
sets for hypercalls in order to organise large specifications,
where parameters have certain expected restrictions and co-
relations (i.e., a precondition characterised by the parameter
schemas invariants). Parameter schemas are similar to the
framing schemas of Z [32, Ch. 13], used to promote local
state. Instead of promoting specific operations to the global
state, by schema conjunction, parameter schemas relate the
global process-encapsulated state of a Z operation schema to
the Circus channels of its enclosing Circus process. As in
the case of promotion, schema conjunction is used to connect
the parameter schemas to their processes.
Hypercall parameters are “passed” in and out by the
parameter “list” variables. The channel parameters schema
below describes the relationships between external Circus
action variables and the internal Z variables of the hypervisor
state. Local and remote domain identifiers are passed in; the
port number is passed back and a result code is “returned”.
Values of param in and param out are set deterministically
by actions of the appropriate parameterised guest process
Guest (d) (see Sect. 3.16). The value of result code will be
established deterministically by an internal hypercall oper-
ation schema of the Hypervisor process (see Sect. 3.10).
A concrete example from the Xenon specification is given
next to clarify this.
paramsEvtchnAllocUnbound
lDomID?, rDomID? : DomID
param in : evtchnAllocUnboundParamIN
p! : PortNumber; result code, rc! : RC
param out : evtchnAllocUnboundParamOUT
lDomID? = param in 0 ∧ result code = rc!
rDomID? = param in 1 ∧ param out 0 = p!
Formal methods for security in the Xenon hypervisor
A guest wishing to allocate an unbound event channel passes
in a local and a remote domain ID as param in, via channel
hyp, and the hypervisor returns the port number of the newly
allocated event channel via channel ret, as param out. For the
internal operation, the parameter schema relates param in to
the internal variables lDomID? and rDomID?. The parameter
schema establishes a similar relationship for the result code
and param out.
3.10 Hypervisor process
Once its channels are defined for external communication,
we can specify the state-rich internals of the hypervisor pro-
cess. In the process definition shown here, we depart from
the order used in the specification. In the specification, the
part represented by the first ellipsis (…) is several pages of Z
specifications of the hypervisor internal state, as we will pres-
ent shortly. Near the end of the process definition, as organ-
ised in the specification, we would find the Circus action
Run, as defined immediately below. Action Run synchronis-
es on a cpu “tick” (e.g., a communication of channel cpu in
the process’ trace), then schedules another guest operating
system to perform one hypercall. Finally, the effects of the
requested hypercall are given by the external choice action
with the second ellipsis. Next in our paper’s presentation we
see the main anonymous action (following the •), in this case
(startXenon) ; Run.
process Hypervisor =  begin
. . . Run =

cpu.currDom −→ ( Schedule );
( doEvtChnAllocUnbound 
doEvtChnBindInterdomain 
. . . doNMIop ) • (startXenon) ; Run
end
The main action, characterising the process behaviour, initi-
alises the state,13 then executes Run, which offers an exter-
nal choice of the hypervisor’s interface to guest domains or
scheduling of VCPUs. All these actions in turn call back to
Run recursively.
Now that we have an overview of where we are going; we
return to the normal order of exposition as used in the specifi-
cation. Following typical Circus practice, we define internal
state and internal actions14 for the hypervisor process. We
introduce the event channel state space first. Event channels
are managed on a per-domain basis, by including event chan-
nels in the state space of Xen domains. We describe the states
an event channel can be in as its event channel states (ECS).
13Recall that schemas can be “casted” as actions. This is syntactically
marked by the fat-parenthesis around startXenon.
14 Circus actions are just like CSP processes, but local to the process
they are defined in.
ECS ::= ECS FREE | ECS RESERVED
| ECS UNBOUND | ECS INTERDOM
| ECS PIRQ | ECS VIRQ | ECS IPI
Now we define the event channel (or virtual interrupt) state
space. All kinds of event channels have some common state
space: a unique identifier for event channels (evtchnID); the
port number of this event channel (portNumber); the event
channel (ECS) state; a couple of (boolean) flags about the
channel being used to send events to the hypervisor or
not (consumerIsXen), and if the channel is supposed to
notify a VCPU other than the first VCPU of a Xen domain
(notifyVCPU); and two remote IDs used by the other end of
an attached channel for the port number (remotePort) remote
domain (rDomid).
Evtchn
evtchnID : EvtchnID; notifyVCPU : VCPUID
state : ECS; consumerIsXen : Bound
remotePort : PortNumber
rDomid : DomID
remotePort ≤ MAX EV TCHNS − 1
Note that port numbers are not unique to the hypervisor,
but unique to a given domain, where in the implementation
event channels are distinguished by domain and port number
pairs. In the specification, they are distinguished by unique
evtchnID, which is to be refined into such pairs later. Some
hypercalls operate on more than one event channel at a time.
To clarify the behaviour of these hypercalls, we provide a
shorthand for the local channel and a second schema, to play
the role of the remote channel. For example, we have
localEvtchn =  Evtchn[ localEvtchnID/evtchnID,
localState/state, localRemotePort/remotePort,
localConsumerIsXen/consumerIsXen,
localNotifyVCPUID/notifyVCPU,
localRemoteDomid/rDomid ]
We have a similar renamed schema for remoteEvtchn. We
introduce the specific virtual CPU (VCPU) state space next.
Xenon uses its VCPU state space to virtualise CPUs for its
guests. Currently, we do not model the entire VCPU state,
but only a subset necessary to represent event channel oper-
ations, as described in this paper. Like its parent Xen, Xenon
supports up to 32 virtual CPU’s per domain. The scheduling,
or run states of a VCPU are also explicitly given.
MAX VIRT CPUS == 32
Runstate == 0 . . 3
123

There are four VCPU states as either: running, runnable (or
ready), blocked (or suspended), and offline. A specific VCPU
contains the following state: the identifier of the VCPU
(vcpuID); the (vcpuDomain) domain corresponding to this
VCPU; the run state of a VCPU (runstate); the polling status
as positive number indicating a single port is being polled,
zero indicating no polling, and a negative number indicat-
ing multiple ports might be polled; and a couple of sets of
port number used by the hypervisor (evtchnUpcallPending)
or the guest (evtchnUpcallMask). The first set is used by the
hypervisor to tell the guest that a virtual event is pending.
This occurs by placing the relevant port number in the set. A
guest would “clear” the event by removing the port number
from the set. Similarly, the evtchnUpcallMask set is used by a
guest to block or mask off virtual events for a particular event
channel: when the port number appears in the set, the hyper-
visor (VCPU) will not perform any upcall to the domain for
that virtual event.
VCPU
vcpuID : VCPUID; vcpuDomain : DomID
isRunning : Bound; runstate : Runstate
pollEvtchn : {−1, 0, 1}
evtchnUpcallPending : P PortNumber
evtchnUpcallMask : P PortNumber
Some the state components are hidden; these include the
hardware CPU that this VCPU has “affinity” for, a struc-
ture that records guest notification state for events, a set of
corresponding Xen domain per VCPU (implemented in Xen
and Xenon as a list), and so on.
Next, we introduce the specific state of a Xenon domain
(or a virtual machine or OS), again from the various mem-
bers of its underlying C implementation. A domain contains
the following: a unique domain identifier (domID); a couple
of tables for VCPUs (vcpu) and event channels (evtchn); a
couple of flags determining if the domain is privileged
(isPrivileged) or if the domain is running as a “hardware
virtualised machine” (HVM) for the guest (isHVM), which
has consequences on what hypercalls and instructions are
allowed; and a pollMask used to record the VCPU’s that are
currently polling. Note that the privileged flag is not part
of the Xen Security Modules (XSM) state. As for VCPU,
some components are hidden here, such as a record of the
number of pause operations that have been applied to this
domain, and so on. Event channels are kept in domains, rather
than VCPUs because events may be sent to more than one
VCPU, and because event channel policies are enforced on
a per domain basis, and hence are part of the Domain state
invariant. On the other hand, domain ID uniqueness and other
scheduling features are system-wide and hence specified as
part of the hypervisor global state, where the overall set of
123
L. Freitas, J. McDermott
EvtchnID forms a partition15 within all known domains, and
this requires extra constraints per domain in the hypervisor.
To increase proof modularity and reuse, we separate each
constituent part of a Domain using the Z schema calculus, and
later prove the compartmentalised version to be equivalent to
the complete expanded definition. This is important to make
proofs about event channel operations within a domain with
respect to the hypervisor global state (i.e., the specification
refactoring performed is tailored for proofs, yet represents the
same artefact). Without such refactoring, proofs get consider-
ably large (e.g., about 40 page-long formulae!) with too much
(unnecessary) details exposed. We expect such “specification
pattern” (or refactoring) to be a post-facto device created by
proof experts, rather than the programming-expert team mod-
elling Xenon at first. That is, Xenon engineers are expected
to come up with something close to the DomainExpanded
schema described below, and only when necessary (likely
because of unwieldy proofs), a theorem proving expert—or
indeed the engineer herself—would apply such refactoring.
Thus, the equivalence proof between each version is impor-
tant to make sure expert attempts at easing the burden proof
do not compromise the artefact being proved.
For ease of explanation we present this process the other
way round by presenting the refactored Domain state at first.
We start with the Domain state components, as described
above, but now with their types.
DComponents
domID : DomID; pollMask : Unsigned
isHVM, isPrivileged : Bound
evtchn : PortNumber  EvtchnID
evtchnInfo : EvtchnID →  Evtchn
portnoInfo : PortNumber →  Evtchn
vcpu : VCPUID →   VCPU
The table of events (evtchn) is a total injective function ()
mapping all ports to specific EvtchnID, uniquely. The num-
ber of event channels is fixed to the number of ports, since the
evtchn map is a total injection from PortNumber. This ensures
event channel IDs are unique per domain, yet port numbers
may be reused across domains. For ease of proof later, we add
a redundant component to the specification in order to extract
Evtchn state information given a PortNumber (portnoInfo)
rather than EvtchnID as partial functions (→);
 this indirection
is present at the implementation using pointers to correspond-
ing structures. Similarly, to keep event channel information
known to this domain we have evtchnInfo, which maps known
EvtchnIDs to their corresponding Evtchn state. This redun-
dancy came up during proofs involving hypervisor domains
15 A partition of a (finite) set of sets ensures that each element is pair-
wise disjoint with all other sets in the partition (e.g., no set has elements
in common), and that their distributed union covers all elements.
Formal methods for security in the Xenon hypervisor
and event channel ports, since various event channel opera-
tions within domains depend on port numbers, which is what
the user knows, rather than EvtchnID that are internal to the
hypervisor. We are currently working on a model for point-
ers that would characterise this indirection more precisely.
This is a nice example where taking up a proof exercise of
this scale promote general solutions for other problems. The
table of VCPUs is specified as a finite partial function (→).

All maps are finite in the implementation, yet we keep
these explicit at the specification only when necessary dur-
ing proof. Otherwise, one could get unnecessarily more com-
plicated proof obligations. In this sense, the specification is
weaker than the implementation and hence easier to achieve.
If during the modelling we need to use finiteness proper-
ties, it would require a stronger specification where the prop-
erty is would then be necessarily explicit, like in the case
of VCPUs. With the state components, the basic properties
about domains are given next. They include trivial restrictions
over DomID, and the number of VCPUs a domain can map.
DBasic
DComponents
domID = DOMID SELF
dom vcpu ⊆ 0 . . MAX VIRT CPUS
The hypervisor never assigns the DOMID SELF value to a
domain identifier. The special value DOMID SELF is used
by hypercallers (i.e., guest OS outside the hypervisor) when
they want a hypercall to apply to themselves and they do
not know their own internal identifier. An example for event
channels would be a hypercall to make an event channel
loop back to the same domain, as an interdomain connec-
tion. The number of virtual CPU’s is bounded and hence
the need for it to be finite. We avoided using set cardinal-
ity as in # vcpu = MAX VIRC CPUS because this leads
to much more complicated (inductive) proof obligations, yet
represents (a weaker version of) the invariant needed that
vcpu is bounded. When performing some proofs later, we
make the bound smaller, say to two VCPUs rather than
MAX VIRT CPUS (or 32) per domain as in the implemen-
tation, so that existential-quantifier witnesses are simpler for
the vcpu table, like vcpu = {3 → vcpuX, 7 → vcpuY }.
We need to enforce VCPU state properties regarding
mutually agreeable identifiers, given included domain com-
ponents. That is, all VCPU ids mapped in a Domain must
have the same internal VCPU.vcpuID; and all domain id
of a VCPU must match the current domain id. That means
VCPUs are unique per domain and that dom vcpu collects
all VCPU ids under consideration. Also, all mapped VCPUs
“know” which domain they are coming from via the consis-
tent VCPU.vcpuDomain as the current domID.
DVCPUProperties
DComponents
∀ vID : dom vcpu • (vcpu vID).vcpuID = vID
∧ (vcpu vID).vcpuDomain = domID
For all VCPUs, this links each VCPU to its domain of
use and hence establish consistency between VCPU and
Domain ids. Moreover, the invariant enforces uniqueness of
VCPUIDs across domains (e.g., VCPU state is injective on
their VCPUID field only) and allows us to prove the fol-
lowing consistency lemma as a rewrite rule: assuming these
domain properties for VCPUs, all VCPU states with the same
VCPUID are identical.
Theorem disabled rule lDomainVCPUConsistency
∀ DVCPUProperties • ∀ i, j : dom vcpu •
i = j ⇒ vcpu i = vcpu j
We need a similar property mapping for Evtchn state
within domains and their internal Evtchn.evtchnID. A set of
similar rewrite rules as above is also proved. They are crucial
in order to perform proofs about event channels and VCPU
information for domain operations in the hypervisor. More-
over, the VCPUs that require notification (e.g., notifyVCPU)
by that event must be known within the VCPUs of a domain.
and similarly for the Evtchn.remotePort of an event within
the evtchnInfo map. That is, we need to define the healthy
relationship between the notifyVCPU member of an event
channel and the VCPUs of the general state. The notify
VCPU field of an event channel must be from the domain
VCPU set (dom vcpu), so that event channels are part of
some “containing” domain. Similarly, we establish consis-
tency for all remote event channels that maybe connected
within a domain, with respect to the event channel state
(evtchn). Finally, we specify the definition of Evtchn infor-
mation given a port number, rather than an event chan-
nel id. That is possible because evtchn is injective and
total.
DEvtchnProperties
DComponents
Every port association has event channel information
dom evtchnInfo = ran evtchn
Evtchn ids, notifyVCPU, and remotePort consistency
∀ eID : dom evtchnInfo •
(evtchnInfo eID).evtchnID = eID
∧ (evtchnInfo eID).notifyVCPU ∈ dom vcpu
∧ (evtchnInfo eID).remotePort ∈ dom evtchn
Evtchn state access via a port
portnoInfo = (evtchnInfo ◦ evtchn)
123

The complete state is given as the conjunction of these def-
initions. We add DComponents explicitly to the definition
in order to facilitate type-correctness proofs about the state
components. That is, we do not need to expand it in order to
access type-related information.
Domain =
 (DComponents ∧ DBasic ∧
DVCPUProperties ∧ DEvtchnProperties)
As mentioned, these and other specification patterns are
very important for ease of proof, yet not so important for
capturing the Xenon design intent. We actually produce
this specification in two stages: first, one given by Xenon
specification-oriented programmers, and a second (mostly
equivalent) version by a formal modelling expert. Other con-
straints over port number and VCPUID across domains are
enforced by the hypervisor global state. To ensure the modu-
larised, easier-to-do-proof-with version is right, we prove it
equivalent to the following expanded version. Some hyper-
calls operate on more than one domain at a time. To clarify
the behaviour of these hypercalls, we provide an alias for the
local and remote domain by renaming components accord-
ingly, similarly to what we have used in localEvtchn. We
introduce the domain identifier for the privileged dom0 that
acts as a control plane for the hypervisor. We also introduce
two unprivileged domains domU1 and domU2, for use as
witnesses in the proofs of security.
dom0 == 0 domU1 == 1 domU2 == 2
The hypervisor scheduler state takes care of uniquely queued
VCPUIDs, as well as the current VCPU and corresponding
Domain. We omit them here.
DomainExpanded
domID : DomID; pollMask : Unsigned
isHVM, isPrivileged : Bound
evtchn : PortNumber  EvtchnID
evtchnInfo : EvtchnID →  Evtchn
portnoInfo : PortNumber →  Evtchn
vcpu : VCPUID →   VCPU
domID = DOMID SELF
dom vcpu ⊆ 0 . . MAX VIRT CPUS
∀ vID : dom vcpu • (vcpu vID).vcpuID = vID
∧ (vcpu vID).vcpuDomain = domID
dom evtchnInfo = ran evtchn
∀ eID : dom evtchnInfo •
(evtchnInfo eID).evtchnID = eID
∧ (evtchnInfo eID).notifyVCPU ∈ dom vcpu
∧ (evtchnInfo eID).remotePort ∈ dom evtchn
portnoInfo = (evtchnInfo ◦ evtchn)
123
L. Freitas, J. McDermott
We prove the initialisation theorem for Domain that estab-
lished that its invariant has a model: it is feasible and not
over-constraining. We prove such theorem for all schemas
representing state parts. For Domain, the proof requires a
witness for each component, such that all the invariants
hold at the initialised state. The complete proof is not very
interesting, yet quite long because of the various layers of
structuring involved (e.g., Evtchn, VCPU, Domain, etc.). The
point, or warning, is that at some stage there is the need to
re-structure the specification in order to tailor it for proof.
That was when we refactored the expanded Domain. Nev-
ertheless, such refactoring must preserve the original inten-
tions, unless a problem is discovered in the process. Thus,
equivalence theorems between these state schemas are also
proved everywhere. This is not specific to this case study.
3.11 Scheduler state space
We provide an abstract rudimentary, but not fully functional
scheduler. This scheduler is just “scaffolding” for proofs
involving security, our major concern. It serves to define a
plausible set of traces that can be used to prove the security
of the defined hypercalls. It does not allow domains to be
removed or even paused. In a future version of this specifica-
tion, a faithful model of the real scheduler will be constructed.
The scheduler provides strict round-robin execution, because
it is covert channel free [1]. A covert channel is anything that
is being misused to flow information the wrong way. The
canonical example is to use a file lock. Malicious software
in a High domain that wishes to leak High information to a
Low domain, will lock a shared file that Low can also access.
Each time Low tries to access the shared file but is refused
because of the lock there is the transmission of one bit of
information. No bits of Low’s state space are modified, but
the lock refusal is visible to Low and thus leaks one bit.
Covert channels can be used to leak sensitive information in
otherwise strongly protected systems. Covert channels typ-
ically leave no audit trail, hence can be used undetected, to
leak large amounts of information over an extended period
of time. Practical covert channels in a hypervisor can flow
information at rates comparable to a USB connection. We
want to build a formal model to avoid exactly these kind of
covert channel attacks.
Scheduling is by VCPU as well as by domain, one rea-
son a VCPU has to “know” its domain. In our specifi-
cation, scheduling is by VCPU only, but there is still a
need to refer to the domain of the current VCPU, in order
to make sure the scheduler is not deadlocked or inconsis-
tent. A practical example of this in the implementation is
a virtual or real interprocessor interrupt within the same
domain.(e.g., there is always something scheduled). We omit
other parts here.
Formal methods for security in the Xenon hypervisor
MINvcpuPerDom : N
Scheduler
schedule : iseq VCPUID
currVCPU : VCPUID; currDom : DomID
MINvcpuPerDom ≤ # schedule ≤ MAXvcpuID
currVCPU ∈ ran schedule
The invariant bounds the amount of VCPUs by given con-
stants, and say that the VCPU currently running must be
scheduled. As an injective sequence (iseq), there can be no
repeated VCPUIDs for scheduling.
3.12 Hypervisor state space
Given the specific state space components of event chan-
nels, VCPUs, and domains, we can now define the global
state for the hypervisor process. It adds constraints that
relate the hypervisor state to its specific components. Like
with Domain, we modularise the global state as well. First,
we have the components as the Scheduler plus the various
mapping functions collecting information per domain. Func-
tion dmns lays out the promotion for future operations over
domains: that is, from a given ID, the corresponding Domain
modification is framed back into the global state.
HypComps
Scheduler; dmns : DomID → Domain
vcpus : VCPUID ↔ VCPU
evtChns : EvtchnID ↔ Evtchn
Next, we have two relations (i.e., ↔ as sets of pairs) collect-
ing all VCPUs and Evtchn per each domain known—these are
projections over domains. Later, we prove that they are injec-
tive functions and give add them as rewrite rules. We leave
them here as relations in order to avoid complex proofs about
injective function later when domain updates take place. This
is possible because, unlike with Domain.evtchn, which is
declared as injective, we do not have explicit need to use
that fact in the hypervisor’s invariant. Like for VCPU within
Domain, we have that globally Domain.domIDs are unique.
HypDomainUniqueness
HypComps
∀ dID : dom dmns • (dmns dID).domID = dID
Also, the scheduled VCPUs must be known within the col-
lected VCPUs per domain. This includes all mapped vcpus,
as well as the currently scheduled VCPU.
HypScheduler
HypComps
currVCPU ∈ dom vcpus
∀ v : ran schedule • v ∈ dom vcpus
Given domain uniqueness, all VCPU-state known to the
hypervisor can be collected as the set of VCPU mappings
within the known domains in the hypervisor state dmns func-
tion, that is the value of (dmns dID).vcpu. The identifiers of
CPU in a domain vcpu table must match the identifier used
to look them up from a domain operation: VCPUs within a
domain must agree that this is indeed the domain which owns
the VCPU. That is, vcpu returns a function from VCPUIDs
to VCPU states for every known DomID in the hypervisor.
On this set of functions we apply distributed union in order
to flatten them into a single relation, which we later proved to
be injective (e.g., vcpus belong to VCPUID   VCPU). What
makes vcpus a function is that all the VCPUIDs within each
dom (dmns dID).vcpu are disjoint,16 as enforced by schema
DVCPUProperties as part of Domain above.
HypCollectedVCPUS
HypDomainUniqueness

vcpus = { m : dom dmns • (dmns m).vcpu }
disjoint (λ i : dom dmns • dom ((dmns i).vcpu) )
This ensures no sharing of VCPUIDs across domains can
happen; hence the hypervisor state vcpus is indeed a func-
tion. Similarly, we have the same property projecting out all
event channel information within dmns. Moreover, all event
channel remote domain ids must be known globally within
dmns. Otherwise, we would have virtual interrupt requests
from domain ids unknown to the hypervisor.
HypCollectedEvtchns
HypDomainUniqueness

evtChns = { n : dom dmns •
(dmns n).evtchnInfo }
disjoint (λ j : dom dmns •
dom ((dmns j).evtchnInfo) )
∀ eEvtchn : ran evtChns •
eEvtchn.rDomid ∈ dom dmns
As before for Domain, the complete HypState is the conjunc-
tion of all its parts, where we again explicitly add HypComps
16The predicate involving disjoint says each set of VCPUID from the
Domain’s vcpu table domain (dom ((dmns i).vcpu)), for every known
domain id in dmns are pairwise-disjoint, hence share not elements.
123

in order to make proofs about the global state component
types easier.
HypState =
 (HypComps ∧ HypScheduler
∧ HypDomainUniqueness ∧ HypCollectedVCPUS
∧ HypCollectedEvtchns)
The expanded state is given next, which is proved equivalent
to the modular version.
HypStateExpanded
schedule : iseq VCPUID; currVCPU : VCPUID
currDom : DomID; dmns : DomID →  Domain
vcpus : VCPUID ↔ VCPU
evtChns : EvtchnID ↔ Evtchn
currVCPU ∈ dom vcpus
∀ v : ran schedule • v ∈ dom vcpus
∀ dID : dom dmns •
(dmns dID).domID = dID

vcpus = { m : dom dmns • (dmns m).vcpu }
disjoint (λ i: dom dmns • dom ((dmns i).vcpu) )
evtChns = { n : dom dmns •
(dmns n).evtchnInfo }
disjoint (λ j : dom dmns •
dom ((dmns j).evtchnInfo) )
∀ eEvtchn : ran evtChns •
eEvtchn.rDomid ∈ dom dmns
Besides proving equivalence between the two versions of the
global state, we also prove a feasibility (or initialisation) the-
orem for the hypervisor. This theorem is important because
it ensures that, even though the global state imposes a series
of restrictions over Domain, which imposes a series of fur-
ther restrictions over VCPU and Evtchn states, the HypState
invariant is feasible. We can find a existence-witness; hence
our set of constraints is permitting some (if many) imple-
mentations.
Now we have the complete global state invariant, we con-
centrate in proving various properties of interest it satisfies.
They include containment of domain information within the
hypervisor, like VCPUs and Evtchn. These lemmas are some-
what easy to prove, since the hypervisor state is constructed
by collecting them together. More interesting are the proofs
within the hypervisor state that dmns, vcpus, and evtChns
are injective on the known DomIDs. We have that within
Domain, vcpu and evtchnInfo are also injective. The impor-
tant aspect of these injectivity proofs is that they enable con-
sistency proofs about the hypervisor state like:
Theorem lHypStateDomIDEquiv
∀ HypState • ∀ d : ran dmns • dmns (d.domID) = d
123
L. Freitas, J. McDermott
It says, given the global state and any known Domain state
d from dmns, it is indeed mapped through its domID in the
known hypervisor domain states. With these lemmas at hand,
we can start modelling the operations, both for domains and
the hypervisor globally. These proofs are crucial as they
establish all the necessary features we need Xenon to have
when collecting available VCPUs and Evtchn in Domains,
such that all required constraints are observed. Before show-
ing an example hypercall operation, we first need to set up the
promotion schemas. They will promote local state updates to
their global correspondent. For instance, VCPU and Evtchn
updates get promoted within the Domain state they belong to.
That domain update then gets promoted into the hypervisor
global state as well. And similarly for local and remote event
channels. Some of it is presented next.
3.13 Promoting event channels
The hypervisor state does not have local (or remote) event
channels; they come from each of the hypervisor’s domains.
So, to promote event channel operations within the hyper-
visor state, we must first describe how they are promoted
at the level of domains with the next schema. It includes
before and after states for both domain and event channel.
Note this enforces the intricate invariant for event channels
mapped within domains, like remotePort and notifyVCPU,
within event channel state as related to other Domain compo-
nents. We also have two inputs for local and remote domain
ids, and two outputs for port number and operation return
code. These are pretty much like in the hypercall implemen-
tation. For the visible components involved, we use a com-
mon Z pattern that says all after state elements of Domain
remain constant (ΞDomain), except evtchn and evtchnInfo,
which may change as a result of the operation.
 ΞDomain \ (evtchn, evtchnInfo)
EvtchnDomProm =
EvtchnPromotedInDomain
ΔDomain; ΔEvtchn; EvtchnDomProm; rc! : RC
lDomID?, rDomID? : DomID; p! : PortNumber
p! ∈ dom evtchn
evtchn (p!) = evtchnID = evtchnID
evtchnInfo (evtchnID) = θ Evtchn
evtchn = evtchn ⊕ { p! → evtchnID }
evtchnInfo = evtchnInfo ⊕ { evtchnID → θ Evtchn  }
(lDomID?, rDomID?) ∈ dom xsmEvtchnAllocUnbound
The port number p! returned by the event channel opera-
tions must be known within the table of event channel ids per
port (evtchn) in a domain. This also means that the EvtchnID
Formal methods for security in the Xenon hypervisor
this port is mapped to (i.e., evtchn p!) has Evtchn information
associated with it via the mapping from ids to event channel
state (evtchnInfo (evtchnID)). For the event channel states,
we fix their ids to the id mapped within Domain(evtchn p! =
evtchnID), and their values to what is in evtchnInfo of
Domain, i.e., (evtchnInfo (evtchnID) = θ Evtchn). In Z,
θ-expressions are like self or this in the object-oriented
programming: it references the actual instance of the before
or after state at a particular point—it refers to the current
schema binding, or actual values within the labelled record.
The promotion of the event channel operation port number
returned (p!), as well as the updated event channel (after-)
state (θ Evtchn  ) into Domain, are performed by updating
each domain mapping accordingly using relational overrid-
ing (⊕). That is, evtchn p! = evtchnID ; hence no update in
event channel id happens through this promotion schema,
whereas event channel information does change to whatever
values θ Evtchn  has, given some event channel state oper-
ation using this promotion (i.e., event channel operations
cannot change event ids). The domain id input parameters
(lDomID?, rDomID?) enforce the security policy for what
local and remote domains can do with event channel hyper-
calls. This mapping is kept at the xsmEvtchnAllocUnbound
function defined earlier (see Sect. 3.7.1). The XSM policy
permits the hypercall to allocate an unbound channel des-
tined for dom0, or the request is for a loopback channel on
DOMID SELF. A request for an unprivileged domain to allo-
cate an unbound channel destined for another unprivileged
domain is denied. That is, event channel connections between
unprivileged domains (e.g., domU1, domU2, etc.) are set up
by the trusted guest domain running in dom0.
The next aspect of the promotion is to bring this event
channel state update from Domain into to the hypervisor
global state. It is defined with the next schema containing
a copy of the corresponding before and after states for the
hypervisor and domain, where only dmns and evtChns may
change in the hypervisor.
 ΞHypState \ (dmns, evtChns)
EvtDomHypProm =
EvtchnPromotedInHypervisor
ΔHypState; ΔDomain; EvtDomHypProm
rDomID! : DomID
rDomID! ∈ dom dmns ∧
rDomID! = (vcpus (currVCPU)).vcpuDomain ∧
dmns (rDomID!) = θ Domain ∧
dmns = dmns ⊕ { rDomID! → θ Domain }
The invariant clarifies that any operation using this pro-
motion schema will be for the domain id of the current VCPU
scheduled only, since this is the domain id (rDomID!) han-
dling the event channel hypercall. This value is output as
the domain id of the current VCPU (currVCPU) sched-
uled in the hypervisor. It is used as input to other pro-
moted schemas defining what to do with the hypervisor’s
selected domain rDomID!. The global state invariant guar-
antees that the domain id for the currently scheduled VCPU
is known and comes from dmns. Also, when combined with
EvtchnPromotedInDomain, there could be a relation between
the input domain ids and the domain id rDomID! handling
the hypercall request. Following the same pattern, we con-
struct layered promotion schemas for VCPU updates within
Domain and its corresponding update within HypState, as
well as specialisation of event channel promotion for local
and remote hypercall requests. These are similar and omitted
here.
3.14 Example hypercall operation schema
Like in Xen, the Xenon hypervisor has over 200 hypercalls in
its interface. These hypercalls are used to control domains,
manage the MMU, virtualise interrupts, manage VCPU’s,
manage the grant table inter-domain communication mech-
anism, and other hypervisor features. Here, we provide an
example of one hypercall that is used to manage event chan-
nels. The event channel state update gets promoted into the
domain state, which in turn gets promoted to the hypervisor
state, thus giving a complete characterisation of its effect of
event channel operations on the hypervisor’s behaviour.
Event channels “virtualise” the functions provided by
hardware interrupts, for virtual CPU’s. For example, instead
of an interrupt notifying a hardware CPU that a device has
data ready, Xenon uses events to notify selected VCPU’s in
a domain. Technically, event channels are an asynchronous
communication mechanism for notifications from Xenon to
its guests or from one guest to another. Event channels are
similar to Unix signals, but it is also possible to poll for
events that were delivered while event notification was dis-
abled. Events delivered by event channels can correspond to
physical interrupts (PIRQ events), virtual interrupts (VIRQ
events), or events sent between domains. Domain events can
be interdomain, such as events communicated by paravirtu-
alised devices, or intradomain, such as events used as virtual
inter-processor interrupts on a multicore CPU.
Event channels are indexed by a port number. Each chan-
nel has two bits of state: PENDING and MASK. When the
hypervisor sets PENDING, the Xen domain is notified of
a pending event. A guest in the Xen domain may clear
PENDING. The MASK bit is only changed by the guest oper-
ating system. If MASK is clear when the hypervisor sets
PENDING from a cleared state, an up call to the guest
will be scheduled. The Xenon hypervisor interface provides
a hypercall named do_event_channel_op with 11
123

sub-commands; so there are really 11 event channel hyper-
calls. For our example, we show the specification of one
of these sub-commands: evtchn_alloc_unbound. This
hypercall sub-command allocates an event channel bound to
the requester, with the remote-port free for later binding.
This form of the do event channel op hypercall is
made by passing a pointer to a struct that gives the requesting
domain, the remote domain, and space for the port number of
the allocated event channel. The typical use case for this hy-
percall is for the privileged guest domain in dom0, to use the
sub-command to set up an event channel from dom0 to one
of the unprivileged domains. This unbound channel is later
bound to the unprivileged domain, again via domain dom0.
As usual with Z, operations are defined by splitting (dis-
joining) successful with error cases. In normal processing,
this hypercall results in the requesting domain having its
first available event channel port set to the unbound event
channel state. The available free ports are updated to show
that the allocated port number is no longer available, and we
model it with the next schema, given the event channel state
change within the domain it belongs to. This domain will be
bound to the before state of Domain in the promotion schema
EvtchnPromotedInDomain above.
 ΞEvtchn \ (state, rDomid)
EvtchnAllocSuccCmp =
EvtchnAllocUnboundSuccess
Domain; ΔEvtchn; EvtchnAllocSuccCmp
rc! : RC; lDomID?, rDomID? : DomID
((rDomID? = DOMID SELF ∧ rDomid  = domID) ∨
(rDomID? = DOMID SELF ∧ rDomid  = rDomID?))
(lDomID?, rDomID?) ∈ dom xsmEvtchnAllocUnbound
xsmEvtchnAllocUnbound (lDomID?, rDomID?) = 1
state = ECS FREE ∧ state = ECS UNBOUND
rc! = rcok
This schema models the choice between a domain’s request
to loop an event channel back to itself, or to start a connection
to another domain. Domain identifier lDomID? is the id of the
local domain requesting the creation of the unbound channel,
where no restrictions are placed on which domain may play
the role of local domain. The hypervisor always performs
the requested operation on behalf of the requested (remote)
domain. Domain identifier rDomID? is also an input vari-
able, but again, its relation to the general state is through the
event channel “table” (function evtchn). If the input remote
domain ID is not the special value indicating “self”, then
the request is not for a loopback and the unbound connec-
tion is set up for the remote domain requested (rDomID?).
The alternative is a loopback channel, i.e., the guest needs
123
L. Freitas, J. McDermott
to send events to itself. To do this, Xenon uses the current
VCPU state (vcpuDomain) to find the actual domain ID of
the hypercalling domain. Next, is the Xen Security Modules
(XSM) check. The XSM security check is a security pol-
icy decision about allowing a connection from local domain
lDomID? to remote domain rDomID? If the value of function
xsmEvtchnAllocUnbound is 1, then the operation is permit-
ted. Finally, we have the output return code for successful
execution and the update on the event channel state compo-
nent. Note that during promotion, the right port number (p!)
will get assigned to this state change by finding one within
the evtchn mapping of port numbers. All other event channel
local state is unchanged.
Next we define one of various possible hypercall error
cases. If the XSM security policy check fails, then the hyper-
call has no effect on the event channel state; hence any effect
through the promotion schemas will lead to a unchanged
θ Evtchn  because of the ΞEvtchn used.
EvtchnAllocUnboundXSMNo
ΞEvtchn; lDomID?, rDomID? : DomID; rc! : RC
(lDomID?, rDomID?) ∈ dom xsmEvtchnAllocUnbound
xsmEvtchnAllocUnbound (lDomID?, rDomID?) = 0
rc! = xsmAccessDenied
There are other error cases. For instance, attempting to allo-
cate an unbound event channel when we cannot get a free port
will cause an error. That is, there is no port with a ECS FREE
state in the domain’s evtchn “table”. The error report is passed
back to the hyper-caller as rc! = enospc.
EvtchnAllocUnboundGetPortNoPort
Domain; ΞEvtchn; rc! : RC
rc! = enospc
¬ (∃ freePort : PortNumber •
(∃ e : localEvtchn • freePort ∈ dom evtchn
∧ e.localEvtchnID = evtchn freePort
∧ ( e.localState = ECS FREE )))
All error cases are assembled with disjunction as
EvtchnAllocUnboundFailure =

EvtchnAllocUnboundXSMNo ∨
EvtchnAllocUnboundGetPortNoPort
where the complete operation before promotion includes the
successful case with the error ones.
EvtchnAllocUnbound =
EvtchnAllocUnboundSuccess ∨
EvtchnAllocUnboundFailure
Formal methods for security in the Xenon hypervisor

This is the operation we promote into the domain and global hypervisor process state, which is marked with the state key-
hypervisor state next. It existentially quantifies the before word.
and after states of both domain and event channels, which
get captured by their declarations in the schemas involved. It
also includes the domain id (rDomID!) of the currently run- state (HypState ∧ paramsEvtchnAllocUnbound . . .)
ning VCPU in the hypervisor, which gets used as the input
domain for the the promotion of Evtchn into Domain, and
With the process state defined we can proceed to the Circus
the promotion of Domain into HypState. In that way, all pos-
actions that model the event channel hypercalls behaviour.
sible domain and event channel states that satisfy the overall
For this paper, we only provide an example action cor-
invariant characterise the global (promoted) operation.
responding to the event channel hypercall for operation
schemas presented above. Usually, the CSP within Circus
HypEvtchnAllocUnbound = 
processes provide beside the (concurrent) trace behaviour
(∃ ΔDomain; ΔEvtchn; rDomID! : DomID •
of the system and also a controller for the possible state
EvtchnAllocUnbound[rDomID!/rDomID?] ∧
update behaviour. The next step is to have a state initiali-
EvtchnPromotedInDomain[rDomID!/rDomID?]
sation schema that would satisfy the overall process state
∧ EvtchnPromotedInHypervisor)
invariant, which is feasible as we have its existence proof.
Yet, it is also possible to leave state initialisation (i.e., or in
This completes our example of how we describe the state
practice, hypervisor loading) under or weakly specified, thus
effects of key parts of single specific hypercall sub-command.
allowing the most varied possible implementations.
This specification can look deceptively simple. If one
The allocate unbound event channel hypercall action gets
expands all definitions and invariants, both of operations and
an operation code and an input parameter list from its envi-
underlying state, the schema is rather large. That necessi-
ronment. Then it allocates new unbound channel state as
tates a lot of house keeping theorems and rewrite rules about
defined by the evtchnAllocUnbound Z operation schema.
individual schemas, which is part of our model as well, yet
Finally, the action returns a result status report as variable
not as interesting to add to this explanation. The full spec-
result code (understanding that success, rcok, is one pos-
ification would have over 200 of these operation schemas,
sible result), and an output parameter list. Notice that the
and we have completed this refactoring and housekeeping
returned value has a proof label, indicating whether the action
of some of them. Another important aspect regarding proof
is High or Low. In the end, after the necessary traces and
would be to try and have free promotions [32, p. 196] when-
state updates, the action recurses back to the Run action
ever possible, as these make proofs much easier: in a free
defined above (see Sect. 3.10, and again below). This is
promotion one can prove individual schemas and the proof
important in the notion of security through non-interfer-
of their combination above is “for free” because there are no
ence extended for Circus. The parameters not related to the
inter-state dependencies. This is not the case for this example,
schema inputs/outputs are kept by other actions and state
unfortunately.
operations not presented here.
3.15 Hypervisor event channel actions
doEvtChnAllocUnbound = 
We are now ready to complete the definition of the hyper- hyp?proof label.doEvtchnAllocUnbound.param in−→
visor process. The key advantage of the Circus formalism ((evtchnAllocUnbound );
is its natural way of combining descriptions of internal state (ret!proof label.result code.param out −→ Run))
behaviour with externally visible (concurrent) trace behav-
iour. The trace behaviour of each hypercall will be defined
as an action of the Hypervisor process that will ultimately At this point in the specification, we would define the rest of
update the hypervisor state. The hypervisor state defines the hypercall actions. Instead, we proceed to the point where
the variables and schemas used by the process actions. It we define the main action that drives our hypervisor process.
also defines the parameter schemas that relate the exter- Run defines the principal structure of the hypervisor pro-
nal Circus action parameters to the Z parameters of the cess. It first schedules a domain and then waits for and per-
internal hypervisor state. The hypervisor state is defined by forms a hypercall request of, the current domain. The event
the HypState schema above (see Sect. 3.12), together with cpu.currDom has the effect of “running” the current guest,
(by conjunction of) any extra parameterisation schemas, like as the corresponding guest process actions (see Sect. 3.16)
paramsEvtchnAllocUnbound above (see Sect. 3.9). Techni- always start with a synchronisation on their own domain
cally, these could be process parameters, but since we have ID. As explained near the beginning of our description of
extra invariants over them, we add them as part of the state the hypervisor process, the external choice action selects the

123

appropriate hypercall necessary state changes.
Run =
 which domain applies. The remote domain counter
cpu.currDom −→ ( Schedule );
( doEvtChnAllocUnbound 
doEvtChnBindInterdomain 
doNMIop )
We complete the process definition with its main action that
initialises the hypervisor state and then Run’s.
• (startXenon) ; Run
end
3.16 Guests
We need a collection of Circus processes to model both
dom0 “control plane” (privileged) guest, and the untrusted
domUn (unprivileged) guests that perform computation for
the end users.
We need an untrusted guest process that is parameterised
on its domain ID. This simplifies any additions to the number
of untrusted guests.
 d : DomID • begin
process Guest =
The guest will need a corresponding state changing operation
schema and matching hypercall action trace to synchronise
with the Hypervisor process. We provide a single example
of state for the allocate unbound event channel hypercall.
We use simple counters to have our guests cycle through all
possible domain and port values.
EvtchnAllocUnboundGuestState
param in : evtchnAllocUnboundParamIN
param out : evtchnAllocUnboundParamOUT
lDomIDcounter, rDomIDcounter : DomID
localPortCnt, remotePortCnt : PortNumber
result code : RC
The parameter lists and counters must be initialised. We also
initialise the result code.
InitEvtchnAllocUnboundGuestState
EvtchnAllocUnboundGuestState 
param in 0 = param in 1 = 0
lDomIDcounter  = rDomIDcounter  = 0
localPortCnt  = remotePortCnt  = 0
result code = rcok
123
L. Freitas, J. McDermott
A well-behaved guest always requests itself as the local
domain. Notice that the hypercall uses currVCPU to decide
(rDomIDcounter) is used to request the next remote domain.
DomUallocUnboundChooseParams
ΔEvtchnAllocUnboundGuestState
vcpuDomain? : DomID
param in 0 = vcpuDomain?
param in 1 = rDomIDcounter
rDomIDcounter < MAXdomID ⇒
rDomIDcounter  = rDomIDcounter + 1
rDomIDcounter = MAXdomID ⇒
rDomIDcounter  = 0
We need the corresponding guest action for each hypercall.
For our running example, we present the allocate unbound
event channel action of the guest
hypercallEvtchnAllocUnbound =
cpu?d −→ ((DomUallocUnboundChooseParams);
(hyp!Low.doEvtchnAllocUnbound.param in−→
ret?Low.result code.param out −→ Run))
Each untrusted guest cycles through all possible requests that
it can make for itself in a similar guest GRun action.
GRun = hypercallEvtchnAllocUnbound
 hypercallEvtchnBindInterdomain  . . .
• (InitEvtchnAllocUnboundGuestState) ; GRun
end
The untrusted guests do not directly share events and

hence the use of interleave ( ) over all possible domain
ids. This replicated process synchronises with the hypervi-
sor process.
process Guests =
  d : DomID • Guest (d)
We model the collection of guests as an interleaving of
parameterised guest processes by their domain id.
3.17 Combined Xenon system
The interleaved guests now communicate as allowed by the
Hypervisor process.
process Xenon =

Guests  HypervisorInterface  Hypervisor
Formal methods for security in the Xenon hypervisor
Events shared on the cpuChanSet channel set (part of
HypervisorInterface) have the effect of limiting guests to
only executing when a real CPU is allocated to them.
3.18 Balagan adversary
For the chaotic adversary, we have the process
process evtchnBalagan =
 begin
We need a schema as the process state to provide parameter
passing variables.
evtchnBalaganState
au param in : evtchnAllocUnboundParamIN
au param out : evtchnAllocUnboundParamOUT
result code : RC
We make the schema as part of the process’ state.
state evtchnBalaganState
The intent here is that the traces of process evtchnBalagan
range over all possible sequences of input and output param-
eters over each event channel hypercalls. Here we only
show the one associated with allocate unbound. Notice that
evtchnBalagan will not “run” unless the Hypervisor process
is prepared to engage in the event cpu.domBalagan. Also, it
might simply deadlock and refuse to communicate anything,
nondeterministically.
• µ X • cpu.domBalagan−→
(Stop
As already mentioned, the whole model is over 4500 pages
hyp.High.doEvtchnAllocUnbound.au param in−→
(ret.High.result code.au param out −→ X))
end
This completes our running example of the Xenon inter-
face specification for some event channel related hyper-
calls.
This industrial example clearly shows the advantages of
Circus for describing software systems that have both com-
plex state behaviour and complex (concurrent) trace behav-
iour. The current specification does not model all of the
Xenon hypercalls, but it specifies more than we have been
able to show in this exposition.
4 Independence definition of security in Circus
Next, we define the information flow security policy we want
that needs to be proved. For that, we combine the Xenon
process with the chaotic evtchnBalagan process into a lazy
abstraction: it is the parallel composition of the hypervisor
and guest OSs with the known event channels allowed to
behave chaotically in the non-interference setting of Eq. 1.
process LazyAbstraction =

(Xenon  HighHypervisorInterface  evtchnBalagan)
\HighHypervisorInterface
If we can show that this LazyAbstraction is deterministic,
then our Xenon process is information-flow secure. We are
working on this proof at the moment.
If LazyAbstraction is deterministic then the design of our
hypercall interface cannot be exploited by a guest operat-
ing system in one untrusted domain to crash, lockup, or
gain administrative control over another guest operating sys-
tem in another domain, via shared host execution. Any of
these (compound) events could happen in the second (target)
guest, but not as a result of shared execution with the source
(attacking) untrusted guest. They would have to happen as
a result of failure within the target guest OS, as a result of
inputs to that guest from outside the hypervisor platform. If
LazyAbstraction is deterministic then the design described
by our Circus specification will also prevent direct copies of
information from one domain to another, via shared host exe-
cution and also indirect leaks due to exploitation of hypercall
features. Either of these attacks, from an untrusted domain,
would have to cause some kind of nondeterministic event
within the target Circus process.
5 Evaluation summary
of Circus, and this comes from the model extraction from the
code’s intent as also described earlier. This larger model has
been typechecked and verification conditions for parts of it
had been generated. CZT, and Z/Eves, have a simple verifica-
tion condition generator for Z, which currently extending for
Circus. Verification conditions are related to the specification
in terms of its: (i) well-formedness or domain checks that
functions are applied within their domains and ∃1 -predicates
are satisfiable; and (ii) feasibility, or precondition calculation
for all operations as well as invariant satisfiability proof for all
state (without after variables) schemas. It will include gener-
ation of refinement proofs of adequacy in the near future. We
also include a series of housekeeping lemmas, which are tai-
lored to make proof smooth within Z/Eves, where most of the
material reused here is already explained elsewhere [10,11].
For the part processed by the theorem prover, that is the
hypercalls involving event channels, we have proved both
all generated proof obligations, as well as extra housekeep-
ing for Z/Eves and properties of interest, as pointed out in
various places in this paper (e.g., some state components of
123

the hypervisor are given as a set of pairs, yet we prove this
set of pairs are an injective, 1–1 function). The specification
presented in this paper has about 89 Z paragraphs and 38
Circus constructs for CSP and their combination. This gen-
erated about 30 domain checks proof obligations, as well as
one feasibility proof obligation for every schema as either
precondition calculation (e.g., operation post states are fea-
sible) of invariant satisfiability (e.g., existence proof that the
schema invariant for various state components above is fea-
sible). This does not include the various lemmas necessary
for many of these proofs, some of which are from a cata-
log of proofs involving complex schemas started in [10], and
many other lemmas that are new, in particular those about
injective functions, which started in [11]. Lemmas for lay-
ered promotion were also needed. We got inspiration (and
reuse) from [4].
Among proof obligations for the work presented here, the
most complex were the proof of separation of the hypervi-
sor state components, as well as the non-interference proof
for lazy abstraction. This took over half-man-year of effort
spread over about one and half years. Since this is ongoing
work, we have not finished measuring the amount of time /
effort involved in these proofs. It suffices to say that we are a
team of about two proof experts, and around 2–5 kernel engi-
neers. NRL started work on Xenon a few years ago, yet we
got involved into formal modelling Xenon since late (about
October) 2008.
6 Conclusions
The Xenon project is re-engineering the Xen open source
hypervisor into a higher-assurance form, with a focus on
information-flow security. In the Xenon project, we use for-
mal specifications as both guides for re-engineering and for
assurance that the actual hypervisor enforces the desired
security policy. Our formal modelling of both the fundamen-
tal definition of security and the hypercall interface behaviour
made beneficial contributions to the re-engineering effort.
We also constructed a partial internal design specification
that was less successful, as we will explain momentarily.
To our knowledge, the Xenon project’s formal definition
of security is the first application of the Roscoe, Woodcock,
and Wulf [29] style of non-interference to kernel design. This
is significant not only because their notion is preserved by
refinement, but also because it is a well-understood definition
of security that has undergone significant external review.
The definition also subsumes the well-understood take-grant
definition [20] used by seL4 and is similar to, but more
tractable than, the non-interference definition used by MILS
systems [12]. We chose this definition because of its rela-
tive simplicity in comparison to other trace-based definitions
of information flow security [21,25]. The fact that it is pre-
123
L. Freitas, J. McDermott
served under refinement, unlike other trace-based definitions,
allows us to use the Circus refinement calculus directly,
without having to re-prove security for each refinement.
The Xenon project’s hypercall interface specification is
an industrial-scale application of the Circus formalism to
modelling an actual industrial hypercall interface. The use
of Circus allows us to refine our security definition without
the use of unwinding rules or theorems. Trace-based defini-
tions of information-flow security typically require the use of
these rules to apply the definition to state-based implemen-
tations. Unwinding rules add complexity that is not inherent
in the security problem we are trying to solve. Unwinding
rule complexity is caused by limitations in the chosen spec-
ification language. Since Circus treats both traces and rich
state, the “unwinding issues” are addressed automatically by
the definition of the language. Our specification shows how
Circus provides a powerful and natural way to describe state-
rich and trace-rich concurrent behaviour together in a single
model that is amenable to refinement calculation.
We have introduced the concept of a Z parameter schema
as a means of organising industrial scale Circus specifica-
tions. Like the concept of a Z framing schema used in pro-
motion [32, Chap. 13], a Z parameter schema is used as a
means of factoring and organising a large specification into
largely independent components. Unlike a framing schema,
a parameter schema organises and isolates the details of how
Circus channel values are related to Z variables. Changes
to these details are thus localised in the parameter schema.
Of course, the parameter schema concept only applies to
Circus, and not to Z specifications, since the latter does not
have channel communication.
Future work
We already have an abstract notion of the Xenon security pol-
icy also specified in Circus and presented in [23]. The work
reported here represents a concrete specification of the actual
Xenon code’s intent in the same formalism. We plan to apply
the Circus refinement calculus to these two models in order
to achieve a complete top-down refinement from abstract
notion of security down to its code-level implementation, for
at least key event-channel APIs. This will increase the levels
of security in Xenon in the sense that security attacks (over
the modelled and refined APIs) are ruled out by construction.
We plan to report the extent of this proof in due course. We
are also working on a proof for a model of pointers to be
used as a refinement target of the various tables used in state
schemas above.
Acknowledgments The first author is grateful for the financial sup-
port offered by Qinetiq Malvern and the National Physical Labora-
tory (NPL, UK) during some of the work with Xenon while at York.
Having recently moved to Newcastle University, he is also grateful for
the support of Cliff Jones within the EPSRC funded AI4FM project
Formal methods for security in the Xenon hypervisor
at Newcastle, who made the later stages of this work possible. Both
authors are grateful to Jim Woodcock for invaluable comments on the
extension of the CSP notion of non-interference for Circus.
References
1. Anderson, R.: Security Engineering: A Guide to Building Depend-
able Distributed Systems. 2nd edn. Wiley, New York (2008)
2. Back, R.-J., von Wright, J.: Refinement Calculus: A System-
atic Introduction. Graduate Text in Computer Science. Springer,
New York (1998)
3. Barham, P., Dragovic, B., Fraiser, K., Hand, S., Harris, T., Ho, A.,
Neugebauer, R., Pratt, I., Warfield, A.: Xen and the art of virtual-
ization. In: Proceedings of 19th ACM Symposium on Operating
Systems Principles (SOSP-19), Bolton Landing, New York, USA,
October 2003
4. Butterfield, A., Freitas, L., Woodcock, J.: Mechanising a formal
model of flash memory. Sci. Comput. Program. 74(4), 219–237
(2009)
5. Chisnall, D.: The Definitive Guide to the Xen Hypervisor. Prentice-
Hall, Englewood Cliffs (2008)
6. Coker, G.: Xen security modules. Xen Summit 2007 Presentation,
April 2007. http://www.xensource.com/xen/xensummit.html
7. The Common Criteria Project Sponsoring Organizations.: Com-
mon Criteria for Information Technology Security Evaluation,
v. 3.1, rev. 1 (edn.), September 2006. Also referred to as ISO 15408
8. The Common Criteria Project Sponsoring Organizations.: Com-
mon Methodology for Information Technology Security Evalua-
tion, v. 3.1, rev. 1 (edn.), September 2006
9. Denning, D.: A lattice model of secure information flow. Commun.
ACM 19(5) (1976)
10. Freitas, L., Woodcock, J.: Mechanising Mondex with Z/Eves.
Form. Asp. Comput. 20(1), 117–139 (2008)
11. Freitas, L., Woodcock, J.: A chain datatype in z. Int. J. Softw.
Inform. 3(2–3), 357–374 (2009)
12. Greeve, D., Wilding, M., Vanfleet, W.M.: A separation kernel for-
mal security policy. In: Proceedings of ACL2 Workshop, Boulder,
Colorado, USA, July 2003
13. Hoare, C.: Communicating Sequential Processes. Prentice-
Hall, Englewood Cliffs (1985)
14. IA-32 Intel Architecture Software Developer’s Manual: vol. 3A:
System Programming Guide, part 1. Technical Report 253668-
020US, Intel Corp., June 2006
15. ISO/IEC.: ISO/IEC 13568: Information Technology—Z Formal
Specification Notation—Syntax, Type System and Semantics
(2002)
16. Jackson, D.: A direct path to dependable software. Commun.
ACM 52(4), 78–88 (2009)
17. Klein, G., Andronick, J., Elphinstone, K., Heiser, G., Cock, D.,
Derrin, P., Elkaduwe, D., Engelhardt, K., Kolanski, R., Norrish,
M., Sewell, T., Tuch, H., Winwood, S.: seL4: Formal verification
of an OS kernel. Commun. ACM 53(6), 107–115 (2010)
18. Klein, G., Elphinstone, K., Heiser, G., Andronick, J., Cook, D.,
Derrin, P., Elkaduwe, D., Englehardt, K., Kolanski, R., Norrish,
M., Sewell, T., Tuch, H., Winwood, S.: seL4: Formal verification
of an OS kernel. In: Proceedings of 22nd ACM Symposium on
Operating System Principles, Big Sky, MT, USA, October 2009
19. Leinenbach, D., Santen, T.: Verifying the microsoft hyper-v hyper-
visor with vcc. In: Cavalcanti, A., Dams, D. (eds.) FM 2009: Formal
Methods. Lecture Notes in Computer Science, vol. 5850, pp. 806–
809. Springer, Berlin (2009)
20. Lipton, R., Lawrence, S.: A linear-time algorithm for deciding
subject security. JACM 24(3), 455–464 (1977)
21. Mantel, H.: The framework of selective interleaving functions and
the modular assembly kit. In: Proceedings of Formal Methods in
Security Engineering, Fairfax, Virginia, USA, November 2005
22. McDermott, J.: Fine-grained inspection for higher-assurance soft-
ware security in open source. In: Proceedings of 43rd Hawaii Inter-
national Conference on Systems and Sciences, pp. 1–10, Kauai, HI,
January 2010
23. McDermott, J., Freitas, L.: A formal security policy model for
Xenon. In: Proceedings of Formal Methods in Security Engineer-
ing (FMSE ’08), October 2008
24. McDermott, J., Kirby, J., Montrose, B., Johnson, T., Kang,
M.: Re-engineering Xen internals for higher-assurance secu-
rity. Inform. Secur. Tech. Rep. 13(1), 17–24 (2008)
25. McLean, J.: A general theory of composition for trace sets closed
under selective interleaving functions. In: Proceedings of IEEE
Symposium on Research in Security and Privacy, Oakland, Cali-
fornia, USA, May 1994
26. Oliveira, M., Cavalcanti, A., Woodcock, J.: A UTP semantics for
Circus. Form. Asp. Comput. 21(1), 3–32 (2007)
27. Oliveira, M.V.M., Cavalcanti, A.L.C., Woodcock, J.C.P.: A de-
notational semantics for Circus. In: Aichernig, B., Derrick,
J. (eds.) REFINE’2006, Eletronic Notes in Theoretical Computer
Science, Elsevier, Amsterdam (2006)
28. Roscoe, A.: The Theory and Practice of Concurrency. Prentice-
Hall, Englewood Cliffs (1997)
29. Roscoe, A., Woodcock, J., Wulf, L.: Non-interference through
determinism. In: Proc. ESORICS, Brighton, UK, November 1994
30. Ryan, P., Schneider, S.: Modelling and Analysis of Security
Protocols. Addison-Wesley, Reading (2001)
31. Sailer, R., Jaeger, T., Valdez, E., Cáceres, R., Perez, R., Berger, S.,
Griffin, J., van Doorn, L.: Building a MAC-based security archi-
tecture for the Xen open-source hypervisor. In: Proceedings of
21st Annual Computer Security Applications Conference, Tucson,
Arizona, USA, December 2005
32. Woodcock, J., Davies, J.: Using Z: Specification, Refinement,
and Proof. International Series in Computer Science. Prentice-
Hall, Englewood Cliffs (1996)
33. Woodcock, J.C.P., Cavalcanti, A.L.C., Gaudel, M.-C., Freitas,
L.J.S.: Operational Semantics for Circus. Form. Asp. Comput.
(2009, in press)
123