News for hackers. Stuff that matters.
Re:Sel4: We’re going open source by mantraxC on Tuesday June 24, 2014 @02:41PM (#7939589)
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.
Re:Sel4: We’re going open source by TacticalCoder on Tuesday June 24, 2014 @02:46PM (#7939632)
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.

Re:Sel4: We’re going open source by Avshalom on Tuesday June 24, 2014 @02:52PM (#7939691)
On that note: what even is a correct translation of C when it has so many undefined behaviors in it's spec.
Re:Sel4: We’re going open source by cc_ on Tuesday June 24, 2014 @10:16PM (#7941904)
They use a formally-specified subset of C described in Harvey Tuch's PhD thesis: http://www.ssrg.nicta.com.au/publications/papers/Tuch:phd.pd...
Re:Sel4: We’re going open source by wmf on Tuesday June 24, 2014 @03:06PM (#7939809)
What if the code doesn't rely on undefined behavior?
Re:Sel4: We’re going open source by regehr on Tuesday June 24, 2014 @04:02PM (#7940197)
Absence of undefined behavior in the C implementation is of course one of the things covered by the seL4 proof.