
L4Linux – Linux running on the L4 microkernel - phoe-krk
http://l4linux.org/overview.shtml
======
Firerouge
This seems like an important part that's buried

> Compared to monolithic Linux, there is a small performance tradeoff because
> of the µ-kernel architecture. However, the initial L4Linux has been somewhat
> optimized, and on L4/x86 it has a very acceptable slowdown of less than 4 %
> for any relevant load.

If it provided any additional security guarantees in trade for that 4%, I
imagine it'll become a popular way of running Linux

~~~
monocasa
It doesn't really provide extra security for processes managed by the Linux
kernel, but it allows you to co locate Linux and some other code. I could see
a model where you have an untrusted Linux land running next to some unikernel
like rtos-esque components that are protected from the Linux side. The sel4
guys had a CTF where they ran hard realtime heleicopter software next to a
Linux kernel on the same system, and gave you a root shell to the Linux side
to start off with.

That being said, last time I checked even sel4 wasn't really hardened against
Spectre attacks.

~~~
wahern
By exposing kernel memory Spectre diminishes the effectiveness of mitigations
like kernel ASLR as well as makes it easier more generally to exploit kernel
vulnerabilities. That's significant in the case of Linux as there's no
shortage of Linux kernel bugs, not now nor for the foreseeable future. Even
well written, bug free user space applications can't protect themselves from
the kernel, AMD's and Intel's best efforts with SEV and SGX, respectively,
notwithstanding.

By contrast seL4 is effectively bug free. (Literally bug free for the most the
part, but AFAIU some gritty details like TLB management remain outside the
scope of the formal verification.) That means you can build a reliable
security model for your own application. The guarantees that model can make
about confidentiality may be weaker because of Spectre, but you're still in an
infinitely better position than on Linux, Windows, or most anywhere else.

seL4 is arguably even better than ARM's TrustZone. With TrustZone you're still
stuck having to ensure you correctly manage transitions into and out of
protected mode. Bugs in such code constitute a good chunk of kernel
vulnerabilities more generally, so it's clearly not trivial. Doing this
correctly is basically what seL4 is all about. Then consider the fact that
people are trying to push so many tasks into the TrustZone (or secure enclaves
in general) that it's common to run an OS in the TrustZone. People would do
much better to run seL4 inside the enclaves than bug ridden TEE environments.
And unless the enclave is a discrete processor rather than a protected mode as
with TrustZone, you may as well just run seL4 as the only OS (or at least the
host OS).

Interestingly, Apple's T1 and T2 chips run an L4-based microkernel. AFAIU it's
something of a cousin to seL4 but predates it. If seL4 was as mature then as
it is now perhaps Apple would have started with seL4.

~~~
j16sdiz
seL4 is bug free in theory, not in paratice. It have been proved to follow the
spec, but the spec can have error. Missing workaround for hardware bug can
bite too.

"Beware of bugs in the above code; I have only proved it correct, not tried
it." \-- Donald Knuth on the van Emde Boas construction of priority deques
(1977)

~~~
sanxiyn
After proving the full functional correctness (that machine code implements
spec), they did additional security proofs against the spec, including
confidentiality and integrity. If you accept their TCB(no hardware bugs etc),
the entire proof is incredibly strong.

------
andrewflnr
Can you use this setup to use Linux's device drivers for SeL4? Given the
paranoia level involved, I imagine you'd run a stripped down Linux kernel per
driver, with all device commands proxied through L4. Your Linux or whatever
other userland would see virtual devices through L4 as well. Possible?
Hopelessly inefficient? Or does L4's capability pipelining save the day?

~~~
jakeogh
there's this for NetBSD's drivers: [https://research.csiro.au/tsblog/using-
rump-kernels-to-run-u...](https://research.csiro.au/tsblog/using-rump-kernels-
to-run-unmodified-netbsd-drivers-on-sel4/)

------
Koshkin
The idea seems to be to use paravirtualized Linux as a “time-sharing
component” of a system that otherwise provides real-time capabilities...

~~~
nixpulvis
This might be interesting for my long abandoned drone project...

Undoubtably still want propellor controls + stabalization on dedicated
hardware, but everything else.

------
bluejekyll
I’ll ask a naive question. Could L4 in this context be used as a means to
migrate Linux to a micro-kernel architecture?

What I mean by this is, run the Linux kernel on L4, then in Linux remove
different components by calling out to a library (like virtio does) which
actually puts a message onto the L4 bus and has that service handle the
request. For example, running an FS as an L4 service.

Not sure if this is possible, but it seems like it should be.

~~~
Animats
Unfortunately, no.

L4, unlike QNX, is so minimal that you have to put another OS on top of it to
do much. L4-Linux has been around almost since L4. There's not much point in
it unless you have something else running on the same hardware which needs to
be isolated. If all you have is one Linux instance, you haven't gained
anything.

Putting some container system on top of L4 might be useful.

------
__bjoernd
Might be worth noting that this link itself points to the university project.
Most of the main developers moved on and founded a company that's providing
microkernel technology commercially:
[https://www.kernkonzept.com](https://www.kernkonzept.com)

Disclaimer: not working for them, but used to work on the university project.

------
elcritch
Anyone used this before? If it supports arm it could be a handy system.

~~~
yjftsjthsd-h
Can I ask what you'll find it useful for? The technology is neat, I'm just
struggling to think of something that would benefit from it.

~~~
elcritch
Primarily for soft (or hard) real time operations. Even kernel modules running
in a RT-Linux have a difficult time responding consistently to an IRQ at
sub-10 uS latency. Of course, the larger SoC capable of running Linux can have
hardware latencies due to shared data buses, etc. but still having a RTOS
layer “underneath” Linux would be a good way to ensure more consistent
responses.

------
vicnov
Okay, can someone explain why is this a thing? It is a genuine question.

I am not very familiar with OS designs and skimming through the landing page
didn't help.

Is it essentially a Linux kernel that runs within an existing instance of
Linux? Why is it important/useful?

Thanks.

~~~
butterisgood
Microkernels and hypervisors are very closely related in the view of some.
Paravirtualization, like L4 Linux, is when the guest is aware of being hosted
and, at one time - maybe still, could outperform guest OSes on fully
virtualized hardware. I'm not sure if that's all still true since Intel and
AMD implemented VTX.

If you want to see a neat demo of this stuff - check out the DROPs demo or
TUD:OS [http://demo.tudos.org/](http://demo.tudos.org/).

Screenshots of a whole bunch of linuxes (linii?) running at once:
[http://demo.tudos.org/l4lx_screenshot.png](http://demo.tudos.org/l4lx_screenshot.png)

I think this is from 2003...

~~~
Koshkin
> linii?

Linuces.

------
newnewpdro
Does anyone here have experience running this on desktop/laptop for general
use? Does GPU acceleration in opengl/vulkan work? Intel integrated HD audio?

Could you speak to how well everything works?

------
butterisgood
This is at least a decade old... If it was going to become a popular way of
running Linux, as some have suggested, what's stopped it so far?

~~~
__bjoernd
Virtual machines running Linux have actually become quite popular in the past
decade. ;)

It's not the research project's fault that a different mechanism is used in
the public cloud.

As for microkernels, they are actually used, but not in mainstream server
systems.

------
MR4D
Might be a nice alternative to Docker.

