seL4 Verified Microkernel Now Open Source
Back in 2009, OKLabs/NICTA announced the first formally verified microkernel, seL4 (a member of the L4 family). Alas, it was proprietary software. Today, that's no longer the case: seL4 has been released under the GPLv2 (only, no "or later versions clause" unfortunately). An anonymous reader writes OSnews is reporting that the formally verified sel4 microkernel is now open source: "General Dynamics C4 Systems and NICTA are pleased to announce the open sourcing of seL4, the world's first operating-system kernel with an end-to-end proof of implementation correctness and security enforcement. It is still the world's most highly assured OS."
Source is over at Github. It supports ARM and x86 (including the popular Beaglebone ARM board). If you have an x86 with the VT-x and Extended Page Table extensions you can even run Linux atop seL4 (and the seL4 website is served by Linux on seL4).
You mean, fortunately. Now, it's more likely to actually be used.
sig: sauer
http://sel4.systems/FAQ/
Is it really that hard to give more background information?
What's being released?
It includes all of the kernel's source code, all the proofs, plus other code and proofs useful for building highly trustworthy systems. All is under standard open-source licensing terms — either GPL version 2, or the 2-clause BSD licence.
Directly from the website. Not bothered enough to see what bits are BSD 2 Clause though.
Don't tell the HURD people -- they'll change which microkernel they're building around, again.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
Who else thinks that it's only a matter of time before the first vulnerability is found?
A fool and his hard drive are soon parted.
It may have been proven correct, but lets wait and see until after it's actually been used if it really is.
(Knuth said (paraphrased): be aware of bugs in the above code. I have only proved it to be correct; I have not tried it.)
I feel an explaination may help. This project is based on a formal specification (in Isabelle/HOL) about what should be true about the microkernel. This specification rules out things like buffer overflows, null pointer dereferences and other properties by recasting these ideas in terms of higher order logic and uses automatic theorem proving tools to verify the proofs and that implementations match the specification.
There's even a binary verified version for ARM, so you don't even have to trust that your compiler works (but, there is progress in verified compilers, so hopefully an x86_64 version is on the way). The value in this is in using the tool chain and creating new, formally specified abstractions and implementing them in an verified manner to implement more secure, robust programs on top of this kernel. Of course, the microkernel makes assumptions about the hardware, boot loader, but formal verification is used more often in hardware, and you have to trust something at some point.
This opens a whole set of possibilities to the community as a whole. As a random example, you could formalize the Arduino language (or a kernel for that language) and create a verified version of that system that runs on this microkernel. This would be a big effort, but you could do it.
Overall, this is a positive step in lower the costs of verified co-designed systems and I hope it attracts more interest in software formal verification.
Yes, it does mean that any code including v3 code can only be legally licensed as v3 - but there's nothing stopping you from later extracting the offending code and reverting to v2+. You don't magically change the 2+ license under which you gained rights to the other code, you just only have the option of redistributing it under v3 so long as any v3-only code is included. So long as you make sure all contributions made in the interim are made under v2+ you don't have a problem (i.e. v3-only licensing can only spread if you let it).
--- Most topics have many sides worth arguing, allow me to take one opposite you.
While proved software is much better than unproved software, this is not the end of security holes: The proof assumes hardware and compiler behave as specified, which lets a lot of attack surface.
At least it raises the bar much higher.
True, theoretically once you know about it, you should be untangle any GPL3 code and any contributions on top of that GPL3, and any other code that borrowed from the GPL3 code. As an example of what I'm thinking of, suppose you have something modular like WordPress or Apache. Someone contributes an authentication module that includes gpl3 code. Because it includes GPL3 code, the whole module is gpl3. Someone else writes a different type of authentication module and rather than writing boring parts from scratch, they start by making a copy of the existing authentication module and replacing the "guts", the actual authentication function, with some other type. That second authentication module would be a derivative work of the first, and therefore gpl3. The project maintainers have no way of knowing how the author went about writing it, though, so they don't know if it's gpl3 or not.
My primary 8-5 job is maintaining and enhancing a gpl3 project called Moodle. I appreciate what the licence APPEARS to say, but I'm always nervous about what it DOES say. I'm careful to only contribute or distribute under my personal name, never hosting a copy of the source on my employer's servers. When I get an email at work asking for a copy of a module I wrote, or some help with something, I reply from my personal email address in order to protect my employers IP by avoiding any indication that the organization is distributing. Even with that, I also have to watch the entire project for anything that might infringe on my personally held UP because if someone puts infringing code on the project github I'll arguably lose my rights.
whats the difference between tivoized code and non-tivoized code
Primarily, that the (majority) of users of said code are unable to effectively exercise the rights the GPL was intended to confer upon them.
Specifically, the right to change the code. That they can copy the code to some other deivces, change it, and run it there, but not be allowed to on the original device was not the intent of the GPL, or its author.
Surely a formally-proven OS doesn't want a traditional open-source license, because if you let people tinker, what you will end up with is forking... into unproven versions. And suddenly, the world's first formally-proven microkernel is just a plain old microkernel again.
OK, so maybe tinkering is alright as a personal hobby, but it risks the ecosystem.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
A trap? Not really. From the developer's point of view, they'll still be able to get access to any changes to code on their terms, even if it is "tivoised". They can incorporate them into their code base without worrying too much about which hardware devices will or won't work - Somebody Else's Problem. They're interested in the code, not in "right to do whatever you want with your devices."
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
nice troll, too bad nobody is biting :( Slashdot has really gone down hill.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.