HackerTube.dev

seL4 Is Free – What Does This Mean For You?

Linux.conf.au 2015 -- Auckland, New Zealand · 9.8K views · 2015-01-16 · 49:45

Open on YouTube ↗

If playback is restricted in your region, try opening the original video. Use Mark watched to add it to your marked videos.

Overview

Gernot Heiser presents seL4, a microkernel with a mathematical proof connecting security properties to the binary code, and explains what its open-sourcing means for users. It covers its roles as a microkernel, separation kernel and hypervisor.

On Hacker News

Cited to explain what formal verification of seL4 guarantees, such as ruling out whole classes of bugs like buffer overflows.

Recommended by 1 HN people across 1 months · HN mentions 2015–2019

Topics

Operating systems & kernelsLogic & formal methodsSecurity & hacking
Search by tags
sel4microkernelformal verificationsecuritylinux.conf.au

What people said

rodgerd · 2019-08 · Recommendation

> This is a great view on history of seL4. Is there a list of use cases where seL4 is being used outside academia? "Can you build actual systems with it?" [VIDEO] The whole talk is well worth a watch.

Read the original HN comment ↗
tonyhb · 2015-03 · Reference

Spent a while on the weekend reading about the seL4 kernel, which uses capability based security and has end to end mathematical proofs of correctness on the compiler and underlying kernel. Its predecessors are used in Apple's A7 and Qualcomm's chips. Watching [VIDEO] and it says that it's mathematically impossible for seL4 to suffer from things such as buffer overflows. I'm faaaaaar out of my field here... but this sounds as like a far better improvement in security compared to running things in a chroot. Apart from it being really new (there's just a kernel with a C compiler), would this be a good route to head down for improving security? Why aren't we writing a linux port on this? Kernel info here: [LINK]

Read the original HN comment ↗
contingencies · 2015-01 · Reference

[VIDEO] The implementation is correct against this abstract specification ... so bug-free, etc. The implications, there's many of them, but just a few obvious ones: it's not possible for this kernel to have a buffer overflow; it cannot - it provably does not use uninitialized variables or dereference null pointers, there's no stack smashing, you can't have code injection, there's no return oriented programming. Any of that stuff is just not possible - provably. So that's nice!

Read the original HN comment ↗

Sources

Video by Linux.conf.au 2015 -- Auckland, New Zealand, played through YouTube.

Data and selection notes

HN summaries and labels may contain AI errors. HN dates refer to discussions, not video publication.

HN Library: HackerTube export (2026-10-31) and open-index/hacker-news. Upstream summaries and classifications may contain AI errors.

Views, duration and playback status refresh separately from the published catalog. When an update fails, existing data remains visible.

Selection checks
  • SaaS & AI candidates: Topic keywords do not match
  • Editor-approved picks: Editorial review is required

Rule matches identify candidates. They do not guarantee video quality or financial results.

About the library and its sources