
Unhackable Kernel? - bootload
https://www.newscientist.com/article/mg22730392-600-unhackable-kernel-could-keep-all-computers-safe-from-cyberattack-2
======
achille
Note that the SEL4 kernel is only a small portion of this project. They've
secured the entire stack, top to bottom.

HACMS leverages a number of other projects including the CompCert verifying C
compiler, Verve OS Theorem prover, model checkers. You also need need proofs
for the communication protocol, the IP stack, secured device drivers, memory
protection units, control systems that can detect attacks, etc.

Just a proven kernel won't keep the helicopter flying, you've got to secure
everything. Additionally you need to reason about execution time and memory
constraints.

Slides:
[http://www.cyber.umd.edu/sites/default/files/documents/sympo...](http://www.cyber.umd.edu/sites/default/files/documents/symposium/fisher-
HACMS-MD.pdf)

Presentation from Kathleen Fisher, the researcher who's won the DARPA grant
for the program:

* [https://www.youtube.com/watch?v=YqRdbgRPYw8](https://www.youtube.com/watch?v=YqRdbgRPYw8)

~~~
mtgx
So can you create a general purpose OS with something like this, or is it only
useful for embedded stuff, like say voting machines?

~~~
tptacek
It is unlikely that anyone is going to create a general-purpose operating
system based directly on an L4 kernel. L4 is incredibly simple. The more
reasonable thing to do with L4 is to run another OS on top of it.

~~~
hga
I know of this effort: [http://genode.org/](http://genode.org/)

More specifically, I'd wonder about efforts to create not (necessarily) POSIX
based stuff on top of seL4 etc.

~~~
csirac2
NICTA/UNSW have apparently started working on a QubesOS port

[https://my.cse.unsw.edu.au/thesis/thesis_topic_details.php?I...](https://my.cse.unsw.edu.au/thesis/thesis_topic_details.php?ID=3289)

[http://sel4.systems/pipermail/devel/2015-March/000312.html](http://sel4.systems/pipermail/devel/2015-March/000312.html)

~~~
throwaway7767
Huh, I'm surprised I'm seeing this first in a HN comment.

I read qubes-devel with interest and have not noticed anything from these
guys, but it sounds like a great project.

I really hope it's something that turns into an actual maintained project
instead of dying after the paper is out like so many security-focused research
projects, but the lack of communication doesn't give me great hope.

~~~
nickpsecurity
That's because Joanna is against it and will aggressively defend their
platform choice. After our argument online [1], she posted this essay [2]
comparing QubesOS to other things. She censored my piece-by-piece counter,
too, lol. She did eventually do something with trusted path and mentioned
QubesOS could be ported to different platforms. So, there's some progress...
Honestly, it wasn't clear whether she really understood INFOSEC (esp TCB
concept) based on her replies so I avoid QubesOS.

[1] [http://pastebin.com/5fnh8g2S](http://pastebin.com/5fnh8g2S)

[2] [http://theinvisiblethings.blogspot.com/2012/09/how-is-
qubes-...](http://theinvisiblethings.blogspot.com/2012/09/how-is-qubes-os-
different-from.html)

~~~
hga
I remember one good argument she made, a reductionist one that if the firmware
on your Ethernet adapter can be hacked without recourse or relief from the OS
(she gave a specific example), reducing the Xen part of TCB was not too
relevant.

It's worth noting that the seL4 people haven't tried to formally verify it on
x86 (and there's no 64 bit port to date that I know of, outside of possibly
the lowRISC GSoC effort which I should check up on), only ARMv6 and v7 (which,
I'll grant, also has to do with academic efforts to verify ARM in general). If
you're that serious, seL4 serious, there's a good argument you should eschew
Intel and start with some of the less chaotic ARM systems (i.e. not so much
kitchen sink ones from the mobile world like the Broadcom chips the Raspberry
Pies use).

I take her as trying something rather different, the pragmatic approach of
getting the best security possible out of our existing infrastructure, hence
the use of x86, Xen, Fedora, etc., based in part on her experience when
figuratively putting on a black hat. She's discovered a lot of exploits,
hasn't she? (lowRISC also includes an effort with tags to make our existing
C/C++ infrastructure safer).

And without the prospect of a "secure" web browser aside from perhaps Servo
someday, maybe....

~~~
pakled_engineer
QubesOS would have saved that Bitpay executive $2mln who fell for an old
phishing trick [http://www.americanbanker.com/news/bank-
technology/bitcoin-p...](http://www.americanbanker.com/news/bank-
technology/bitcoin-payment-processor-bitpay-loses-1m-in-phishing-
hack-1076722-1.html)

Just logically separating administrative VMs with credentials from email VMs
would have been good enough to thwart this. We can always fork Qubes and play
around with whatever other VM templates such as OpenBSD, seL4 x86/genode port
or experimental encrypted overlay kernel.org kernels

~~~
nickpsecurity
The article states that he's just guessing at what happened leading up to the
fraudulent request. (If I'm reading right.) So, no way to know what would stop
the first part. The actual attack was a common one where a request comes in
_without strong authentication_ and an _authorized user carries it out_.
Neither QubesOS nor any other low-level architecture I mentioned would stop
that as it's an application-layer concern. There's a little irony in your
comment, though, given that one of the Nizza demonstrators in mid-2000's was
doing eCommerce by splitting the UI and security critical parts over a
microkernel. Did that for GPG email, too. So, even they recognized the problem
and demo'd a two-part solution. I sent that to Joanna in our exchange.

"We can always fork Qubes and play around with whatever other VM templates
such as OpenBSD, seL4 x86/genode port or experimental encrypted overlay
kernel.org kernels"

That's true. It's why I found the seL4 and QubesOS work interesting.
Additionally, as they showed up, I've suggested various projects to those
interested in improving QubesOS assurance. These included capability
extensions for Xen, the Xenon project, several projects that knock risk out of
Dom0, components like Nitpicker, and so on. To be clear, I don't see QubesOS
as worthless or all bad so much as redundant in some ways, weaker
technologically in others, and a vast usability improvement in yet others. Use
and improve it if you want for sure with definite benefits over a vanilla
Windows or Linux box. Just know the limitations of the security approach and
that efforts might be better spent elsewhere.

Here's a recent report on the 2005 Nizza architecture's design along with
other projects that built on it if you're curious what it was like. Notice how
they understood where the software risks were, systematically eliminated what
they could, and kept metrics on the TCB to back it up. On other end, I
couldn't even get Joanna to agree user-mode drivers were more robust despite a
decade plus evidence of this.

[https://os.inf.tu-
dresden.de/Studium/KMB/WS2014/11-Security-...](https://os.inf.tu-
dresden.de/Studium/KMB/WS2014/11-Security-Architectures.pdf)

------
doe88
Not sure about the _unhackable_ claims part but it seems at least to be an
interesting project. This is a formally verified L4 derived micro-kernel, its
code is open-source (GPL2, BSD).

Homepage: [https://sel4.systems/](https://sel4.systems/)

Github: [https://github.com/seL4/seL4](https://github.com/seL4/seL4)

Related course (already posted on HN i think but can't find its associated
thread):
[http://www.cse.unsw.edu.au/~cs9242/14/lectures/](http://www.cse.unsw.edu.au/~cs9242/14/lectures/)

~~~
amirmc
They also have [http://sel4.com](http://sel4.com) \-- why wouldn't they use
the .com as the canonical site instead of a more obscure .systems? (I say this
because sel4.systems is linked from within the original article).

Also, the link
[http://sel4.systems/FAQ/proof.pml](http://sel4.systems/FAQ/proof.pml) is a
404 (linked within the article where it says "Last year, Heiser’s team proved
mathematically that their kernel is unhackable."). I guess this is meant to
link to
[http://sel4.systems/Info/FAQ/proof.pml](http://sel4.systems/Info/FAQ/proof.pml)
(where the claims are far more measured).

~~~
sanxiyn
I don't think claims are more measured. It is more detailed, yes, but claims
are still extremely strong.

"Integrity means that data cannot be changed without permission, and
confidentiality means that data cannot be read without permission." seL4
claims both. I think "unhackable" is a good enough summary.

~~~
amirmc
I didn't mean to imply that the claims were not strong. Just that they're more
careful/specific (which is a good thing for this kind of work).

Also, saying a piece of software is "unhackable" is akin to saying a ship is
"unsinkable".

~~~
schoen
It seems like, in light of the mathematical proof, it may be reasonable to say
"does not contain exploitable software vulnerabilities".

Unfortunately, it's true that might not be enough to prevent attacks in some
settings. For example, see Govindavajhala and Appel's "Using Memory Errors to
Attack a Virtual Machine".

[https://www.cs.princeton.edu/~appel/papers/memerr.pdf](https://www.cs.princeton.edu/~appel/papers/memerr.pdf)

In this case, they show that even given correct software safety guarantees,
they can write a program which requires only one bit flip in any of a large
number of RAM locations in order to achieve privilege escalation or violate
the safety guarantees. They can then heat or irradiate the DRAM chips and make
such a bit flip likely to occur. Since they can't control which bit will flip,
it might sometimes crash the computer, but it's more likely to make their
attack succeed.

So, one thing to study with systems like this is whether hardware fault
injection can compromise the security guarantees in a way that would allow an
attack to succeed.

~~~
nickpsecurity
This is why you address system security holistically. There are countless
projects that sprang from the Aegis processor that address the fact that RAM
and devices aren't trustworthy. One had the start of an EAL7 argument for
security of software from all those attacks via the hardware mechanism without
modifying the processor's internal RTL. Another shows security of information
flow of a design down to the gates. Others are about just synthesizing correct
designs that arbitrary parties can produce for a fab and composing them into a
trustworthy system.

The problem, if not specific attack, has been known a long time. The Tandem
NonStop architecture assumed that its memory, I/O, and key components could
fail. So, they designed system to work correctly regardless plus linear
scaling of resources. My proposal was to integrate above technologies with
older, non-patented version of NonStop for high security and availability.

------
nabla9
Current cream of the crop:

IBM System z is EAL5 rated (Semiformally Designed and Tested)

Integrity-178B is EAL6 rated (Semiformally Verified Design and Tested). It's
used in aviation systems: Airbus A380, F-16, F-22, F-35 and B-2.

Currently the only EAL7+ rated (Formally Verified Design and Tested) devices
are data diodes. Maybe seL4 can be first OS to get this rating?

~~~
hackuser
I went to lookup EAL in Wikipedia and discovered something interesting: The
exact same information as above on the EAL page (with a little on the
Integrity OS page).

Either the info above is from Wikipedia, or perhaps the commenter above also
wrote those sections of the Wikipedia pages, or the commenter read something
else that was based on those Wikipedia pages. The web is an interesting place.

~~~
nickpsecurity
Use Cygnacom's breakdown as it has a nice summary of what each EAL means:

[https://web.archive.org/web/20130718103347/http://cygnacom.c...](https://web.archive.org/web/20130718103347/http://cygnacom.com/labs/cc_assurance_index/CCinHTML/PART3/PART36.HTM)

------
mschuster91
What is the most worrying aspect of proven-unhackable kernels is that
eventually these projects will be used to prevent people from modifying their
system.

Proven unjailbreakable phones are the wet dream of the mobile carrier industry
- finally no piracy anymore and no way for users to get rid of bloatware.

~~~
wingless
...until someone develops a hardware exploit and starts selling kits. Which is
already happening for many devices, by the way.

~~~
userbinator
That raises the barrier substantially, however. Also, you can bet that the
hardware will be secured too - just look at the technology available currently
for things like credit cards and payment systems (where I think the security
is somewhat more justified.)

------
sanxiyn
The primary paper to read is "Comprehensive formal verification of an OS
microkernel" (2014).

[http://dl.acm.org/citation.cfm?id=2560537](http://dl.acm.org/citation.cfm?id=2560537)

~~~
tempVariable
That is $15 for non-members. First Google result for "Comprehensive formal
verification of an OS microkernel" is a PDF link on ssrg.nicta.com.au. Good
enough for me.

------
Klasiaster
But still software running on top of it might not be secure and proven. And as
well the hardware is another area for attacks and failures.

------
nickpsecurity
The slides "achille" posted are a must-read for people understanding what
they're _actually_ doing rather than nonsense about "unhackable." For
instance, the seL4 team is clear on risk areas of their proofs:

[http://sel4.net/Info/FAQ/proof.pml](http://sel4.net/Info/FAQ/proof.pml)

What's really going here is significant work in high-assurance design and
security of two systems. They're using best modern tools to help prove or even
synthesize about every layer and component in those systems. They're also
developing and improving tools to argue that they integrate in a way that's
secure for the whole system. In the past, similar, high-assurance methods led
to the most robust and secure software ever created per the experience
reports. This work expands on such techniques while attempting to make the
tools, methods, and software produced reusable in other projects. In short,
they're applying The Right Thing philosophy to as much as possible.

Galois's Ivory and Tower languages can be found here:

[http://ivorylang.org/](http://ivorylang.org/)

seL4 is found here:

[https://sel4.systems/](https://sel4.systems/)

CertiKOS, VeriML, and other FLINT work here:

[http://flint.cs.yale.edu/certikos/](http://flint.cs.yale.edu/certikos/)

Termite Driver Synthesis here:

[https://github.com/termite2/Termite](https://github.com/termite2/Termite)

CompCert here:

[http://compcert.inria.fr/](http://compcert.inria.fr/)

A how-to on certified programming that's more accessible for newcomers:

[http://adam.chlipala.net/cpdt/](http://adam.chlipala.net/cpdt/)

------
hackuser
SEL4 previously discussed at HN:

[https://news.ycombinator.com/item?id=7938149](https://news.ycombinator.com/item?id=7938149)

------
ifdefdebug
"unhackable"? After reading "How to Write Unmaintainable Code" [1] earlier, I
expected to find some kernel code implementing all those valuable principles,
not an article about a kernel proven secure against any attack :)

[1]
[https://news.ycombinator.com/item?id=10237636](https://news.ycombinator.com/item?id=10237636)

------
pvdebbe
From the title I readily thought about the Windows kernel and how it can't be
tweaked and recompiled and improved like Linux. Now I know better...

------
dvh
How practical is this, does it have sata? usb? network? bash? some compiler?

~~~
sanxiyn
It is practical enough to autopilot UAV.

------
nerdy
It can be just like that "Unsinkable" ship!

------
thoastbrot
"a prank"? Crashing a car is a prank?

~~~
mrweasel
Honestly, I still have issues with that story. Either someone shouldn't be
allowed to put computers in cars or someone is lying.

I almost refuse to believe it's possible to jump from the entertainment system
to the computers controlling the car. Designing a car where those two systems
are connected in any way other than maybe power and one-way signalling from
the car to the entertainment system would be reckless to an almost criminal
extend. Honestly, what engineer would suggest something like that?

~~~
titanomachy
The guys who did the hack chose the Jeep exactly for this reason -- an
unregulated data pipe between the entertainment computer and the critical-
systems computer. They analysed hundreds of cars and chose the worst-designed
one they could find.

------
9fb29947
There is no such thing as an unhackable system.

~~~
rhaps0dy
Not yet. But there may be in the future. Many things proved impossible have
shown to be possible in the past.

~~~
Beltiras
Gödel's Incompleteness Theorem might be abstractable to this. Any system so
inaccessible as to be unhackable might be functionally impaired beyond
usefulness.

~~~
jdefr89
Godel's theorem is great for claims like this. Have they proved that the
"theorem proving" software has no mistakes?

~~~
hga
There's this: [http://proof-technologies.com/holzero/index.html](http://proof-
technologies.com/holzero/index.html) and I see some other things that I
interpret as moving in that direction.

