
Sel4: We’re going open source - wglb
http://sel4.systems/
======
StefanKarpinski
This is an awful lot of fanfare for the open sourcing of something that was
funded with public money by the government of Australia, using open source
tools and technologies. Why isn't it already open source?

In general, I would like to see more software developed with public research
funding required to be open source as part of the grant stipulation, ideally
from early on. Too often tax-payer money is used to develop software which
then ends up being closed source and providing profit to some commercial
entity, instead of benefiting, you know, the people who payed for it – the
public.

~~~
nl
_Why isn 't it already open source?_

Not sure if you are Australian or not, but - unlike the in the US - in
Australia there is no assumption that publicly funded work will be in the
public domain.

Generally the way it works here is that bodies like Nicta (and CSIRO) are
expected to make a return on the investments that are made in them - ie, they
are expected to make money somehow. The default way they do that is generally
IP licensing.

Personally I think this is very short sighted, but it shouldn't surprise
anyone.

~~~
daveasdf
Just a little bit more on this: NICTA was originally set up as a research
group by the Australian Government with the explicit mandate of
commercialising its research.

The OKL4 and seL4 microkernels developed by NICTA were commercialised through
the company Open Kernel Labs, which was subsequently acquired by General
Dynamics (who thus acquired the IP of both projects).

At NICTA, we are very happy to see seL4 finally being open sourced: we really
do want to see our work be used as widely as possible, and open sourcing it is
going to be the best way of this happening. (So, in response to the
grandparent thread, that is why we are making a big fanfare: _we_ are excited,
even if nobody else is.)

~~~
walterbell
Will there be future work with Genode, e.g. is the codebase going to stay
focused on ARM or will it also support x86?

[http://genode.org/documentation/articles/genode-on-
okl4](http://genode.org/documentation/articles/genode-on-okl4)

~~~
daveasdf
The seL4 kernel currently supports the ARMv6, ARMv7 and x86 architectures,
though the proof only applies to ARMv6.

I am not sure what Genode's plans are. seL4 is a different kernel to OKL4,
with a substantially different API, so it will be quite some work to move it
across from OKL4 to seL4.

------
hackuser
Could someone with expertise in this area share what is really meant by "end-
to-end proof of implementation correctness and security enforcement", and the
practical implications of it? The words suggest that the kernel is 'proven' to
be absolutely secure, which obviously is false (and I don't think the authors
are trying to make that claim). So what are the precise implications for
confidentiality, availability, and integrity?

~~~
deadgrey19
Source: I have worked at NICTA, with the seL4 team, on the seL4 project, I've
seen the seL4 source code and am (was?) a primary author of the user manual.

What they mean by this is that they have specified certain properties at a
high level in a logical reasoning language they call HOL. These properties are
things like the kernel will never reference a null pointer, or, the kernel
will always run the next runable thread, or no application can access the
memory of another application, or, a capability invocation will always
terminate.

They then wrote a runable version of the kernel in Haskell (a purely
functional language) and they have a mechanically checked mathematical proof
that the Haskell code implements these features/properties. They then wrote a
(nearly entirely) C implementation of the kernel and, under a relatively small
set of preconditions, proved that the the C code exactly (no more, no less)
implements the Haskell code, which implements these correctness and security
properties.

A nasty side effect of this effort is that the C code is very strange, since
it is more or less translated Haskell code, and the kernel code must
necessarily be VERY small, about 10,000 lines of code, which is practically
nothing for an operating system kerenl (it is a micro-kernel in the truest
sense of the word). Another side effect is that the API bears almost no
resemblance with "previous" versions such as OKL4.

~~~
a-saleh
Man, I have so many questions :)

Why not just use the haskell version?

What did you use to check the haskell version?

What did you use to check that C implements what haskell implements?

Edit: I have read
[http://ertos.nicta.com.au/research/l4.verified/proof.pml](http://ertos.nicta.com.au/research/l4.verified/proof.pml),
but I'd like to know more about tooling. Like, did you use agda, e.t.c?

~~~
deadgrey19
I can't answer all of these questions authoritatively, as I have more of a
systems focus than a formal methods focus, but I can hopefully point you in
the right directions. The various published papers and final release will be
the right places to find all the authoritative answers.

1) Why not use the Haskell version? The Haskell version was (is?)
"executable", but it ran only against a hardware simulator, never against real
hardware. Haskell has a complex runtime which is not (easily) suitable to run
directly on Hardware (although one student I worked with did port a subset of
the Haskell runtime to work on top of seL4). Using Haskell directly would be
slow, and would require the researchers to prove the correctness of the
Haskell runtime implementation as well which would be a huge amount of work.

2) What did you use to check the haskell version? I was not directly involved
in this. I believe the Haskell used to write the kernel was a subset of the
language, they call "literate haskell" which was used to both implement and
specify the kernel. This was somehow minimally translated into a dialect of
Isabelle called HOL.

3) What did you use to check that C implements what haskell implements? A
similar process was used for checking that the C implementation was a
refinement of the Haskell. Again, a restrictive subset of the C language a
tool was written to translate the C code into HOL (I think). I remember the
team lead arguing that the way the C implementation was checked, both the code
itself and the translator could be checked for bugs.

AFAIK, The tooling was almost all custom except for relying on Haskell and the
Isabel theorem prover. The group had a lot of experience for building and
releasing the OKL4 kernel so a lot of the dirty work was already done as well
as an excellent "Advanced Operating Systems Course" which whips and tortures
undergraduates into systems engineers and ideally PhD students. :-)

~~~
a-saleh
Interesting.

I have already seen the approach "Lets design this in haskell and write
production code in C" for [http://cryptol.net/](http://cryptol.net/), but due
to limited scope (mostly functions of several hundered bits input and output
as customary in crypto-primitives), they were able to check that the
implementation adheres to specification automatically. The aim was to allways
know that the c code does what it is supposed to, so that programmer can focus
on mitigating side-channel attacks :)

I wonder if something similar would be applicable to writing the micro-
kernell.

------
webmaven
<blockquote>All will be under standard open-source licensing
terms.</blockquote>

Hmm. Lumping together the mind-bogglingly broad variety of Free/Libre/Open
Source licensing options as something 'standard' does not instill confidence.

That said, perhaps they are using something standard, like straight-up Apache,
GPL, or BSD.

------
sj4nz
This will be pretty exciting for anyone learning operating systems. More
source to read.

[https://en.wikipedia.org/wiki/L4_microkernel_family](https://en.wikipedia.org/wiki/L4_microkernel_family)

~~~
deadgrey19
Beware, since the source is a translation of Haskell into C, this is not an
entry level source tree and is not straightforward to read/understand despite
it's small (LOC) size.

~~~
sj4nz
If so, it'll still be interesting to see what they've done with Haskell to
make a secure operating system from the L4 model--I assume they are also
releasing the Haskell source as well, otherwise there would be no point to it
all.

------
zmanian
There seems to be a lot of utility here for folks developing hardware based
public key infrastructure like BitCoin wallets.

------
mkesper
Beware of bugs in the above code; I have only proved it correct, not tried it.

[https://en.wikiquote.org/wiki/Donald_Knuth](https://en.wikiquote.org/wiki/Donald_Knuth)

Anyway, here, the Haskell code should be considered the real source code,
right?

------
pkaye
Does "end-to-end proof of implementation correctness and security enforcement"
mean there is zero change of a bug or security flaw?

~~~
aidenn0
No.

There may be a flaw in the security model that they correctly implemented.

There _are_ bugs in every ARMv6 ever made, and some of them may allow crashes
ore security vulnerabilites.

------
luckydude
"In short, the implementation is proved to be bug-free."

Has any smart person looked at their claims enough to vouch for them?

~~~
mlinksva
Some discussion by smart people at [http://www.eros-os.org/pipermail/cap-
talk/2014-June/thread.h...](http://www.eros-os.org/pipermail/cap-
talk/2014-June/thread.html#16120) ... probably have to wait til after it is
open source end of next month to say.

~~~
cottonseed
You can download seL4 binaries and a copy of the specification (190 pages, no
proof) here:

[http://ssrg.nicta.com.au/software/TS/seL4/](http://ssrg.nicta.com.au/software/TS/seL4/)

------
anonymousDan
Can anyone comment as to how feasible/practical it would be to extend these
proofs to a multicore chip?

~~~
angry_octet
Very, very hard, if you mean kernel threads running in parallel. However, if
the other cores run separate kernel instances (machine partitioning, separate
memory and everything) that would be more achieveable. UNSW call this the
clustered micokernel approach.

~~~
anonymousDan
Thanks for that. Kind of what I expected. I wonder if the problem could be
simplified if techniques from deterministic/stable multithreading could be
incorporated somehow to simplify the formalization
([http://dl.acm.org/citation.cfm?id=2566590.2500875](http://dl.acm.org/citation.cfm?id=2566590.2500875))

------
fsiefken
This might become a good competitor for OpenBSD and the hardened linux.

~~~
AlyssaRowan
Well, there's a lot of bits missing - this is a _microkernel_!

But I've seen seL4 before, and this is a very solid (if slightly weird-
looking) foundation to work from.

I hope they choose a good licence; MIT or GPLv3 or GPLv2 or something. (It's a
microkernel, so my general impression is GPL wouldn't be intended to spread
between kernel components.)

This could be a QNX-killer. Eventually, one day, maybe a worthy replacement
for OpenBSD or hardened Linux, but it's got a long way to go. It's ideal for
anyone developing embedded hardware, however, and L4 variants are already very
widely-used there.

Are you developing an open-source trusted security coprocessor? (I know at
least two teams are.) Then this is probably what you want to run on it... of
course, we'll want to check it ourselves as a community first, too, just in
case.

------
rdtsc
Anyone from RTOS community know how this relates to INTEGRITY-178B ?

~~~
daveasdf
INTEGRITY-178B and seL4 are not related in terms of their source code or
origin, though they do both aim at the same target audience (security and/or
safety-critical systems).

I don't have a good knowledge of INTEGRITY-178B, but as far as I can tell some
differences are:

* INTEGRITY-178B is a static separation kernel. seL4 can be used as a static separation kernel, but also allows for dynamic systems, for instance with processes being created and torn-down dynamically at run-time;

* INTEGRITY-178B has a proof that a _model_ of the code satisfies particular security properties, while seL4 has a proof that the actual C implementation satisfies particular properties;

* INTEGREITY-178B is certified to EAL6+, while seL4 has not undergone any external certification process. (Without having a good knowledge of EAL6+, my suspicion would be that the code-level aspects of seL4 would meet or exceed EAL6+ certification, while the process-level aspects would need work on the seL4 side.)

If someone has worked with INTEGRITY-178B, please correct me if I have made
any mistakes.

~~~
rdtsc
Thank you for responding that is a good description.

I remember someone from one of the government agencies gave a talk at in
college many years ago about INTEGRITY-178B and about this separation kernel
idea.

That was maybe 7-10 ago. The idea was pretty neat. And the claim was that the
future will belong to more secure OSes based on this separation kernel
(microkernel?). And how say every little component -- memory, filesystem,
mouse, display are all in userspace. He talked about ok general purpose
computer at that time were too slow to operate in that way (so Linux was
better and winning because of performance). But just wait some 10 years or so
and machines will be so fast that it won't matter.

So since then that story kind of stuck with me that kind of prompted the
question.

------
mantraxC
Hmm, given how compilers & hardware can introduce incorrectness and security
vulnerabilities in otherwise valid code, it makes you wonder if anyone can
really claim "end-to-end proof of correctness" unless they include the
specific compiler & hardware in their proof.

~~~
TacticalCoder
Concerning the compiler, in the link it is written:

 _" There is a further proof that the binary code that executes on the
hardware is a correct translation of the C code. This means that the compiler
does not have to be trusted, and extends the functional correctness property
to the binary."_

(I wonder how that works but it is related to your compiler concern)

Now even though the issue of hardware (say rogue hardware with rigged number
generators and whatever backdoors) is probably a real concern, I still think
that seL4 and its codebase where hundreds of bugs have been automatically
found (and manually squashed) is a big step forward.

~~~
Avshalom
On that note: what even is a correct translation of C when it has so many
undefined behaviors in it's spec.

~~~
wmf
What if the code doesn't rely on undefined behavior?

~~~
regehr
Absence of undefined behavior in the C implementation is of course one of the
things covered by the seL4 proof.

------
UweSchmidt
Love the default bootstrap theme <3

------
dead10ck
"In short, the implementation is proved to be bug-free."

This reeks of bull shit.

"We still assume correctness of hand- written assembly code, boot code,
management of caches, and the hardware"

Sorry, I don't think you can claim you have a mathematical proof of the
correctness of your kernel when you assume this much.

And where is this proof? I can't seem to find it anywhere on their web site.
The only thing I can find is the publication

"seL4: Formal Verification of an Operating-System Kernel"
[http://ertos.nicta.com.au/research/l4.verified/pubs.pml](http://ertos.nicta.com.au/research/l4.verified/pubs.pml)

which looks like it just talks about the proof, rather than providing it. Am I
just blind?

This looks interesting, but the confidence which they espouse is very
suspicious.

~~~
nl
I'm not sure you are aware, but formal verification[1] is a well known and
respected field of research. It does work, but it is hard to build practical
tools using it. Nevertheless, if something is formally proven correct then for
it to be incorrect one of three things must happen:

1) The proof is incorrect (which of course means it is no longer proven)

2) The prover has a bug (most proofs are done automatically). This is
possible, but many of the same formal methods are used on the prover, and it
is often build on a human-proved proof at the bottom.

3) Mathematics (the whole field) is wrong. This seems unlikely.

In reality, the problem with formally verified software is generally that it
must interact with non-verified software (and sometimes hardware - although
hardware can be verified too).

The wikipedia page[1] I referenced is worth reading.

[1]
[http://en.wikipedia.org/wiki/Formal_methods](http://en.wikipedia.org/wiki/Formal_methods)

~~~
josephlord
4) It meets the specification but the specification is incorrect/specifies
sub-optimal behaviour.

~~~
nl
If you can fix _that_ problem in the general case then you are about to be a
very, very rich person.

