
Hyperkernel – A push-button approach to building provably correct OS kernels - lainon
https://unsat.cs.washington.edu/projects/hyperkernel/
======
Animats
That's impressive. The approach works well given simple data structures. Their
OS is a reimplementation of the UNIX V6 kernel, where most data structures
were arrays, searched linearly. That's within the reach of the automated
provers which use Scaling this up to huge servers might be a problem.

This little verified OS should be useful for routers, IoT devices, and such.

------
andrewflnr
Doing this kind of thing with a "mere" SMT solver seems pretty amazing to me.
Haven't previous attempts to verify OS implementations and such all used
heavy-duty dependent typesystems, higher-order logic and the like?

~~~
snaky
It might be fruitful to combine two approaches, like for example VigNAT
authors did

> The beauty of symbolic execution lies in its ease of use: it enables
> automatic code analysis, hence can be used by developers without
> verification expertise. The challenge with symbolic execution is its
> notorious lack of scalability: applying it to real C code typically leads to
> path explosion. The part of real NF code that typically leads to
> unmanageable path explosion is the one that manipulates state. Hence, we
> split NF code into two parts:

> A library of data structures that keep all the “difficult” state, which we
> then formally prove to be correct—this takes time and formal methods
> expertise, but can be amortized if the library is re-used across multiple
> NFs.

> Stateless code that uses the library, which we automatically and quickly
> verify using symbolic execution.

> The challenge lies in combining the results of these two verification
> techniques, and for that we developed a technique we call “lazy proofs”

[https://vignat.github.io/](https://vignat.github.io/)

------
badrabbit
Just a thought,this only proves the code is correct assuming hardware and
firmware assumptions are also correct. Is it even possible to prove
correctness of hardware? I've never heard of verified firmware as well.

~~~
zaarn
You can prove correctness of software, firmware and hardware and still have it
all come crashing down the moment a bit flips.

There is no solution to such things as "bitflip in memory" because once that
happens, all bets are off. Instructions could be entirely wrong, page tables
could have been corrupted, pointers in kernel memory pointing anywhere but
where they belong, fire and brimstone raining from the sky, the dead walking
among the living and the local supermarket running out of chocolate.

You can however reduce the risk that such a bitflip results in a full system-,
security- or application failure via various means (the Apollo 11 computer for
example was capable of simply restarting a program at various checkpoints if
they crashed and had multiple software and hardware safeguards against
bitflips and random crashes).

~~~
natmaka
Aren't ECC RAM and redundancy able to keep both the dead and the chocolate
where they belong?

[https://en.wikipedia.org/wiki/ECC_memory](https://en.wikipedia.org/wiki/ECC_memory)
[https://en.wikipedia.org/wiki/Redundancy_(engineering)](https://en.wikipedia.org/wiki/Redundancy_\(engineering\))

~~~
zaarn
With some probability, yes, but it's still non-zero. There are other failures
where ECC doesn't help (ie, bitrot on your SSD or Harddrive, cosmic ray
hitting the CPU itself, anything that does DMA).

The best we can do is deploy ECC, hope the cosmic rays don't hit our
Datacenter too hard and design software to fail fast if it fails, even if math
says it can't fail. Because it will fail.

~~~
adrianN
It's not impossible to add enough error correction and redundancy to your
stuff that it's more likely that we're wiped out by an asteroid than for your
software to crash because of cosmic rays.

------
dwheeler
Very interesting! Sadly, their code does not seem to have a license. Hopefully
they will correct that soon. No one gets to opt out of laws, and the default
laws don't really let you do anything.

~~~
dooglius
There is a license section in the readme

~~~
dwheeler
Thanks!

That helps, but doesn't answer the question. This part is very helpful:

> Files we created are licensed under the Apache License, Version 2.0,
> viewable at
> [http://www.apache.org/licenses/LICENSE-2.0](http://www.apache.org/licenses/LICENSE-2.0),
> and are marked as such.

This part makes it useless:

> Code borrowed from other sources keeps the original copyright and license.

What are those licenses? If they used a package manager I could just see that
(a nice easy list). As it is, I can't tell what rights and requirements I
have.

~~~
frankmcsherry
In case you are sincerely interested, the literal very next section enumerates
which other projects they borrow from and their corresponding directories in
the repo. I'm sure you can come back with "the xv6 dependence is
underspecified" or whatever, but maybe let's wait until it turns out you
actually want to use any of this before getting excited about your troubles
with the licensing.

------
jiveturkey
uniprocessor only so i guess limited to embedded systems.

does formally verified also mean bug-free?

~~~
vinceguidry
Beware of bugs in the above code; I have only proved it correct, not tried it.
-- Donald Knuth

Code meeting spec doesn't magically make the spec right.

~~~
wiz21c
Is it already the case that a specification good enough to prove a program is
bug free is smaller/less complex than the program itself. Because if it is
not, then I'd assume the risk of failure in the specification just becomes
bigger than in the program itself... So you'd need another tool to prove that
the spec is correct...

~~~
naasking
Or you have the spec written twice, by two independent people and then
compare.

~~~
vinceguidry
SQLite has three independently developed test codebases.

