
CertiKOS: A breakthrough toward hacker-resistant operating systems - spankipants
http://news.yale.edu/2016/11/14/certikos-breakthrough-toward-hacker-resistant-operating-systems
======
no_protocol
I found the linked news piece as impenetrable as this project claims to be.
Something just feels wrong about the organization of ideas.

The conference paper (in pdf format) is located here:

[https://www.usenix.org/system/files/conference/osdi16/osdi16...](https://www.usenix.org/system/files/conference/osdi16/osdi16-gu.pdf)

Section 2 of the paper seems to be a thorough and mostly readable overview of
the project and was much more enlightening than the YaleNews piece. I didn't
end up reading the remainder of the paper.

~~~
Animats
That's a prettier version of the Yale paper.[1]

Key points:

\- It's a hypervisor. It usually needs a guest OS on top, which is,
inevitably, Linux. Code size of the hypervisor is about 6500 lines. The OS
itself is written in some subset of C and in assembler. Both are formally
verified against a specification, written in a formal specification language.

\- The big advance over L4 is that this kernel does concurrency. The verified
version of L4 can't do that, and has one big kernel lock, because their proof
system can't deal with concurrency. This is why L4 avoids passing long
messages; it locks up the system.

\- I've been trying to find more about the specification language and the
subset of C. There are some very simple examples here.[2] But in the examples,
the spec is so close to the code that it's not interesting. I did some work on
formal specification of an OS years ago (the KSOS referenced in the paper
here), so I'm curious to see how they addressed this.

\- They haven't done a file system yet. (That's a good problem for formal
specification, because the abstract semantics of a file system are simple;
it's an efficient implementation that's hard.)

[1]
[http://flint.cs.yale.edu/certikos/publications/certikos.pdf](http://flint.cs.yale.edu/certikos/publications/certikos.pdf)
[2] [http://flint.cs.yale.edu/flint/publications/dscal-
talk.pdf](http://flint.cs.yale.edu/flint/publications/dscal-talk.pdf)

~~~
jroesch
There have already been two file system verification projects, this year's
OSDI best paper is the most recent example,
[http://locore.cs.washington.edu/papers/sigurbjarnarson-
yggdr...](http://locore.cs.washington.edu/papers/sigurbjarnarson-
yggdrasil.pdf), and last year as SOSP FSCQ:
[http://sigops.org/sosp/sosp15/current/2015-Monterey/013-chen...](http://sigops.org/sosp/sosp15/current/2015-Monterey/013-chen-
online.pdf)

~~~
nickpsecurity
Holy crap! That some great improvements together with the COGENT paper I
posted in this sub-thread. I'd love to see them try to overlap in their strong
suits. Push-button is hard to argue with, though. Thanks for the links. :)

------
legulere
Formal verification (what this seems to be about) can be a nice tool to verify
something adheres to a specification or that it has no e.g. buffer overflows.

But I think that is not really the big problem we have. I think it is
operating system interfaces. By default a process is in its own address space
and cannot do anything dangerous. It is only with the operating system API
(which is the syscalls or an C API that uses syscalls) that it can do
dangerous things like writing in the filesystem. Posix defines such an API
which allows every program to do the same as the user running it. Windows does
the same. This would be fine in a world where we can trust each program we run
to not be malicious and to not be exploitable. Now we are trying to make those
inherently unsafe APIs safe via sandboxing, but I guess that it is much easier
to create a new API that is safe from the beginning.

~~~
jojo3000
This is orthogonal. But first, there are still buffer overflows, null pointer
accesses & segmentation faults, etc. in the kernel happening. And this is a
big problem!

But lets assume this is solved. Then a API can be checked for certain
properties. You can specify what it means that something is read-only in an
environment etc. And ensure that it is enforced by the operating system.

As example: the verification of seL4 not only guarantees avoidance of
classical security holes (buffer overflows etc.) but also certain non-
interference properties.

------
vander_elst
What's the difference with this
[https://sel4.systems/](https://sel4.systems/)?

~~~
nickpsecurity
The main difference is the verification/design method. seL4 does the abstract
machine in Haskell, model in HOL, and final code in C. Both Haskell and C are
shown equivalent. It took a ton of work. They also have to use these two tools
for expressing all kinds of solutions they're not ideal for.

CertiKOS is using a DSL approach if it's same as paper I'm remembering. They
design languages or proving techniques ideal to the type of thing they're
working on: memory management, I/O, etc. They prove each individual component
as easily as they can. Then they have some way of modeling the system as a
whole and/or integrating those. Too early to judge but they seem more
productive than L4 project was due to tooling benefits.

~~~
indolering
According to one of the talks I watched, they are moving towards using more
domain-specific languages.

~~~
nickpsecurity
That's ambiguous. Are you talking about seL4 or CertiKOS people?

~~~
indolering
The seL4 team, they have taken this approach with their drivers and ext2
implementation. Apparently it is part of a more general strategy [0].

[0]
[https://archive.fosdem.org/2015/schedule/event/sel4/](https://archive.fosdem.org/2015/schedule/event/sel4/)

~~~
nickpsecurity
Ok. Good they're doubling down on it.

------
smilekzs
> One of the main breakthroughs of CertiKOS is that it supports concurrency,
> meaning that it can simultaneously run multiple threads (small sequences of
> programmed instructions) on multiple central processing unit (CPU) cores.

Isn't this parallelism?

~~~
BraveNewCurency
[https://www.youtube.com/watch?v=cN_DpYBzKso](https://www.youtube.com/watch?v=cN_DpYBzKso)

Rob Pike's talk on why 'Concurrency Is Not Parallelism'

~~~
BraveNewCurency
Oops, that may not have been your question.

------
progman
Ok, now we can run a verified OS on multiple cores. Now, what value has
verified software which runs on buggy or (theoretically) compromised hardware?

In my opinion safe computing requires verified software AND verified hardware.
Since proprietary SW/HW cannot be trusted in general truly safe computing
vitally depend on open software and open hardware.

~~~
naasking
> Now, what value has verified software which runs on buggy or (theoretically)
> compromised hardware?

The vast majority of bugs and vulnerabilities are due to software, not
hardware. There's tremendous value in pushing that boundary back to the
hardware layer.

~~~
posterboy
When hardware comes with multiple levels of firmware, there is hardly any
difference.

~~~
naasking
A search for "linux" in NVD returned over 4,500 entries. "firmware" has barely
900. So I'd say there's definitely a meaningful difference, and operating
system kernels have been used in firmware (Linux and L4 have at least), so
formally verifying kernels can eliminate firmware vulnerabilities too.

------
forgottenacc57
Is this real software or some academic thing?

~~~
hga
Just glancing at their site, I suspect it's real, however, I doubt it's
interesting to us except as an academic example:

Only open source code I could find (and it's not linked from their site that I
could find) is here, it's tooling:
[https://github.com/CertiKOS](https://github.com/CertiKOS)

For Coq, which is the proof system they use, but also for extending the
CompCert verified C compiler, which requires a commercial licence if you use
it beyond "evaluation, research and education purposes". And given the domain,
and of course you have to talk to a salesman, I'm sure it's not cheap, 6
figures a seat in USD would not be out of the question if not likely, I'm sure
it's 5 figures at minimum.

This is in part because this sort of software is inherently more expensive,
and for the people who _really_ need to use these sorts of tools, like those
building airplanes, it's cheap at the price. But by basing it on CompCert,
they've got what's likely to be a very high floor for playing the game they've
not (yet) invited us to.

By comparison, seL4 is now totally free (well, GPLed, but that's not a problem
for software like it), and part of that is because they actually tried
CompCert, but there was an impedance mismatch in connecting it to their higher
level stuff, so they went with Magnus Myreen and his approach of analyzing
(GCC produced in this case) binary code and connecting that to the higher
level proofs.

------
amelius
Does this mean no more jailbreaking for iOS and Android?

:(

