
10 Years SeL4: Still the Best, Still Getting Better - ingve
https://microkerneldude.wordpress.com/2019/08/06/10-years-sel4-still-the-best-still-getting-better/
======
loudmax
Will it be possible to run a web browser on an SeL4 kernel some day, or is
that completely beside the point?

Obviously, formally verifying a modern web browser with a javascript engine
and everything is a whole other undertaking, so I'll leave that aside. But the
notion of using a very secure kernel as the base OS is appealing. Even if a
hostile site broke out of the web browser, SeL4 should keep it sandboxed.
Presumably, SeL4 could enforce isolation between different browser tabs. Is
this something we can look forward to in the future, or are the performance
expectations of modern javascript heavy web sites out of line with what SeL4
is likely to deliver?

Anyway, there are plenty of other applications beside the web, so glad to see
that SeL4 is being used in real world deployments.

~~~
wmf
Technically, a capability-based desktop OS makes perfect sense. In practice,
the microkernel people have been polishing their kernels and about to start on
userspace next year... for 30 years.

(One exception to this is QNX which was killed off by weird business
decisions.)

~~~
ac29
> QNX which was killed off

Are you sure? The latest version is only ~2 years old, and they still seem to
be hiring:
[https://bb.wd3.myworkdayjobs.com/QNX](https://bb.wd3.myworkdayjobs.com/QNX)

~~~
wmf
It looks like the desktop version of QNX was killed off in 2014 although they
stopped promoting it much earlier.

------
mmrezaie
This is a great view on history of seL4. Is there a list of use cases where
seL4 is being used outside academia?

Also, I would like to know why Google didn't go for seL4 and instead created
Fochsia?

I wanted to mention that we wanted to see if we can use L4 for isolating our
network filter from Linux kernel (trustability) but instead we opted for
bitvisor (much simpler code base but not verified).

~~~
im_down_w_otp
We're using seL4 as the basis for one of our products which is focused on
characterizing components, systems, and their failure modes. Mostly targeting
critical "Cyber-Phyiscal Systems" and "Software-Intensive Systems of Systems".

We have a little operating system, or enough of one to facilitate building the
rest of our product atop of it, that goes along with seL4. We'd planned to
open source parts of it fairly soon, but prioritizing hiring a few more folks
(BD, PM, Eng.) has put that effort on-hold temporarily.

Building things with seL4 is easy to do wrong, despite being given a variety
of very low-level verified primitives to work with. You still need to put it
all together _just right_. CAmkES is supposed to make this easier, but our
experience with it wasn't very good, so we took the hard road and created a
Rust-based application framework to go over the top of everything.

~~~
mmrezaie
> seL4 is easy to do wrong

This was our main stopper. seL4 would benefit greatly to teach how everything
can be fit together, and where everything can be expected to go.

~~~
im_down_w_otp
We overcame this with a significant amount of Rust-i-ness and effort in
understanding the guts of the kernel and how it implements its assurances.

Basically by providing setup, resource management, and communication
abstractions that you just can't get wrong because doing something dumb that
would be entirely nuts and/or would result in difficult to deal with run-time
errors (as the kernel enforces some of its guarantees) ends up being rejected
by the compiler ahead of time.

------
elcritch
Are there any resources for running SeL4 on a raspberry pi or other arm SBC'S?
The article mentions hypervisor support, which makes me think it'd be a
possible way to run Linux on top of a secure RTOS. Working in the embedded
world and I ponder what could be possible with a high security hypervisor.

~~~
im_down_w_otp
seL4 isn't an RTOS, FWIW.

There is hypervisor support, sort of. Insofar as there's enough there to build
your own hypervisor (we ended up needing to do something like this), and
there's a sample VMM for a very specific host and guest target combination
available that's created via CAmkES.

Making an seL4-based hypervisor truly cross-architecture capable as well as
generalizable for different host and guest target configurations is a non-
trivial, painstaking, arduous task. In fact making anything on seL4 truly
cross-platform isn't easy. The kernel doesn't provide much in the way of
unifying abstractions over the architecture differences. The different
architecture details are mostly thrust onto you to figure out what kind of
abstractions _you_ want to make.

The MCS (mixed criticality support) stuff in seL4 getting mainlined should
make it theoretically possible to invent/create a hypervisor that enables you
to run MCU oriented RTOSes & applications in an isolated context atop non-HRT
hardware. Data61 has mentioned that they're going to take a whack at making
some part of an AUTOSAR stack that runs in a context like this, but I have no
idea how far along that is. Separately, we're looking at leveraging the same
underlying capability for a variety of different adjacent purposes.

That said, there are a variety of supported platforms you can already build
seL4 for:
[https://docs.sel4.systems/Hardware/](https://docs.sel4.systems/Hardware/),
our experience has been that some work better than others. It's possible to
run in QEMU as well to get started.

~~~
snvzz
How is seL4 not a hard RTOS?

It even has proof of worst case time (WCET), which to my knowledge no other
non-trivial RTOS does have.

I'm very confused now.

~~~
msjyoo
seL4 at the moment doesn't have kernel interrupts. The kernel relies on run-
to-completion and "incremental consistency" partly because IPC in seL4 is
already short so the time window for a kernel interrupt to be needed is also
correspondingly small, and because it makes proofs easier. Of course, this
means there's possibilities of long tail latency for interrupts to be
delivered to userspace if the kernel needs to run a long operation.

~~~
repolfx
My understanding of seL4 is that the kernel never really needs to run a long
operation because it does so very little. For instance filesystems would be a
usermode process, along with nearly all drivers. Isn't that why the MCS stuff
works - the kernel may not be able to interrupt itself but that doesn't matter
because it can interrupt userspace, which is where 99% of traditional kernel
code ends up?

~~~
msjyoo
That's not quite true. It's not solely because seL4 does little. seL4
maintains low interrupt latency through "preemption points" \- basically
points where the kernel can and can only context-switch while maintaining
global consistency.

Keeping in mind I'm not an expert on this, I dug up these papers when I was
vaguely looking, they may be useful to you:

"Improving Interrupt Response Time in a Verifiable Protected Microkernel"
[https://ts.data61.csiro.au/publications/nicta_full_text/5391...](https://ts.data61.csiro.au/publications/nicta_full_text/5391.pdf)

"To Preempt or Not To Preempt, That Is the Question"
[http://ts.csiro.au/publications/nicta_full_text/5859.pdf](http://ts.csiro.au/publications/nicta_full_text/5859.pdf)

~~~
repolfx
Thanks, that's super helpful.

~~~
snvzz
AIUI there's only one such preemption point, in some resume-able operation to
do with cleanup. Every other operation is short enough.

Thus interrupt latency is guaranteed to be very low, even if the interrupt
happens while the microkernel is running.

It is my intuition that the "it's not a RTOS" has to come from something else,
like some non-implemented API that's expected in an RTOS or the like. The
required services might actually be implementable as non-privileged tasks.

~~~
repolfx
Maybe it's just slight conservatism. If all existing RTOS' have pre-emptible
kernels and yours doesn't, perhaps you'd rather let the market decide you've
built an RTOS rather than stating you have and risking an argument over
terminology.

