Cerise: Program Verification on a Capability Machine in the Presence of Untrusted Code

We are interested in a subset of the capabilities available in a CHERI capability machine. We thus work with a simplified machine model, featuring basic capabilities that are used to give access to a range of memory, as well as so-called “sealed entry” capabilities (abbreviated as “sentry” capabilities [Watson et al. 2020, Section 3.8]) that provide encapsulation features. The sentry capabilities were also called “enter” capabilities in earlier work, e.g., in the M-Machine by Carter et al. [1994].

Concretely, we model capabilities as 4-tuples \((p, b, e, a)\) . In actual hardware, capabilities are encoded as fixed-size binary words, but here we abstract over their concrete representation.

A capability \((p, b, e, a)\) represents a machine word that can be used to access memory within the region \([b, e)\) delimited by its base address b and end address e. The permission p specifies what is possible to do within this memory range: permission \(\small {\text{O}}\) specifies that the capability actually gives no access rights, \(\small {\text{RO}}\) grants read-only access to memory, rx grants the right to read and execute the contents of the memory, rw gives read and write access, and rwx gives read, write, and execute access. Capabilities with permission e behave a bit differently (they are used to provide a form of encapsulation), and will be explained later in Section 2.4.

A capability is meant to be used as a pointer, and thus additionally points to a specific address a (typically, but not necessarily, belonging to the range \([b, e)\) ). Each time the capability is used to access memory, the machine will automatically check that a is between bounds b and e, and that the access is permitted according to p. From a capability \((p, b, e, a)\) it is easy to derive another capability \((p, b, e, a^{\prime })\) pointing to a different address \(a^{\prime }\) also within range \([b, e)\) – in other words, while a capability points to a specific address, it really holds authority over the whole region delimited by its beginning and end address.

Note that, on a capability machine, machine words can represent not only binary-encoded capabilities, but also traditional fixed-size integers. However, unlike on a traditional computer architecture, integers cannot be used as pointers. In other words, without holding a capability, one cannot access memory at all. In this paper, we rely on difference in notation to distinguish between capabilities and integers. In actual hardware, this is done by associating an extra one-bit tag to each word to distinguish capabilities from integers.

It is worth pointing out a sometimes counter-intuitive aspect of reasoning about security of programs running on a capability machine, especially for readers with a background in reasoning about safety in higher-level languages. For a high-level language, program safety can be seen as the absence of undefined behavior or runtime errors. For instance, an out-of-bounds array access is undefined behavior in C, and it leads to a runtime error, such as raising an exception, in memory-safe languages such as Rust or OCaml. We are instead interested in security properties for which a runtime failure can actually be considered a good thing.

Generally speaking, a low-level machine has many cases where it can fail at runtime, stopping the normal course of execution. In a standard (non-capability) machine, this can happen, e.g., if the machine attempts to execute an invalid instruction which cannot be decoded. The addition of capabilities only adds more possibilities for runtime faults: each time a capability is used, the capability machine will check that it has adequate permission and bounds, and raise a runtime fault otherwise.

Now, the point is that, from a security perspective, these additional runtime faults are a good thing. Using these additional checks, the capability machine turns dangerous behavior (out-of-bounds accesses leading to buffer overflow attacks, etc.) into proper faults before they can cause damage. Thus, for our purposes, it is always safe for the machine to fail: it means that an illegal operation may have been attempted, and the execution has been stopped in response.

Of course, when writing concrete programs, we will typically want to verify that we do not involuntarily trigger faults, as this would make our programs less useful. But when interacting with adversarial code, this is a possibility that we have to take into account anyway: we cannot prevent unknown code from shooting itself in the foot, e.g., by trying to access memory it does not have a valid capability for, or by decoding illegal instructions.

To sum up, in this work we reason about security properties that are not violated in the case of machine failure. This includes, for example, integrity of private data: no data can be compromised if the machine stops running. It is therefore useful to keep in mind that we consider failure to be trivially safe!

Consider Scenario 1 from Figure 2(a): how can one write a program which passes control to untrusted code while protecting some secret data? That is, we wish to write a program that sets up capabilities so that its secrets are preserved even after it runs untrusted code.

The key intuition is that, at any point of the execution, one can only access the part of memory that is accessible using the currently available capabilities. In other words, the authority of a running program comes from the set of capabilities which are transitively reachable from the CPU registers.

This is illustrated below, in a scenario where the \(\mathsf {pc}\) register (“program counter”) contains a capability with permission rx pointing to some memory region (containing the code of the program being executed), and register \(\mathsf {r_{1}}\) contains a capability with permission rw, pointing to a region of memory, which itself contains an rw capability pointing to another memory region. The collection of the “hatched” memory regions corresponds to the overall subset of memory accessible by the program.

If one wishes to reduce the set of available memory or its associated access rights—for instance to protect secrets from being leaked to an adversary—then it is enough to constrain the capabilities currently available. This can be done in a few different ways.

First, one can simply remove a capability from registers in order to remove access to the memory it was giving access to. For instance, after executing the instruction “mov r1 0”, which overwrites the contents of register \(\mathsf {r_{1}}\) with the integer 0, one loses access to the memory regions which were previously accessible from the capability stored in that register.

Alternatively, it is possible to restrict the range of a capability to point to a smaller memory region. This changes the set of accessible memory to a subset of what was previously available. For instance, starting from our initial scenario and running the instruction “subseg r1 a0 a1” will change the range of the capability stored in register \(\mathsf {r_{1}}\) to \([ {a_{0}}, {a_{1}})\) . (The machine will check that \([ {a_{0}}, {a_{1}})\) is indeed included in the range of the original capability.) In our example scenario (illustrated below), we then only keep the beginning of the region accessible from \(\mathsf {r_{1}}\) , and this entails that the third region of memory becomes inaccessible, since it was only reachable from a capability stored at the end of the region accessible from \(\mathsf {r_{1}}\) .

Finally, one can restrict the permission of a capability to a permission that grants less access rights. For instance, running the instruction “restrict r1 RO” in our initial scenario modifies the capability stored in \(\mathsf {r_{1}}\) to only grant read-only access to its corresponding memory region. Note that we still have read-write access to the last memory region, as we can still read the capability (with permission rw) pointing to it.

Example: sharing a sub-buffer with unknown code. Using some of the mechanisms detailed above, we can implement a very simple program that shares a buffer with unknown, possibly adversarial, code while using capabilities to protect some data that would otherwise be vulnerable to buffer overflow attacks.

The assembly code for the program is shown in Figure 3 . It consists of a code section containing the instructions of the program, followed by some data which (for simplicity) we simply assume to be statically allocated. The data section holds the zero-terminated string “Hi”, which we wish to share with the untrusted code, and the integer 42 which represents our secret data.

Initially, we assume the program counter to contain an rwx capability for the whole region holding our program. This capability serves two purposes: it allows the machine to execute our program, but can also be manipulated by the program itself to derive a capability pointing to its own data. By convention, the register \(\mathsf {r_{0}}\) is assumed to contain a capability to the continuation of the program, i.e., other code that the program will pass control to after it is done executing. As no assumption is made about the contents of \(\mathsf {r_{0}}\) , it is conservatively assumed to point to unknown, arbitrary code.

Our program executes as follows: it first loads the capability held by the program counter into register \(\mathsf {r_{1}}\) . Then, using the lea instruction, it changes the “current address” of the capability to point to the data label (lea modifies a capability by adding an offset to its “current address”). In assembly programs, we use the brackets notation [...] to denote an arithmetic expression that is computed statically when assembling the program.

At this point, the capability held in \(\mathsf {r_{1}}\) points to the start of the “Hi” string, but has (rwx) authority over the whole code and data section. This capability would be unsafe to share with the untrusted code, as they could simply use lea to increment the capability’s current address past the end of the string, and obtain a valid capability to the secret value (thus performing a basic “buffer overflow” attack). To prevent this from happening, we use the subseg instruction to obtain a capability whose range of authority is restricted to the sub-buffer holding the “Hi” string. Note that we are not restricting the permission of the shared sub-buffer capability. Following the principle of least privilege, one might expect that we remove its execute (-x) permission as well. However, while it would have been good practice, doing so would not have been necessary to uphold the expected security property,² and we can thus prove something stronger. Finally, we pass control to the untrusted code by using the jmp instruction, loading the contents of register \(\mathsf {r_{0}}\) into \(\mathsf {pc}\) .

This example illustrates that even a basic mode of use of capabilities (restricting them appropriately) can easily prevent buffer overflow attacks. In Section 6.1, we show how we can formally prove that, for any untrusted code, the value of the secret data will be equal to 42 at every step of the execution, including after control has been passed to the untrusted code. We have also developed a relational model, which can be used to prove that the secret value cannot even be read by the unknown code, but the details of this relational model are out of scope of this paper.

The previous example illustrates how to restrict available capabilities to prevent an adversary from accessing secret data. However, what if we additionally want our program to be called back by the untrusted code, as in Scenario 2(b)? In that case, when the trusted code gets invoked again we would like to recover access to the capabilities it previously had to its private state.

This is unfortunately not achievable with the capabilities that we have described so far. If we remove capabilities to private memory before passing control to untrusted code, then there is no way for us to get them back later on: the only capabilities we will get access to in a further invocation are capabilities the untrusted code itself has access to.

Sentry capabilities provide this missing feature. They implement a form of encapsulation that resembles the use of closures with encapsulated local state in high-level languages, and they allow implementing compartments which encapsulate private state and capabilities but can be called from untrusted code. From a security perspective, sentry capabilities allow setting up protection boundaries: the code executing before and after an invocation of a sentry capability has different authority and thus represents distrusting components. We denote sentry capabilities with permission e (for “Enter”, a terminology originating from the M-machine [Carter et al. 1994]).

One typically creates a sentry capability pointing to a region of memory describing a compartment containing executable code and local state (or private capabilities to that local state). A sentry capability is opaque: it cannot be used to read or write to the memory region it points to, and it cannot be modified using restrict or subseg. It can thus be safely shared with untrusted third-parties: they will not be able to access the encapsulated code and data. In the figure below, the memory region pointed to by \(\mathsf {r_{1}}\) (hatched in gray) is not accessible for either reading or writing.

The only possible operation is to “invoke” the sentry capability using the jmp instruction, thus passing control to the code held in the region pointed to by the capability (in other words, “running” the compartment). When jmp is called on a sentry capability, it turns the capability into a capability with permission read-execute (rx) over the same memory region, and puts it into the program counter register \(\mathsf {pc}\) . This simultaneously runs the encapsulated code, and gives access to the data and capabilities stored there, which were previously inaccessible. Running instruction jmp r1 on the scenario of the previous figure leads to the machine state shown below.

Register \(\mathsf {pc}\) now contains an rx capability to the previously opaque region, meaning that code contained in that region can execute. Furthermore, it may access other capabilities stored in that region, which can in turn be used to transitively access other private regions of memory.

Example: a counter compartment. To illustrate the use of sentry capabilities, let us consider the example of a simple secure compartment implementing a counter. An instance of the counter holds a private memory cell containing the current (integer) value of the counter. Every time the code in the counter’s compartment is invoked, it increases the value stored in the memory cell. Using a sentry capability, one can expose the counter to an untrusted context, without giving it direct access to the counter value.

It is worth pointing out that this is similar to the use of closures encapsulating local state in high-level languages. Typically, a similar counter program could be implemented in a high-level language as follows, using a function closure to encapsulate a reference holding the counter value.

As before, our actual counter program is implemented in assembly, and its code appears in Figure 4 . Its implementation is divided into two parts. First, the code starting at label init (and ending at code) is used to set up the counter compartment; it is intended to run only once at the beginning of the program. Then, the region between code and end corresponds to the contents of the counter compartment itself, including its executable code (between code and data) and private data (between data and end).

The role of the initialization code is to create a sentry capability encapsulating the code–end region, and then pass control to the (untrusted) context, giving it access to the newly created sentry capability. Additionally, the initialization code stores at address data a capability giving read-write access to the compartment’s region, and pointing to the counter’s value at address data+1.

One might wonder why we have this extra indirection to the counter’s value through the capability in data. Recall that after calling jmp on a sentry capability, the program counter is only provisioned with an rx capability. For the counter code to be able to actually increment the counter value (at address data+1), it needs to have write access to it. The additional rwx capability stored at address data by the initialization code is thus used to “promote” read access on the compartment’s region into read-write access to that same region.

The code of the counter’s compartment can then run many times, once each time the context chooses to invoke the sentry capability it got from the initialization code. At each invocation, the counter’s implementation (at address code) reads the rwx capability stored in the data section, uses it to increment the value of the counter, and passes control back to its caller.

Let us walk through the details of the code. The initialization code is assumed to run starting with a program counter giving rwx access over the whole program region. The first four instructions derive, from the program counter, rwx capabilities pointing to addresses data and data+1. Then, using the store instruction, the capability rwx, init, end, data+1) is stored at address data. Next, after using lea and subseg to adjust the address and bounds of the capability, a sentry capability is created pointing to the compartment’s region [code, end. This is done using the restrict instruction, turning a capability with permission rwx into a capability with permission e. Register \(\mathsf {r_{2}}\) is then cleared, to make sure that the rwx capability pointing to the counter value is not leaked to the context. Finally, the initialization code jumps to the capability in \(\mathsf {r_{0}}\) , which by convention points to the context.

The compartment’s code (starting at address code) then gets executed each time the context invokes the sentry capability. Because we have only shared a sentry capability (e, code, end, code) with the context, we know that when the compartment gets executed, the program counter must contain (rx, code, end, code). By reading the program counter, the first two instructions of the code then derive an rx capability pointing to address data, and use it (with load) to read the capability that was stored there, granting rwx access to data+1. The subsequent load, add and store instructions use this second capability to increment the value of the counter. Finally, before returning to the context by jumping to \(\mathsf {r_{0}}\) , the program takes care of clearing register \(\mathsf {r_{1}}\) , overwriting its contents with 0. This is quite crucial, as otherwise an rwx capability would be leaked to the context, giving it direct access to the counter’s private state!

To sum up, our example program carefully selects which capabilities it shares with unknown code, and leverages the encapsulation properties of sentry capabilities provided by the machine. Consequently, it should seem clear, at least informally, that the integrity of the counter’s value is guaranteed through the execution. More precisely, we should be able to formally prove some invariant about it: for instance, that it is nonnegative at every step of the execution, for any untrusted context. In Section 6.2, we show in more detail how to formally establish this property.

In this section, we have showcased how one might program with capabilities in order to obtain security guarantees, and make it possible to interact with adversarial code while protecting private data and invariants.

In the rest of this paper, we show how we can make the intuitions that we have developed so far more precise, and formally prove capability safety for machine code programs that interact with untrusted code. Namely:

Figure 7 shows the syntax of our Cerise program logic based on Iris. In this subsection, we present the underlying concepts of Iris used to define the Cerise program logic. We keep the presentation high level, and refer to Birkedal and Bizjak [2022] for a complete and pedagogical presentation of the Iris logic. We write \(\mathit {Prop}\) for the universe of propositions. These feature the standard connectives of higher-order logic and separation logic, including the separating conjunction \(\ast\) and the magic wand \({\rightarrow\!\!\!\!\ast}\) (read as an implication). The proposition \(\left\lceil \phi \right\rceil\) asserts that the pure proposition \(\phi\) holds, where \(\phi\) is a proposition from the meta logic.

Iris assertions can be divided in two categories: ephemeral assertions and persistent assertions. Ephemeral assertions describe facts or resources that are available at a given point but might become false or unavailable later. Persistent assertions describe facts that never cease to be true. The assertion \(\square P\) , read “persistently P”, is persistent, and asserts ownership over resources whose duplicable part satisfies P. In other words, \(\square P\) is like P except that it does not assert any exclusive ownership over resources. As the knowledge associated with a persistent assertion can never be invalidated, persistent assertions can be freely duplicated.

The modality \(\vartriangleright P\) , read “later P”, expresses (roughly) that the assertion P holds after one “logical step” of execution. In this paper, we mainly use it to define recursive predicates using guarded recursion. It is not necessary to understand how the modality behaves in detail and the reader can safely ignore it for the most part and just recall that it supports an abstract accounting of execution steps.

Our logic includes resources (predicates) that describe parts of the current state of the machine . The assertion \(\mathsf {a} \mapsto w\) expresses that the memory cell at address \(\mathsf {a}\) contains the machine word w. Furthermore, this assertion should be read as giving unique ownership over location \(\mathsf {a}\) , giving the right to freely read and update the corresponding memory cell. Similarly, the assertion \(r ⤇ w\) asserts ownership of a CPU register r containing the word w. We write \(\vec{a} \mapsto \vec{l}\) for the ownership of contiguous memory cells at addresses \(\vec{a}\) containing \(\vec{l}\) .

A key feature of the logic is the notion of an invariant. The assertion \(\boxed{P}\) asserts that P should hold at all times, now and for every future step of the execution (where P can be any separation logic assertion). An invariant is a persistent assertion. Unlike \(\square P\) , which does not assert any exclusive ownership over resources and is established by showing it does not depend on other ephemeral assertions, \(\boxed{P}\) is used to encapsulate any assertions into an invariant. An invariant \(\boxed{P}\) can be created (or “allocated”) by handing over the resources for P, turning them into \(\boxed{P}\) . Then, whenever we know that \(\boxed{P}\) holds, we can get access to the resources P held in the invariant, but only for the duration of one program step. Indeed, since the invariant must hold at every step of the execution, when accessing its resources, one needs to show that it holds again no later than one program step after. A more precise rule for accessing invariants is given next in Section 4.2 (rule Inv).

The predicates for machine resources we just presented allow describing the state of the machine, as well as modalities to guard those resources, which allows us to relate the state of the machine to its execution steps. Our logic, moreover, includes assertions that can be used to specify machine executions, similar to Hoare triples used in program logics for high-level languages. Because we work with a low-level machine (where code is located in memory), we distinguish between three different types of program specifications :

In each case, P are Q are separation logic assertions describing the state of the machine (registers and memory). P corresponds to a pre-condition, Q a post-condition, and s binds in Q the corresponding execution state (of type \(\mathrm{ExecState}\) , see Figure 5).

Informally, \(\left\langle P \right\rangle \rightarrow \left\langle s\ldotp Q \right\rangle\) holds if, starting from a machine state satisfying P, the machine can execute one step of computation, and reach a state satisfying Q in an execution state s. The predicate \(\left\lbrace P \right\rbrace \rightsquigarrow \left\lbrace s\ldotp Q \right\rbrace\) holds if, starting from a state satisfying P, then the machine can diverge (i.e., loop) or reach a state satisfying Q in an execution state s. This is typically used to describe the execution of a code fragment. Finally, \(\left\lbrace P \right\rbrace \rightsquigarrow {\bullet }\) holds if, starting from a machine state satisfying P, then the machine loops forever or runs until completion, ending in either a \(\mathsf {Halted}\) or \(\mathsf {Failed}\) state. In this case, we say that the initial configuration described by P is safe. (Not every configuration is safe: the resources in P describing registers and memory must suffice for the machine to run and execute the code pointed to by \(\mathsf {pc}\) : for example, \(\left\lbrace pc ⤇ ({\small\text{RX}},a,a+2,a) \ast a \mapsto \texttt {mov}\; \mathsf {r_{1}}\; z \ast a + 1 \mapsto \texttt {halt} \right\rbrace \rightsquigarrow {\bullet }\) cannot be established, since the precondition lacks a resource for \(\mathsf {r_{1}}\) . The configuration where the register and memory maps are the partial maps as defined by the declared points-to assertions is thus not considered safe.)

Additionally, these three specifications require the logical invariants to be preserved at every step of the execution. This requirement is implicit in the definition of invariants, but it is a crucial reasoning principle that we will leverage.

Echoing back to Section 2.2, note that our program specification for a complete safe execution allows the program to fail (or diverge). Indeed, we will capture the preservation of security properties by preserving invariants throughout execution and having the machine fail is both fine (invariants are trivially preserved when the machine ends up in a failure state) and unavoidable (we cannot prevent unknown code from triggering a capability check failure). Similar considerations apply for divergence.

Notations. In the rest of the paper, we will rely on a couple of additional notations when writing program specifications. Because we often want to reason about the case where an instruction (or program fragment) does not fail, we write \(\left\langle P \right\rangle \rightarrow \left\langle Q \right\rangle\) (respectively \(\left\lbrace P \right\rbrace \rightsquigarrow \left\lbrace Q \right\rbrace\) ) to denote a resulting execution state equal to \(\mathsf {Running}\) :

When writing pre- and post-conditions, we will often need to include a points-to resource describing the contents of the \(\mathsf {pc}\) register. We introduce a short-hand notation for that purpose, and write \(w; P\) to assert P and additionally that \(\mathsf {pc}\) is set to w:

Using these two notations, the specification for a single instruction, in a case where it does not fail, is written as \(\left\langle w_{0} ; P \right\rangle \rightarrow \left\langle w_{1} ; Q \right\rangle\) (typically, we have \(w_{1} = w_{0} + 1\) , except in the case of the jmp and jnz instructions, or when explicitly writing to the \(\mathsf {pc}\) register).

Properties. Our program specifications satisfy the well-known “frame rule” of separation logic, which permits local reasoning, and asserts that it is always possible to extend a specification by adding arbitrary resources not accessed by the program.

Program specifications can also be composed using sequencing rules. In order to establish a specification of the form \(\left\lbrace P \right\rbrace \rightsquigarrow \left\lbrace s\ldotp Q \right\rbrace\) , one typically uses single-instructions rules ( \(\left\langle R \right\rangle \rightarrow \left\langle s\ldotp S \right\rangle\) ) in a sequence, one for each instruction of the relevant code block. Specifications for two program fragments that follow each other can also be combined to obtain a specification for the sequence of the two fragments. We prove general sequencing rules for our three kinds of specifications; for simplicity, we only reproduce here restricted rules that deal with successful executions (relying on the notations introduced before):

When reasoning about a single execution step, one can additionally access resources held in known invariants. This is done using the Inv rule, given below:³

Example specifications. As illustrative examples, Figure 8 shows specifications for the subseg, load and store instructions, as well as the rclear macro which is used to clear the contents of a number of specified registers. The first rule shows a specification for the subseg instruction . It states that if the program counter contains a capability pointing to a memory location \(a_{\mathit {pc}}\) , if that location contains an integer n which decodes into \(\texttt {subseg}\; r \; z_{1}\; z_{2}\) , and if the register r contains a capability, then assuming that the program counter is valid ( \(\mathrm{ValidPC}\) (...)) and that \(z_{1}\) and \(z_{2}\) are valid new bounds ( \(\mathrm{ValidSubseg}\) (...)), the machine successfully increments the program counter and restricts the capability held in register r with new bounds \(z_{1}\) and \(z_{2}\) .

The second rule is also a specification for subseg, but in a case where it fails a bound check, i.e., \(\mathrm{ValidSubseg}(p, b, e, z_{1}, z_{2})\) does not hold . (For instance, when the new bounds \(z_{1}\) and \(z_{2}\) would allow accessing more memory than what is available through the original capability.) Then, the rule does give us a specification for an execution step, but with a resulting execution state of \(\mathsf {Failed}\) , meaning that the execution cannot continue afterwards.

The third and fourth rules give specifications for the load and store instructions (in non-failing cases) . The specification for load states that \(\texttt {load}\; \mathit {dst}\; \mathit {src}\) loads a word from memory pointed to by a capability in register \(\mathit {src}\) and stores its contents in register \(\mathit {dst}\) . The specification for store states that \(\texttt {store}\; \mathit {dst}\; \mathit {src}\) reads a word from the \(\mathit {src}\) register and writes it into the memory location pointed to by the capability in \(\mathit {dst}\) .

Note that these specifications for subseg, load and store are not in fact the most general specifications for these instructions. They assume that some side-conditions hold, and specify the behavior of the instruction in the case of either a “normal” successful execution, or a failing one. These specifications are typically useful for reasoning about the correctness of a concrete program. We have also proved in Coq (e.g., for the subseg instruction) “most general” specifications, covering in one lemma all possible cases for a given instructions. These are useful for deriving the more specific rules shown previously. Furthermore, we use them directly in the proof of the Fundamental Theorem (Theorem 2), for specifying the behavior of arbitrary instructions that might or might not fail.

The last rule of Figure 8 shows a derivable specification for a program composed of several instructions, the rclear macro . This macro (meaning, a small program that is typically inserted inline as part of a larger program) clears a number of registers by setting their content to 0. It is parameterized by a list l of register names, and its code consists of a sequence of instructions \(\texttt {move}\; r\; 0\) for each register name r in l. We state rclear’s specification using the program specification for code fragments. This specification is provable using the basic reasoning rules for \(\texttt {move}\) . It requires that the body of the macro (“ \(\mathrm{rclear\_instrs}\) l”) is laid out contiguously in memory range \([{a}, {a + n})\) , while the program counter initially points to a. When the program counter eventually points to \(a + n\) , the address immediately after the macro’s instructions, then all the registers in l have been cleared and now contain 0. (The “big star” \(\ast\) denotes an iterated separating conjunction, here over the registers r in list l.)

After establishing program specifications and properties at the level of our program logic, we ultimately want to transfer these results into properties of a program execution at the level of the operational semantics of the bare machine. Generally speaking, we prove using the rules of the Iris logic a statement of the form \(\boxed{P} \vdash Q\) , where P and Q are Iris propositions (read “Q holds assuming invariant P”). From this, we want to deduce that some mathematical proposition \(\Phi\) holds (as a Coq proposition, in our case), where \(\Phi\) describes some property of the machine execution expressed in terms of its operational semantics.

Because we are interested in establishing invariants about a program execution, we typically want to obtain in \(\Phi\) that at every step of the execution, the state of the machine satisfies an invariant corresponding to the Iris assertion P.

Deriving mathematical facts from Iris proof derivations is made possible thanks to the so-called adequacy theorem of Iris . This theorem has a very general but intricate statement. In this section, we describe a simpler but more specialized adequacy theorem for our capability machine, which we can use to reason about the examples introduced in Section 2. (We also describe in Section 7 a more advanced adequacy theorem, suitable for reasoning about programs such as the case study of Section 8.) This specialized adequacy theorem is itself established on top of the general Iris adequacy theorem. When it applies, it is more convenient to use; but in the general case, it is always possible to directly leverage the general adequacy theorem.

We now present our specialized adequacy theorem. We first define a notion of memory invariant (Definition 1), which corresponds to a predicate over a finite subset of the machine memory. Typically, we will consider predicates of the form: “the value at this specific memory address holds a positive integer” (for instance, the value of the counter of Section 2.4). A memory invariant is given by a predicate I over machine memory and a set of addresses D (the “domain” of the invariant); we then require that I is not impacted by changes outside of D.

We now present the statement of our specialized adequacy theorem; we explain the ingredients in the theorem statement below. Given a memory invariant I over a set D, our adequacy theorem (Theorem 1) can be used to show that I indeed holds of the memory at every step of the execution, provided we can show that it holds as an invariant in Iris.

Theorem 1 establishes that, starting from an initial machine state \((\mathit {reg}, \mathit {mem})\) , any subsequent machine state \((\mathit {reg^{\prime }}, \mathit {mem^{\prime }})\) satisfies \(I(\mathit {mem^{\prime }})\) . This is subject to a number of conditions, in particular about the initial state of the machine.

First, the initial memory must be provisioned with relevant code and data. This means that the program that we wish to verify (both its code and data) given by memory fragment \(\mathit {prog} : [b, e) \rightarrow \mathrm{Word}\) should be included in the initial memory. Moreover, some additional “adversarial code” given by \(\mathit {adv} : [ {b_{\mathit {adv}}}, {e_{\mathit {adv}}}) \rightarrow \mathrm{Word}\) should be included in the initial memory. Indeed, we are not only interested in reasoning about the execution of our verified program in isolation, but also its interaction with unverified, possibly adversarial code. The initial memory \(\mathit {mem}\) should therefore include \(\mathit {prog}\) and \(\mathit {adv}\) , in disjoint regions. Furthermore, the domain of the invariant I should be included in the program’s region \([b, e)\) . The intent is that I specifies an invariant about some private data of the verified program, and thus should not depend on other parts of memory.

Second, as should be expected, the invariant I must hold of the initial memory \(\mathit {mem}\) .

Third, the adversary memory \(\mathit {adv}\) can only contain capabilities that are at least ro, with a range contained within the adversary region, as defined by the following condition:

This conservatively ensures that \(\mathit {adv}\) does not contain any “rogue” capability that would give undesired access to the verified program’s private state. No further assumption is made about \(\mathit {adv}\) , which is thus free to contain arbitrary code (i.e., instructions encoded as integers), and any arbitrary in-bounds data capabilities. Furthermore, as we will see in Section 7.1, adversaries will also be able to gain access to dynamically allocated capabilities pointing to fresh regions. This is achieved by sharing a safe malloc subroutine with the adversary.

Next, the initial register file \(\mathit {reg}\) should be provided with an rwx capability to the verified program in \(\mathsf {pc}\) (meaning that it executes first), and a capability to the unverified code in register \(\mathsf {r_{0}}\) (as we have seen in Section 2, by convention \(\mathsf {r_{0}}\) holds the capability to a program’s continuation). Other registers are conservatively required not to contain any capabilities.

Finally, one needs to establish at the level of the program logic that the program is safe to run under invariant I. Concretely, one needs to prove a specification for a complete safe execution (of the form \(\left\lbrace P \right\rbrace \rightsquigarrow {\bullet }\) ), given “points-to” resources in the pre-condition that correspond to the initial state of registers and memory. In particular, we get access to points-to resources for the adversary region (along the fact that they contain integers) and points-to resources for the region containing the program to execute.

Note that no resources are given for the domain of I as part of the initial resources for the complete-execution specification. Instead, these resources are part of the logical invariant under which the specification must be established (inside \(\boxed{\ldots }\) ). This corresponds to the intuition that these resources should only be modified in a way that preserves invariant I. This logical invariant therefore specifies that there exists a subset of memory m, which covers the memory region defined by D, such that the invariant holds the corresponding points-to resources and such that \(I(m)\) holds, i.e., the memory invariant I holds of this memory subset. (Recall from Section 4.1 that \(\left\lceil \phi \right\rceil\) denotes an Iris proposition that asserts that the mathematical proposition \(\phi\) holds.)

The reader may be surprised to notice that the region containing “adversarial” code has no special status. Indeed, it simply corresponds to a memory region containing (a priori unknown) integers. Nevertheless, remember that we ultimately want our program to be able to pass control to the unknown adversary code by jumping to the capability in \(\mathsf {r_{0}}\) , as we have seen our example programs do. This means we need to have a way of reasoning about “what it will do”, at least to ensure that it will not break our program’s invariants.

In the next section, we show how to reason about whether unknown code can be considered “safe to execute”, so that we can pass control to it while preserving previously established invariants.

Our formal definition of what makes a machine word safe, meaning “safe to share with unknown code”, appears in Figure 9 . It takes the form of a unary logical relation, defining simultaneously the notions of a machine word that is “safe to share” ( \(\mathcal {V}\) ) and “safe to execute” ( \(\mathcal {E}\) ). The names \(\mathcal {V}\) and \(\mathcal {E}\) originate from the tradition of logical relations, corresponding respectively to the “value relation” and the “expression relation”, although this interpretation is perhaps less obvious in the setting of low-level machine code. We explain the definition in detail below. The intuition is that:

Technically speaking, this informal definition is circular. Luckily, we can define it properly with the help of the “later” modality \(\vartriangleright\) . Iris provides us with a fixed-point operator that only requires recursive occurrences to be guarded under a \(\vartriangleright\) , and we use that to formally define \(\mathcal {V}\) and \(\mathcal {E}\) . Except for this technical requirement, the reader can in practice ignore the use of \(\vartriangleright\) here.

Let us more closely examine the definition of \(\mathcal {V}\) , which is defined by case analysis on the shape of the given machine word w. If w is an integer (z), then it is always safe to share, since it cannot be used to access memory. Similarly, opaque capabilities with permission o are always safe as they also do not give access to memory.

A sentry capability e is safe to share if the code it encapsulates is safe to execute. Such a capability can be invoked at any moment and possibly several times: this is expressed through the use of the persistently modality \(\square\) . Technically speaking, this means that the property \(\mathcal {E}(\small{\text{RX}}, b, e, a)\) must be established by only relying on persistent resources (typically, logical invariants) that will remain “available” throughout the entire execution.

A read-write capability rw or rwx gives read and write access to the memory region in its range. It is therefore safe as long as the words stored in the corresponding memory region are safe, and continue to be so when the memory gets modified. We thus say that it is safe when we have an invariant for each memory cell in the capability’s region, which asserts ownership over the corresponding memory points-to resource, and asserts validity of its contents.

Finally, a capability with permission ro/rx cannot be used by unknown code to modify the memory words in its range. Therefore, these words can obey any property P as long as it entails safety ( \(\mathcal {V}\) ). Intuitively, the words in the interval have to be safe to share, because the adversary can read them. But since the adversary cannot modify them, it is possible to guarantee a stronger invariant about them. For instance, \(P(w)\) could be the predicate “ \(w = 42\) ”, describing that a value in the range stays equal to the integer 42.

Notice that this definition of safety does not distinguish between capabilities with permission ro and rx, or rw and rwx. This seems to strangely imply that permissions with the execute bit x have no additional expressive power over permissions without the execute bit. And indeed, in terms of our model—which “only” captures the ability to break memory invariants—their expressive power is the same!⁴ The crux of our main theorem (presented in the next sub-section) is that executing arbitrary code does not produce capabilities with more access to memory than was available before. Thus, being able to execute code within a memory region does not yield additional access to memory compared to what was available by simply reading the memory region (it only leads to additional machine behaviors).

Is this definition of safety trivial?. One might wonder whether the definition in Figure 9 is trivial, meaning that any machine word w will in fact be considered safe. This is thankfully not the case; let us illustrate concrete cases where a memory word w is not considered safe to share with unknown code.

At a high level, \(\mathcal {E}\) is not trivial because establishing \(\mathcal {E}(w)\) requires proving that a full execution of the machine, starting from w, preserves logical invariants. This requirement is not explicit in the definition, but comes from the definition of the Cerise program logic. The definition of \(\mathcal {V}(w)\) is also not trivial because, e.g., in the case of an rw capability, it requires the memory points-to \(a \mapsto -\) predicate to be part of a specific invariant, \(\boxed{\exists w, \; a \mapsto w \ast \mathcal {V}(w)}\!\) . Since the resource “ \(a \mapsto -\) ” is not duplicable, there can be only one resource \(a \mapsto -\) , which cannot be simultaneously part of two different invariants. Memory cells whose contents evolve according to an invariant more specific (less permissive) than the one above thus cannot be associated with a safe capability (according to \(\mathcal {V}\) ).

What is a concrete example of a capability which is not safe? Let us consider a memory cell at address x initialized to 0. Let us assume the following Iris invariant: \(\boxed{x \mapsto 0}\) . This invariant expresses that x will contain the integer 0 for the rest of the execution. Then, a capability \((\small{\text{RW}}, x, x+1, x)\) is not safe to share with an adversary. Indeed, an adversary could use such a capability to write an arbitrary value at address x, thus invalidating the Iris invariant. (However, \((\small{\text{RO}}, x, x+1, x)\) would be safe.) A bit more formally speaking, it is not possible to prove \(\mathcal {V}(\small{\text{RW}}, x, x+1, x)\) , because it is not possible to create the invariant \(\boxed{\exists w, \; x \mapsto w \ast \mathcal {V}(w)}\) , as the resource for the memory cell x is already part of the invariant \(\boxed{x \mapsto 0}\) , and cannot be extracted to create a different invariant.

Similarly, one cannot prove \(\mathcal {E}\) for a code fragment that writes another value than 0 at address x (after getting access to it through the \(\mathsf {pc}\) register), because the proof would not be able to guarantee that the Iris invariant related to x is preserved at every step.

The Fundamental Theorem of our Logical Relation (Theorem 2) (hereafter, FTLR) establishes that any capability that is “safe to share” (in \(\mathcal {V}\) ) is in fact “safe to execute” (in \(\mathcal {E}\) ). In other words, if a capability only gives transitive access to safe capabilities, then it is safe to use it as a program counter capability and execute it: it will not be able to gain extra authority over memory or break any invariants. Importantly, this theorem is independent of the code that the capability points to, even though it is this code that will be executed. Hence, the result applies to arbitrary code and we sometimes refer to it as a universal contract because of this.

This is a non-trivial theorem, the proof of which requires checking all the possible cases of the semantics of each instruction of the machine. Indeed, one needs to check that there is no way for some machine instruction to create capabilities with further authority than what was available. This could, for example, happen if some runtime checks were missing, making it possible to create a capability \((\small{\text{RW}}, b, e+1, a)\) from a capability \((\small{\text{RW}}, b, e, a)\) . One can imagine how this would break expected security guarantees, and reveal a design or implementation bug of the machine. Therefore, another informal interpretation of the fundamental theorem is that it expresses that the capability machine “works well” or that it is capability safe.

The fundamental theorem provides a universal security property satisfied by unknown code, and gives us a way of verifying the correctness of known code that includes calls to possibly malicious code. To sum up, our logical relation characterizes the interface between a piece of verified code which wishes to preserve invariants on some internal state, and “external” arbitrary code whose accessible, safe capabilities have been sufficiently restricted.

It is important to note that the distinction between “known” and “adversary” code only exists at the logical level: there is no such distinction at runtime. We can have two components that have been verified separately, and that do not mutually trust each other. In this case, from the point of view of each component, the other component is considered as being the adversary. Additionally, we note that “adversary” code is meant to denote code that has not been independently verified, and as such can only be reasoned about using a universal contract, which holds for any arbitrary capability machine program. Alternatively, since the Cerise separation logic enjoys all the advantages of a higher-order separation logic, it also supports the composition of two verified components via abstract and modular specifications. In such cases, both components are considered “known”, even though their internal representation might be abstracted away by the exposed specifications.

Rules for program verification. From the general statement of the FTLR, we can derive two corollaries, which can be used to instantiate our adequacy theorem (Theorem 1) with a program that passes control to an unknown adversarial code region.

Corollary 1 can be used to trade ownership over a memory region of integers and in-bound capabilities to the knowledge that a capability over this region is safe.⁵ Since integers can encode program instructions, we can typically use this rule to reason about a memory region containing an (unknown) program, and its associated data. The rule follows directly from the definition of \(\mathcal {V}\) for values of p different from e; when \(p = \small{\text{E}}\) , an additional application of the FTLR (Theorem 2) is required.

Notice that the pre-condition of the rule matches the resources that one gets in the Adequacy theorem (Theorem 1) for the adversary region. When using the Adequacy theorem, we will thus be able to conclude that capabilities pointing to the adversary region are safe.

Corollary 2 gives us a specification for the execution of the machine after a jump to an unknown word w, assuming that w is safe. Recall that \(\mathrm{updatePcPerm}(w)\) corresponds to the value of the program counter after jumping to w (see the machine semantics in Figure 6). The full execution specification in the conclusion of the rule requires that the machine registers contain safe values: indeed, we must only share safe words with unknown code.

An important application of Corollary 2 is to reason about the last instruction of a program encapsulated in a sentry (e) capability, where it “returns” and passes control to its caller by calling jmp on the (unknown but safe) return capability held in \(\mathsf {r_{0}}\) . In this scenario, the return capability provided by the caller is unknown but safe, so Corollary 2 gives us a specification for the continuation of the program.

Additionally, Corollary 2 is typically used in combination with Corollary 1 when instantiating the Adequacy theorem. Indeed, in order to prove the complete safe execution specification required by the theorem, one typically needs to justify that one can jmp and pass control to an adversary region, given the resources granted by the Adequacy theorem.

To give a more in-depth perspective of the ideas behind the Fundamental Theorem, we detail in this sub-section one of the interesting cases of its proof. This sub-section can be safely skipped on a first read.

Let us recall (on the right) the code for our buffer-sharing program, previously introduced in Figure 3. The labels code, data, secret and end denote addresses in memory. We wish to prove formally that the program can share the data between addresses data and secret (excluded), while protecting the integrity of the data at address secret.

Using the reasoning rules from our program logic, we can first prove a specification for the program, specifying its behavior from its first instruction up until the final jmp. The corresponding specification is as follows, where \(\mathrm{code\_instrs}\) is the list of integers corresponding to the encoded instructions of the program, i.e., \(\mathrm{code\_instrs} = \mathrm{map}\; \mathrm{encodeInstr}\; [\texttt {mov}\; \mathsf {r_{1}}\; \mathsf {pc}; \ldots ; \texttt {jmp}\; \mathsf {r_{0}}]\) .

One can read from the specification that executing the program will store in \(\mathsf {r_{1}}\) an rwx capability to the memory segment between addresses data and secret (our “buffer”), and pass control to the word \(w_{\mathit {adv}}\) found in register \(\mathsf {r_{0}}\) .

Proving this specification is easy: it is enough to successively apply the program logic rule of each individual instruction found in the program.

This specification shows that the program ultimately jumps to the word initially passed in register \(\mathsf {r_{0}}\) , but does not describe what happens after, in the case where this word points to a region containing unknown code. For this, we use the reasoning principles from Section 5.2 (built on top of the Fundamental Theorem), and derive a specification for a complete execution of the machine, see Lemma 2 below. The lemma specifies that, starting by executing our program, and given that \(\mathsf {r_{0}}\) contains a capability to a region containing unknown integers, then the machine is safe to run. Notice that we do not assume a points-to resource for the secret data: instead, this points-to will be part of an invariant—specifying that it contains the same secret value at every step—and we do not need to access that here.

Finally, from Lemma 2, established in the program logic, we wish to obtain a final result in terms of the operational semantics of the machine. The toplevel end-to-end theorem that we obtain is shown in Theorem 3. We consider a machine whose memory is initially loaded with our program and unknown adversarial code, and that starts by executing our verified code. The theorem establishes that the adversary will not be able to tamper with the value held at address secret: at every step of the execution, it will be unchanged and equal to 42.

Let us now come back to the example introduced in Section 2.4, whose code is reproduced below. In this example, the control flow is somewhat more involved, as we have two separate pieces of known code that run at different times. The initialization code between \(\mathsf {init}\) and \(\mathsf {code}\) runs first, and creates a sentry capability before passing control to the unknown code. The code and data located between \(\mathsf {code}\) and \(\mathsf {end}\) are encapsulated in the sentry capability created by the initialization code. Because the sentry capability is exposed to the unknown code, the code it encapsulates may be invoked several times, incrementing the value of the counter each time.

We wish to prove formally that the value of the counter is correctly encapsulated. We prove that it remains non-negative at every step: starting from zero, it can only get incremented by the code routine encapsulated in the sentry capability.

Using the rules of our program logic, we can first prove a specification for the initialization code, shown in Lemma 3. This specification describes the behavior of the code between \(\mathsf {init}\) and \(\mathsf {code}\) , where \(\mathrm{init\_instrs}\) denote the corresponding list of encoded instructions.

From this specification, one can read that running the initialization code will store in register \(\mathsf {r_{1}}\) a sentry capability to \([{\mathsf {code}}, {\mathsf {end}})\) , and write at address \(\mathsf {data}\) an rwx capability pointing to the location holding the counter value. The initialization code then passes control to the unknown word \(w_{\mathit {adv}}\) stored in \(\mathsf {r_{0}}\) .

We can also use the program logic rules to prove a specification for the code routine in \([{\mathsf {code}},{\mathsf {data}})\) which increments the counter, and which will run each time the sentry capability is invoked. The specification appears in Lemma 4, where \(\mathrm{code\_instrs}\) refers to the list of encoded instructions for the routine.

This specification assumes a number of Iris invariants, describing the contents of the \([{\mathsf {code}}, {\mathsf {end}})\) memory region. Indeed, because the increment routine is invoked by unknown code, it cannot make many assumptions about the state of the machine. The only thing that it can assume is that previously established invariants still hold (because, by definition, capability-safe unknown code has to preserve invariants).

The specification thus assumes, as invariants: (1) that the region \([{\mathsf {code}},{\mathsf {data}})\) contains the code of the routine; (2) that \(\mathsf {data}\) contains the rwx capability to the counter value previously stored there by the initialization code, and finally (3) that the counter value (at address \(\mathsf {data}+1\) ) is a non-negative integer.

The specification asserts that the routine can run, starting with \(\mathsf {pc}\) containing an rx capability to the \([{\mathsf {code}}, {\mathsf {end}})\) region, while preserving the invariants. (In particular, this means that incrementing the counter indeed preserves the fact that it is a non-negative integer.) Recall that the rx permission in \(\mathsf {pc}\) corresponds to what one gets after jumping to a sentry capability.

Finally, we prove as before a specification proving safety of complete executions, starting from the initialization code, then followed by the execution of unknown code, including its possible invocations of the sentry capability. This specification appears below in Lemma 5.

Similarly to the previous example, we derive from Lemma 5 a toplevel theorem which only refers to the operational semantics of the machine, shown below in Theorem 4. We consider a machine initially loaded with our program and unknown adversarial code. The theorem establishes that the value of the counter is properly encapsulated: at every step of the execution, it will be a non-negative integer.

We show how dynamic memory allocation can be implemented as a library, for which: (1) we prove an Iris specification making it usable from verified code, and (2) we show that it is safe to share with untrusted code, so that an adversary can also use the library to allocate memory for its own uses.

Note that this task is made easier by the fact that we do not attempt to provide a way of deallocating memory. As such, memory provided by the allocation routine is never reclaimed. We leave deallocation for future work, as it likely requires a significantly more complex runtime mechanism to ensure that no dangling capabilities remain pointing to previously allocated memory regions [Filardo et al. 2020; Xia et al. 2019].

Concretely, we implement our allocator library as a simple bump-pointer allocator. The library provides a malloc entry point, to be called with an integer argument n, which works as follows:

Figure 10 outlines the code for our simple malloc implementation. The code assumes that it is stored in memory in an interval \([ {b_m},{b_{\mathit {mid}}})\) and that \(b_{\mathit {mid}}\) points to a capability \((\small{\text{RWX}}, b_{\mathit {mid}}, e_{m}, a)\) giving access to: itself (so it can be updated), and the memory pool (between address \(b_{\mathit {mid}}+1\) and \(e_{m}\) ). For simplicity, we assume that the non-allocated memory is already initialized to 0. These requirements are represented by the following invariant :

The core property of our safe malloc is that is does not hand out the same addresses across multiple dynamic allocations. This can be expressed elegantly in separation logic, by specifying that malloc hands out points-to resources for the allocated memory. Indeed, points-to resources ( \(a \mapsto w\) ) express full ownership over the data at address a: possessing a resource \(a \mapsto w\) guarantees that one is the only owner of address a.

Consequently, remark that the invariant holds memory points-to for the region corresponding to non-allocated memory (between a and \(e_{m}\) ), but not for the memory that has already been allocated (between \(b_{\mathit {mid}}+1\) and a): these resources have been handed out to previous callers of the library.

We show below the specification for malloc. First, note that because malloc can fail if it runs out of memory or is given a wrong size, the specification documents that the resulting execution state is either \(\mathsf {Running}\) or \(\mathsf {Failed}\) . In the case where it does not fail, we can read that malloc hands out points-to resources for the allocated range in its post-condition: this expresses the fact that no piece of code but the caller of malloc can access the newly allocated memory.

The malloc routine can furthermore be encapsulated using a sentry capability, which can be shown to be safe to share with an adversary (Lemma 6). We highlight that sharing the entry point to the malloc subroutine with an adversary means that adversaries may dynamically allocate new capabilities at runtime, thus enriching the class of adversary programs that may safely be linked to.

The proof is comparable to the proof that \(\mathcal {V}(\small{\text{E}}, \mathsf {code}, \mathsf {end}, \mathsf {code})\) on page 34. It relies on the malloc specification and the fundamental theorem.

The final end-to-end theorems presented so far in Section 6 rely on establishing that a certain memory location satisfies a given invariant. This requires the relevant location is statically allocated in memory and thus known in advance, thus making it easy to tie it to an Iris invariant.

However, when using our malloc routine, we typically wish to enforce properties about the contents of dynamically allocated memory locations, whose address is, by definition, not known in advance. To address this issue, we implement an assert routine, to be linked alongside programs relying on malloc. One can invoke assert to dynamically test whether the contents of two registers are equal; if the test fails, assert sets a flag “assert has failed” at a fixed location in memory.

The idea is then that, to assert that some property holds about a piece of dynamically allocated memory, one can check dynamically whether it holds using assert. Then, one can prove that each assert check succeeds (meaning that the property indeed holds). Consequently, as a property of the whole execution, one gets that, at every step, the assert flag (initialized at 0) remains at 0 and is never set to 1 by assert.

The private memory of the assert routine is described by the following invariant :

The address \(a_{\mathit {flag}}\) denotes the address of the “assert flag”, which is initialized to 0 and set to 1 by the routine in case of failure. As we are interested in using assert in programs where we can prove that the equality check succeeds, we establish the following specification , which asserts in a separate invariant that \(a_{\mathit {flag}}\) remains at 0. Registers \(r_{4}\) and \(r_{5}\) contain the two integers which are compared by the routine; we thus require that they are equal.

Note that, as opposed to malloc, the assert routine should only be shared with verified code, which calls it according to the specification above. Were assert shared with an unknown adversary, the adversary could simply call the routine with two different integers, setting the flag to 1, thus invalidating any guarantees established by verified code. Technically speaking, we cannot prove safety of the assert routine from the specification above: if we try to prove \(\mathcal {V}(\small{\text{E}},b_a,e_a,b_a)\) , then we get that registers \(\mathsf {r_{4}}\) and \(\mathsf {r_{5}}\) contain two unknown (valid) words, which could be two different integers. In that case, we cannot use the specification above, as we would violate the invariant specifying that \(a_{\mathit {flag}}\) stays at 0.

We define a heap-based calling convention that uses malloc to dynamically allocate activation records. An activation record is encapsulated in a closure that reinstates its caller’s local state, and continues execution from its point of creation. Conceptually, our heap-based calling convention can be seen as a continuation-passing style calling convention (one passes control to the callee, giving it a continuation for returning to the caller). This is similar to the calling convention that was used for instance in the SML/NJ compiler to implement an extension of Standard ML with call/cc [Appel 1992] (in the setting of a traditional computer architecture).

In the setting of a capability machine, our calling convention is furthermore secure in the sense that it enforces local state encapsulation. In other words, one can use it to pass control to unknown adversarial code, while protecting local data of the caller, thanks to the use of sentry capabilities to implement the continuation. Note that this calling convention does not enforce well-bracketed control flow (another desirable property); see Georges et al. [2021]; Skorstengaard et al. [2019a, 2019b] for stack-based calling conventions that do.

We provide a call macro implementing the calling convention, invoked as call \(\mathit {target}\) \(\mathit {locals}\) \(\mathit {params}\) , where \(\mathit {target}\) is the name of the register containing a capability to the code to invoke, \(\mathit {locals}\) is the list of registers whose content corresponds to the local state to reinstate upon return, and \(\mathit {params}\) is the list of registers containing the parameters to the call (passed to the callee). Its implementation appears in Figure 11, and a representation of the corresponding memory layout in Figure 12. (Because call is defined as a macro, its code is used inline as part of a bigger program, here stored between addresses \(\mathsf {code}\) and \(\mathsf {end}\) .)

Before passing control to the callee, the call macro does the following:

When the callee passes back control to the caller by jumping to the continuation, the code stored in the activation run first. It loads the capability pointing to local state, and returns to the old program counter set up by the call macro. As the last step, the macro will finally:

We show below the specification for the code of the macro up to step 5 (the jump to the target address) . Since the malloc routine is invoked by the macro, the specification relies on the corresponding invariant for malloc. The parameters of the macro are \(\mathit {params}\) , \(\mathit {locals}\) and \(\mathit {target}\) , respectively denoting the list of registers containing the parameters to the call, the list of registers containing local state, and the register containing the capability to jump to. The list of (encoded) instructions act_instrs denote the concrete instructions making up the activation code (in Figure 11 they are written as act_instr1...act_instr5 ), which are not shown here for simplicity.

The post-condition of the specification describes the state immediately after the jump, where: the activation record has been allocated and initialized in \([{\mathit {act}},{\mathit {act}_{\mathit {end}}})\) ; register \(\mathsf {r_{0}}\) contains an enter capability pointing to the activation record, and the local data has been copied to a newly allocated region \([{l},{l_{\mathit {end}}})\) .

It is then up to the user of the call macro to establish that the capability in \(\mathsf {r_{0}}\) is safe to share with the (possibly unknown) callee. This can be done with the help of the specification for the activation code , shown next:

One can read from this specification that the activation code passes control back to the caller (at address \(\mathsf {cont}\) ), while loading in register \(\mathsf {r_{2}}\) a capability to the region holding the local state, which can be then loaded back into the corresponding registers by the restore_locals macro (step 6, which we do not detail here).

To sum up, the calling convention presented here allows one to make a “function call” as one would do in a higher-level language, while protecting local data of the caller. The code invoked this way can be completely untrusted: in particular, it does not need to implement the calling convention itself for the local state encapsulation guarantees to hold. (But of course it might never “return” and pass control back to the caller.)

In Section 7.5, we demonstrate the use of this heap-based calling convention on a simple example, showing the interaction of its local state encapsulation guarantees with read-only capabilities.

We can now provide an updated version of the adequacy theorem (Theorem 1) which directly incorporates the malloc and assert library routines. Instead of establishing that a memory invariant is always preserved at each step, the new adequacy theorem establishes that the flag held by assert is never modified.

Theorem 5 assumes that the malloc and assert routines are loaded in memory disjoint from both \(\mathit {prog}\) and \(\mathit {adv}\) . Furthermore, the assert routine must have its flag initialized to 0. The verified program \(\mathit {prog}\) is given access to both the malloc and assert routines. The adversary program \(\mathit {adv}\) is given access to malloc. We assume that \(\mathit {prog}\) contains the code and a table that has been filled by a linker with capabilities giving access to the two routines. Likewise, we assume that \(\mathit {adv}\) contains its program and data (arbitrary integers and capabilities pointing to its own region) and a table filled by the linker with the capability to the malloc routine. Similarly to the first adequacy theorem, the theorem states that if the capability machine starts with the capability pointing to \(\mathit {prog}\) in the program counter, and if it has been proved in the program logic that the machine can run until completion, then the assertion flag is never modified.

In what follows, Lemma 5 will thus allow us to prove end-to-end theorems saying that the assertion flag will still be unset after a full execution. This corresponds to the end-to-end theorems of Swasey et al. [2017] which are also phrased in terms of an assert primitive (albeit in a high-level language) that untrusted code does not get access to. Of course, such results remain a bit artificial: ultimately, in real systems, we are not directly interested in the contents of assertion flags in the system’s memory, but rather in the system’s interaction with the outside world: network communication, the content of displays, and so on. Our approach can be extended to reason about such properties, but we don’t go into details here. Instead, we refer to Van Strydonck et al. [2022], where we have done exactly this extension, by adding MMIO and external event traces to our operational semantics and using Iris invariants and ghost state to reason about them. This results in end-to-end theorems that prove security properties about the external event traces of a system, which we regard as a more realistic end goal of a verification effort.

We now present an example program sharing a read-only capability with adversary code, showcasing the combined use of the malloc (Section 7.1) and assert (Section 7.2) routines, the secure calling convention (Section 7.3), and exercising our updated adequacy theorem (Section 7.4).

Figure 13 shows the implementation of our program of interest. The program dynamically allocates a region of size 1, into which it stores the integer 1. Next, it creates a copy of the newly created capability, which is then restricted to read-only (ro). This restricted capability is shared with an unknown callee, while the original copy is kept as local state. Upon return, an assert statement checks that the region indeed still contains 1. We then wish to prove that the final assertion always succeeds.

Notice that in this example, control is passed to untrusted code, corresponding to the first scenario in Figure 2(a). However, we also allow the callee to return, i.e., jump to a callback. This is achieved using our calling convention to create a secure two-way boundary between known code and the unknown callee.

In order to prove that the assert statement succeeds, we rely on two facts. First, the heap-based calling convention guarantees the encapsulation of \((\small{\text{RWX}},b,b+1,b)\) . Second, sharing \((\small{\text{RO}},b,b + 1,b)\) with unknown code does not threaten the integrity of b, since \(\small{\text{RO}}\) capabilities cannot be used to write to memory. These two facts are key when proving the following specification:

From this functional specification, we can instantiate our updated adequacy theorem (Theorem 5) to then derive the following end-to-end theorem about our program.

The interval library implements an abstract data type representing intervals. An interval has a lower and upper bound, which can be extracted via two functions; imin and imax. An interval is created via a function makeint that takes as input two integers, and chooses the smallest input as the lower bound, and the largest input as the upper bound. Crucially, the internal representation of an interval must stay hidden so as to guarantee its integrity.

We thus use dynamic sealing [Sumii and Pierce 2004] to dynamically enforce data abstraction for the intervals representation. We detail our implementation of seals in Section 8.2. For now, it suffices to know that a seal is a pair of functions, seal and unseal, where the former hides the internal representation of some value, such that only the latter can expose it.

An interval can be represented as an ordered pair of integers. On the capability machine, we implement such a pair as a dynamically allocated region of size two, storing the lower and upper bound of the interval. Then, an interval itself consists of a capability with read/write authority over the corresponding region of size two. In Figure 14, we depict the high-level implementation of our interval library . Note that the library implements closures around a fresh seal-unseal pair, used to seal the aforementioned internal representation of intervals. The low-level implementation that we formally reason about can be thought of as the result of compiling the high-level implementation shown in Figure 14.

The same figure also depicts a client of the interval library . The client exposes four entry points to the environment: in addition to entries to makeint, imin and imax from a fresh instance of the interval library, the client also exposes an encapsulated checkint function that, given an interval, dynamically asserts that the expected representation invariant holds for the interval, that is, that the minimum of the interval is indeed smaller than or equal to the maximum of the interval.

When formally verifying the interval library and its client, we will need an invariant to keep track of each interval created by makeint. The invariant should capture the properties enforced by the implementation of the interval library. We can already list the internal properties of an interval intuitively. First and foremost, the lower bound of an interval must be less than or equal to its upper bound. A perhaps more subtle property is that intervals are immutable. Thus, we will need to define an invariant that represents each interval as a dynamically allocated region of size two, which stores the lower and upper bound, and is immutable. The seal-unseal pair encapsulated by the library will be used only to seal intervals that adhere to this representation (satisfy this invariant). Keeping this intuition in mind, let us now explore the technical implementation of seals.

Dynamic sealing makes it possible to support data abstraction dynamically. The function makeseal creates a pair of functions, seal and unseal, where seal is used to seal a word \(\mathit {w}\) into a fresh sealed word \(\sigma\) . We will also refer to \(\sigma\) as the key to \(\mathit {w}\) . The only way to extract the word \(\mathit {w}\) from \(\sigma\) is with unseal. The key point is that this seal-unseal pair supports data abstraction by sealing away or hiding the internal representation of some value, only known and available to the owner of the associated unseal function.

Although capability machines such as CHERI include seals as a language primitive, we show here how we can implement seals in software, as a low-level library. The library is implemented via a data structure that stores each word sealed through seal, associating each sealed word with a key. A key in itself does not reveal any details about the word it is hiding. However, it can provide access to that word, granted one has the proper authority to unseal it. Only a valid key should grant access to a sealed word. Keys, and the data structure that uses them, should intuitively satisfy two properties; (1) the unforgeable nature of keys and (2) the unique association between a key and the word it seals.

The seal and unseal subroutines respectively perform insertions and lookups in this underlying data structure. seal takes a word as input, generates a fresh key, and adds the key value association to the data structure. unseal takes a key as input, checks that the key is associated to a value in the data structure, in which case it returns the value.

The first key step is to formally define the representation invariant for an interval. Recall the intuitive description given in Section 8.1: an interval is a capability with authority over a region of size 2, storing the lower and upper bounds of an interval, and which is immutable.

A first thought might be that one can define the representation invariant using two points-to predicates for the region. However, this does not capture the immutability of intervals, nor is it persistent. Instead, we use persistent points-to predicates [Vindum and Birkedal 2021], a predicate from the core logic of Iris,¹¹ which can be derived by relinquishing a regular points-to predicate and transforming it into its persistent counterpart. A persistent points-to predicate \(a \hookrightarrow w\) asserts that address a stores the word w. It can be used to read from address a, but not write to it, and as such, is a persistent resource. This is exactly what we need for our immutable invariants. We formally define the representation invariant \(\mathrm{isInterval}\) as follows:

(Note, in particular, that the invariant also captures the property that the lower bound is less than or equal to the upper bound.) Using properties of persistent points-to predicates, we can prove the following lemma:

Because \(\mathrm{isInterval}\) is persistent, we can use it as the representation predicate for a seal-unseal pair, which will thus operate over the following invariant:This seal invariant is allocated by the specification for makeseal, which is invoked during the creation of an interval library closure.

When sealing a new interval using makeint, we must establish \(\mathrm{isInterval}\) for the newly created interval. This requires us to transform the regular points-to predicates handed out by the malloc specification into persistent points-to predicates, and assert that indeed \(min(z_1,z_2) \le max(z_1,z_2)\) .

Specifications for imin and imax return the respective lower and upper bound of a sealed interval. The seal invariant guarantees that the sealed word is an interval according to the representation invariant \(\mathrm{isInterval}\) . In other words, if imin or imax succeeds for some word \(\mathit {w}\) , we know that \(\mathit {w}\) is the key to some associated capability pointing to the bounds of an interval \([ {l},{r}]\) ; specifically that \(\mathrm{isIntervalInt}~l~r~w\) holds.

During the verification of checkint, the specification for imin gives us some value l and predicate \(\mathrm{isIntervalInt}~l~r~w\) . Similarly, the specification for imax gives us some value \(r^{\prime }\) and predicate \(\mathrm{isIntervalInt}~l^{\prime }~r^{\prime }~w\) . Notice that the bounds may be different, but the sealed word w is the same in each instance. We can thus apply Lemma 8 on the two given instances of \(\mathrm{isIntervalInt}\) , and use the definition of \(\mathrm{isInterval}\) to conclude that the given assert statement succeeds, namely that \(l \le r\) .

Finally, all that remains is to apply adequacy and prove the following final end-to-end theorem:

Earlier variants of Cerise focused on showing how capabilities can be used to implement a secure, stack-based calling convention [; Georges et al. 2021; Skorstengaard et al. 2019a, 2019b] and nested security wrappers [Van Strydonck et al. 2022].

Skorstengaard et al. [2019a] were the first to show that capabilities can be used to implement a secure stack-based calling convention, i.e., a calling convention where the security guarantees of function calls at the machine code level are faithful to the high-level notion of a function call. They employed an additional kind of “local” capabilities and stack clearing to achieve security. Their work follows a similar methodology as the one described here, that is, they define a logical relation which characterizes a notion of safety. However, their proofs were not mechanized and the logical relation was defined using a non-trivial concrete model; in contrast we use the Cerise program logic to define and prove properties about our logical relation, which means that our development is done at a higher-level of abstraction and thus we, e.g., do not have to solve any recursive domain equations. In follow-up non-mechanized work, Skorstengaard et al. [2019b] achieved similar security guarantees with a novel calling convention based on so-called “linear” capabilities; capabilities that can never be duplicated. Although this calling convention avoids the stack clearing required in the previous work, linear capabilities come with certain architectural restrictions [see, e.g., Skorstengaard et al. 2019b, Section 6.2]. An efficient implementation of linear capabilities has so far not been demonstrated.

The subsequent work by Georges et al. [2021] introduced a new type of capabilities (called “uninitialized”) to avoid most of the stack clearing from Skorstengaard et al.’s first calling convention, thereby improving runtime efficiency.¹² Importantly, uninitialized capabilities do not come with the same architectural hurdles as linear capabilities. As a second contribution, Georges et al. used Iris to formulate safety as a logical relation and mechanized their proofs of security. Their work was subsequently built on in Georges et al. [2022], which presents a new type of locality (called “directed”) to completely avoid stack clearing upon return, while still enforcing temporal stack safety properties. Uninitialized capabilities have been taken up in the CapStone capability-based architecture [Zhijingcheng Yu et al. 2023], where they are used to prevent leaking secrets when reallocating memory to untrusted software.

The aforementioned logical relations of both Skorstengaard et al. and Georges et al. are more expressive and therefore significantly more complicated than the one presented here: they permit reasoning about revocation of local/linear/uninitialized capabilities and well-bracketedness properties of machine-code “function calls”, on top of local-state encapsulation. In our present work, object capabilities ensure local state encapsulation, but we do not enforce calls and returns to be well-bracketed. In particular, we do not prevent an adversary from invoking a return capability several times, or storing return capabilities for later use. In other words, our calling convention implements the kind of function calls one has in a high-level language with control operators (e.g., call/cc), where calls and returns are not necessarily well-bracketed. (It is well-known that models of well-bracketed function calls are more involved than models of not-necessarily-well-bracketed function calls [see, e.g., Abramsky et al. 1998; Dreyer et al. 2012], and here we opted for the latter, to present a more accessible model, which suffices for a heap-based calling convention and for studying low-level implementations of object-capability patterns.)

In a different line of work, Van Strydonck et al. [2022] employed a capability machine and logical relations model similar to the one presented here, but with additional support for memory-mapped I/O (MMIO), to verify safety properties for small, nestable wrappers around security-critical devices on a capability architecture. As part of the verification effort, multiple end-to-end security theorems were proven, which state that safety predicates of interest hold over the trace of IO events admitted by the machine. Here we have instead focused on demonstrating how a core model (without MMIO support) can be used to reason about low-level implementations of object-capability patterns.

A number of high-level programming languages allow for programming patterns similar to object capabilities, that enable preserving local state while interacting with unknown code. Examples are closures, and high-level objects in capability safe languages.

Devriese et al. [2016] pioneered the use of a logical relation to give a semantic characterization of capability safety (earlier work used a more conservative syntactic approach based on whether or not objects contain references to each other and ignored the behaviour of objects). Devriese et al. [2016] focused on capability safety for a core calculus of Javascript, including a notion of observable effects, and used an explicit construction of their logical relation (not a program logic), which was the inspiration for the capability model by Skorstengaard et al. [2019a] mentioned above and for the work by Swasey et al. [2017], who presented a program logic which allows reasoning modularly about object capability patterns in a high-level language. The methodology of Swasey et al. [2017] is close to the one presented here, but in contrast to Swasey et al. [2017] we reason about object capabilities on a low-level machine. For instance, Swasey et al. define two predicates to describe a reference: a predicate for “high integrity” locations ( \(\ell \hookrightarrow v\) ), and one for “low integrity” locations ( \(\mathsf {lowloc}\; \ell\) ). The first predicate grants exclusive access to the corresponding reference, and is therefore not safely shareable with an adversary. The second is shareable with an adversary, but can only be used to read and write “low integrity” values. In our setting, “high integrity” directly corresponds to the predicate \(a \mapsto w\) for a memory location, and “low integrity” corresponds to the invariant used in the definition of \(\mathcal {V}\) : \(\boxed{\exists w, a \mapsto w \ast \mathcal {V}(w)}\) . Correspondingly, our definitions satisfy similar reasoning rules to the ones established by Swasey et al. In particular, we believe that the various object capability patterns they verify can be implemented and verified in a similar way in the setting of a capability machine, using the principles presented in this paper. We demonstrated one such implementation by adapting their dynamic sealing example in Section 8. Additionally, the robust safety theorem of Swasey et al. [2017] is related to our template adequacy theorem with malloc and assert (Theorem 5); our assert flag plays a role similar to the OK flag of Swasey et al. [2017].

Nienhuis et al. [2020] formally verify a number of “architectural” properties of CHERI capability machines. This constitutes a significant mechanization effort: the authors tackle the full generality of a realistic operational semantics for CHERI-MIPS. Bauereiss et al. [2022] go even further, and apply the methodology of Nienhuis et al. to the Morello CPU, which is based on the high-performance Neoverse N1 CPU and extending the Armv8 ISA, a significantly more complex ISA than both CHERI-MIPS or the minimal machine we consider here.

The approach followed by Nienhuis et al. is different from ours: they state the properties they establish as trace properties, over a trace of “abstract actions” describing the various capabilities transiting through the machine during the execution. This approach makes it possible to state the desired properties in a very explicit and concrete fashion. For instance, the authors state and prove a property of “capability monotonicity”: during the execution, the authority of available capabilities cannot increase (in other words, the machine does not allow forging new authority). Intuitively, this seems like a very reasonable property, required for proper operation of the capability machine. However, in practice it is more subtle: calls between components (in our case, jumping to an e-capability) do allow for some restricted form of non-monotonicity. The property proved by Nienhuis et al. is thus restricted to trace fragments that do not include calls to a different component. Our methodology is less explicit, but more expressive. In our setting, the fundamental theorem can be understood as expressing that “the machine works well”. Its very extensional statement is admittedly harder to understand in terms of the operational semantics of the machine, but it enables deriving correctness statements in terms of the operational semantics that do apply to a full execution of the machine, including calls between an arbitrary number of components.

As mentioned, our fundamental theorem constitutes a universal contract for arbitrary code, i.e., it allows deriving the guarantee that any adversarial capability is safe to execute, given validity of said capability. This safety is typically obtained by syntactically restricting the adversarial capability; e.g., requiring that the adressed memory only contains integers.¹³ Similar notions of universal contracts have been used for high-level languages (explicitly or implicitly) in the literature. The aforementioned work of Skorstengaard et al. [2019a, 2019b] and Swasey et al. [2017] all used a version of universal contracts, and placed varying syntactic restrictions on adversaries. The semantic type systems of Jung et al. [2017] and Sammler et al. [2020] permit similar reasoning about untrusted code based on a syntactic well-typedness restriction. The back-translation in the full-abstraction proof by Van Strydonck et al. [2019] involved an explicit, universal separation logic contract for a C-like language with capabilities. Generally, whenever a semantic model is used to describe semantic guarantees satisfied by arbitrary code (possibly subject to syntactic restrictions), and when these guarantees are used in the manual verification of other code, this can be regarded as an application of a universal contract.