Lessons Learned From Microkernel Verification — Specification is the New Bottleneck

Baumann, Christoph; Beckert, Bernhard; Blasum, Holger; Bormer, Thorsten

doi:10.4204/eptcs.102.4

Cited by 35 publications

(20 citation statements)

References 18 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Similar to [3], we observed that strong abstraction capabilities of the used tools are essential. KIV supports arbitrary user-defined data types (given suitable axioms), which was for example exploited to abstract the pointer structure to an algebraic tree and to abstract the sparse pages of files to streams (see Sec.…”

Section: Lessons Learnedsupporting

confidence: 58%

Development of a Verified Flash File System

Schellhorn

Ernst

Pfähler

et al. 2014

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract. This paper gives an overview over the development of a formally verified file system for flash memory. We describe our approach that is based on Abstract State Machines and incremental modular refinement. Some of the important intermediate levels and the features they introduce are given. We report on the verification challenges addressed so far, and point to open problems and future work. We furthermore draw preliminary conclusions on the methodology and the required tool support.

show abstract

Section: Lessons Learnedsupporting

confidence: 58%

Development of a Verified Flash File System

Schellhorn

Ernst

Pfähler

et al. 2014

Lecture Notes in Computer Science

View full text Add to dashboard Cite

show abstract

“…First, OS kernels (and other system software) contain many interdependent components that are difficult to untangle. Writing down their specifications is already extremely challenging [1]. Making these specifications compositional has a major impact on the overall cost of the entire verification effort.…”

Section: Overviewmentioning

confidence: 99%

Clean-Slate Development of Certified OS Kernels

Shao

2015

Proceedings of the 2015 Conference on Certified Programs and Proofs

View full text Add to dashboard Cite

The CertiKOS project at Yale aims to develop new language-based technologies for building large-scale certified system software. Initially, we thought that verifying an OS kernel would require new program logics and powerful proof automation tools, but it should not be much different from standard Hoare-style program verification. After several years of trials and errors, we have decided to take a different path from the one we originally planned. We now believe that building large-scale certified system software requires a fundamental shift in the way we design the underlying programming languages, program logics, and proof assistants. In this talk, I outline our new clean-slate approach, explain its rationale, and describe various lessons and insights based on our experience with the development of several new certified OS kernels. OverviewOperating System (OS) kernels and hypervisors form the backbone of every safety-critical software system in the world, so it is highly desirable to formally verify the correctness of these programs [18]. During the last 10 years, we (the FLINT group at Yale) have developed a large number of program logics (for C and assembly) to support modular verification of low-level constructs such as storage allocation [21,3], embedded code pointers [15], stack-based control abstractions [7], machine context management [16], self-modifying code [2], garbage collectors [14], hardware interrupts and preemptive threads [5], nonblocking concurrency [4, 8, 12], concurrent thread management [11], and virtual memory management [20].We have also developed a certified linking framework [6] and used it to compose heterogeneous program components to build end-toend certified systems.In 2010, we were ready to test these program logics on a realistic OS kernel [19,9]. The new CertiKOS project aimed to develop language-based techniques for building large-scale certified system software. We wanted to explore the design space of various OS kernel architectures, but on the verification side, we thought that it is mostly a matter of proof engineering: we will develop more domain-specific program logics and powerful proof automation tools, but we would likely stick to the original path which followed the spirit of standard Hoare-style program verification.After several years of trials and errors, we have decided to take a different path [10]. We now believe that building large-scale certified system software requires a fundamental shift in the way we design the underlying programming languages, program logics, and proof assistants. More specifically, we advocate a clean-slate approach that uses compositionality as a decisive factor in choosing the underlying programming and specification languages and on forming certified software components. Language features that have no simple and clean compositional semantics should either be avoided completely or be encapsulated inside a single module. Certified system software should have highly compositional specifications and be built strictly using compositional b...

show abstract

“…In this evaluation we did not consider lower levels, including caches and pipelines, as they are not simulated by the underlying emulator. 6 We focused the evaluation on the generally accepted single-error single-bit assumption. This means that for a certain experiment, a fault occurs at any point in time, but only once and is limited to a single register or memory word.…”

Section: B Evaluation Scenario: I4coptermentioning

confidence: 99%

“…Other approaches integrate dependability services into the operating system [10], which simplifies the realization of triple modular redundancy (TMR), but does not protect the kernel itself against transient faults. Even the existing ISO-26262-compliant real-time operating systems ensure only strict isolation of the deployed applications against each other (typically by employing hardware-based memory protection [4] or hypervisor [6] technology), but not against faults that occur in the respective kernel structures.…”

Section: Introductionmentioning

confidence: 99%

dOSEK: the design and implementation of a dependability-oriented static embedded kernel

Hoffmann

Lukas

Dietrich

et al. 2015

21st IEEE Real-Time and Embedded Technology and Applications Symposium

View full text Add to dashboard Cite

Abstract-Because of shrinking structure sizes and operating voltages, computing hardware exhibits an increasing susceptibility against transient hardware faults: Issues previously only known from avionics systems, such as bit flips caused by cosmic radiation, nowadays also affect automotive and other cost-sensitive "ground-level" control systems. For such cost-sensitive systems, many software-based measures have been suggested to harden applications against transient effects. However, all these measures assume that the underlying operating system works reliably in all cases. We present software-based concepts for constructing an operating system that provides a reliable computing base even on unreliable hardware. Our design is based on two pillars: First, strict fault avoidance by static tailoring and elimination of susceptible indirections. Second, reliable fault detection by finegrained arithmetic encoding of the complete kernel execution path. Compared to an industry-grade off-the-shelf RTOS, our resulting dOSEK kernel thereby achieves a robustness improvement by four orders of magnitude. Our results are based on extensive fault-injection campaigns that cover the entire space of single-bit faults in random-access memory and registers.

show abstract

Lessons Learned From Microkernel Verification — Specification is the New Bottleneck

Cited by 35 publications

References 18 publications

Development of a Verified Flash File System

Development of a Verified Flash File System

Clean-Slate Development of Certified OS Kernels

dOSEK: the design and implementation of a dependability-oriented static embedded kernel

Contact Info

Product

Resources

About