---
readstatus: true
dateread: 
title: Formally verified software in the real world
year: 2018
authors:
  - Klein, Gerwin
  - Andronick, June
  - Fernandez, Matthew
  - Kuz, Ihor
  - Murray, Toby
  - Heiser, Gernot
DOI: 10.1145/3230627
ISBN: ""
citekey: kleinFormallyVerifiedSoftware2018
itemType: journalArticle
journal: _Commun. ACM_
volume: 61
issue: 10
pages: 68–77
---
#### DOI
[10.1145/3230627](https://doi.org/10.1145/3230627)
#### ISBN
[](https://www.isbnsearch.org/isbn/)

### Tags:
#formal-verification, #Control-systems, #Cybersecurity, #penetration-testing, #Formal-methods

**Contribution**:: 

**Related**:: 

> [!LINK] 
>
>  [Full Text PDF](file:///home/danesabo/Zotero/storage/CVGJMIHP/Klein%20et%20al.%20-%202018%20-%20Formally%20verified%20software%20in%20the%20real%20world.pdf).

> [!Abstract]
>
> Verified software secures the Unmanned Little Bird autonomous helicopter against mid-flight cyber attacks.
>.
> 
# Notes
>.


# Annotations%% begin annotations %%


### Imported: 2024-08-12 4:55 pm



<mark style="background-color: #ffd400">Quote</mark>
> key insights ˽ Formal proof based on micro-kernelenforced software architecture can scale to real systems at low cost. ˽ Mixed assurance levels and security levels within one system are possible and desirable; not all code has to be assured to the highest level. ˽ High assurance can be retrofitted to suitable existing systems with only moderate redesign and refactoring.

<mark style="background-color: #5fb236">Quote</mark>
> Its foundation is our verified microkernel, seL4, discussed later, which guarantees isolation between subsystems except for well-defined communication channels that are subject to the system’s security policy.

<mark style="background-color: #ffd400">Quote</mark>
> Note we primarily use formal verification to provide proofs about correctness of code that a system’s safety or security relies on. But it has other benefits as well. For example, code correctness proofs make assumptions about the context in which the code is run (such as behavior of hardware and configuration of software). Since formal verification makes these assumptions explicit, developer effort can focus on ensuring the assumptions hold—through other means of verification like testing. Moreover, in many cases systems consist of a combination of verified and non-verified code, and in them, formal verification acts as a lens, focusing review, testing, and debugging on the system’s critical nonverified code.

<mark style="background-color: #5fb236">Quote</mark>
> The mechanisms support its use as a hypervisor to, say, host entire Linux operating systems while keeping them isolated from security-critical components that might run alongside, as outlined in Figure 1. In particular, this functionality allows system designers to deploy legacy components that may have latent vulnerabilities alongside highly trustworthy components.

<mark style="background-color: #ffd400">Quote</mark>
> The dual of integrity is confidentiality, which states that a component cannot read another component’s data without permission,2

<mark style="background-color: #ffd400">Quote</mark>
> the link between Linux and the crypto component in Figure 4 is for message passing only and does not give access to memory. Only authenticated messages can reach the CAN bus, as the crypto component is the only connection to the driver. Untrusted payload software and WiFi are, as part of the Linux VM, encapsulated by component isolation and can communicate to the rest of the system only via the trusted crypto component.

<mark style="background-color: #f19837">Quote</mark>
> The mechanisms of the seL4 kernel discussed earlier can achieve this enforcement, but the level of abstraction of the mechanisms is in stark contrast to the boxes and arrows of an architecture diagram; even the more abstract access-control policy still contains far more detail than the architecture diagram. A running system of this size contains tens of thousands of kernel objects and capabilities that are created programmatically, and errors in configuration could lead to security violations. We next discuss how we not only automate the configuration and construction of such code but also how we can automatically prove that architecture boundaries are enforced.

<mark style="background-color: #5fb236">Quote</mark>
> Due to the isolation provided by seL4 and the componentized architecture, it becomes possible for components of mixed assurance levels to coexist in the system without decreasing the overall assurance to that of the lowest-assurance component or increasing the verification burden of the lowest-assurance components to that of the highest-assurance ones.

<mark style="background-color: #ffd400">Quote</mark>
> The right granularity is a trade-off between the strength of isolation on the one hand and the increased overhead and cost of communication between partitions, as well as re-engineering cost, on the other.


%% end annotations %%

%% Import Date: 2024-08-12T16:55:33.616-04:00 %%
