Channels ▼

Jonathan Erickson

Dr. Dobb's Bloggers

100% Verifiable Bug-Free Code Is Possible

August 12, 2009

 It doesn't matter how bug-free your application software is if the underlying OS is bug-ridden. But considering the size and complexity of modern operating systems (Windows XP is said to consist of more than 40-million lines of code), bug-free is easier said than done.

The usual solution then, is simply to reduce the amount of privleged code (that is, the part of the system executing in the most privleged mode of the processor), following the principle of "less code means fewer bugs". On the other hand, this approach does impose limitations of sorts.

While that may seem satisfactory in some regards, it isn't satisfactory to researchers at Open Kernel Labs (OK Labs) and Australia's  National Information and Communications Technology Research Centre (NICTA) who clearly fall into the category of people who "want their cake and eat it too." In other words, they wanted a verifiable correct, reliabile, and secure  microkernel that was also powerful.

Consequently, they set out to create a mathematical method for proving the correctness of the underlying source code of OKL4, OK Labs' virtualization platform for mobile devices using formal logic and programmatic theorem checking. And what they ended up with was seL4, to the best of their knowledge "the world's first 100% verified 'bug free' embedded software." The verification process they implemented eliminated a wide range of exploitable errors, such as design flaws and common code-based errors, buffer overflows, null-point dereferences, memory leaks, arithmetic overflows, and exceptions.

The seL4 kernel (short for "secure embedded L4") is a third-generation microkernel, comprising 8,700 lines of C code and 600 lines of assembler, that runs on ARMv6 and x86 platforms. According to OK Labs, this is the first formal proof of functional correctness of a complete, general-purpose operating-system kernel. In this case, "functional correctness" means that the implementation always strictly follows a high-level abstract specification of kernel behavior. This includes traditional design and implementation safety properties (such as the kernel will never crash, and it will never perform an unsafe operation). It also proves that programmers can predict precisely how the kernel will behave in every possible situation.

According to OK Labs:


  • seL4 is suitable for real-life use, and able to achieve performance that is comparable with the best-performing microkernels.
  • seL4's behavior is precisely formally specified at an abstract level.
  • seL4's formal design is used to prove desirable properties, including termination and execution safety;
  • seL4's implementation is formally proven to satisfy the specification.
  • seL4's access control mechanism is formally proven to provide strong security guarantees.
As described in the paper seL4: Formal Verification of an OS Kernel, the formal verification the researchers used is the Isabelle/HOL theorem prover, developed by Tobias Nipkow, Lawrence C. Paulson, and Markus Wenzel. Isabelle/HOL is an interactive theorem prover that requires human intervention. That said, it isn't constrained to specific properties or finite, feasible state spaces, unlike more automated methods of verification such as static analysis or model checking. They point out that for programs to be formally verified they must have formally-defined semantics, and one of the achievements of seL4 project is an exact and faithful formal semantics for a large subset of the C language.

All in all, the paper describing what NICTA and OK Labs have done is fascinating, not to mention the project itself.

Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 


Video