Information on implementing L4

[Andrew Warkentin]

On 9/14/18, Paul Boddie <paul at boddie.org.uk> wrote:

>
> But one of the lessons from the phenomenon of Java is that people don't like
>
> to be told to rewrite all their stuff in a particular language, and although
>
> you can try and make the runtime language-neutral, some languages end up
> being
> more equal than others.
>

Yeah, that would be the biggest thing that limits the appeal of
language-based OSes.

>
> It is interesting to consider Nemesis, which evolved into Xen, in this
> regard:
>
> https://en.wikipedia.org/wiki/Nemesis_(operating_system)
>
> One of the goals was to support POSIX applications, and it was apparently a
>
> usable system in its day, maybe still is.
>

I knew Nemesis and Xen were from the same group at Cambridge but I
didn't know that there was much of a connection other than both being
somewhat exokernel-ish.

>
> It is also interesting to see the UX/RT label given the heritage of Unix
> systems:
>
> https://en.wikipedia.org/wiki/Multi-Environment_Real-Time
>

I'm well aware of MERT/Unix-RTR, although UX/RT won't really be
similar beyond being a microkernel-based Unix-like RTOS. It will have
a general structure like that of QNX and a VFS model similar to that
of Plan 9 (the name is kind of an indirect reference to QNX's name
originally being derived from "Quick uNiX").

>
> In the L4 microkernel-related materials I have seen, nobody seems to mention
>
> this work or even the foundational influences on it. Indeed, one set of
> slides
> calls the Mach microkernel "The mother of all microkernels", later to
> discuss
> IBM Workplace OS and to note that "OS personalities did not work".
> Presumably
> such remarks are made in that specific context given that DMERT apparently
> supported multiple personalities (Unix-RTR and RSX-11).
>

Yeah, a lot of people seem to think that Mach was the first
microkernel, but nothing could be further from the truth. QNX predates
Mach by several years, and it has always been somewhat similar to
L3/L4. I think Mach was the single worst thing to happen to
microkernels. It completely destroyed the reputation of microkernels
with its slow, heavyweight IPC. I think it may have hurt the
reputation of OS research in general as well, creating more of a
divide between research and mainstream OSes. I wonder if microkernels
would be widespread on an alternate timeline where QNX had somehow had
significant influence on OS research as soon as it came out (Mach may
not have been written, or may have been QNX-like instead).

Another thing that has hurt performance on microkernel OSes that I
haven't heard discussed is component-level versus subsystem-level
modularization. It seems like most microkernel OSes go for
component-level modularization everywhere (e.g. separate processes for
disk device driver and disk filesystem, or process manager and VFS).
The problem with component-level modularization is that it multiplies
the number of context switches for a system call in many cases, and
often provides little benefit to security or stability (e.g. both a
disk device driver and disk filesystem are both dealing with the exact
same data, just on different levels, and compromising either would
basically be equivalent; similarly, an OS with restartable servers
should allow recovery from either a disk device driver or disk
filesystem crash, so splitting them up doesn't provide any benefit
there). UX/RT will take a similar approach to QNX and will use
subsystem-level modularization in many places (e.g. there will be a
disk server incorporating both device drivers and filesystems, with
support for multiple instances; similarly, the memory manager, VFS,
and certain in-memory special filesystems will all be part of a single
root server).

>
> Who is to say that an incompatible system does not have "practical
> real-world
> usage", though? I agree that compatibility would be helpful, and there are
> plenty of systems that exist only through the perseverence of their
> creators,
> only to fade away at some point, partly due to a lack of interest and
> difficulties integrating mainstream software.
>

Yes, an incompatible OS may be able to achieve success in some niches,
but even that will be made more difficult by the incompatibility.

>
> Personally, I am also interested in what it would take to develop a vaguely
>
> standard multiserver system, albeit leveraging L4 technologies. A while
> back,
> people tried to get the Hurd working on L4 (Pistachio, I think), and I think
>
> there is potential to get something like that going on Fiasco.OC,
> particularly
> since the lack of capability support was supposedly the reason why the
> Hurd-L4
> work was abandoned.
>

I've never really been a fan of Hurd. It gets its VFS model backwards
by requiring you to bind servers to disk files. It causes major
problems with determining the context that passive translators should
be started in, and it also requires the disk filesystem to support
storing the translator as file metadata.

UX/RT will use pure in-memory mounts like QNX and Plan 9, and the
contexts in which demand-started servers are run will be explicitly
specified by the init system configuration, rather than inheriting
them from another server (no need for elaborate process persistence
schemes to resolve the context problem like have been discussed for
Hurd).

On 9/14/18, John <john.r.moser at gmail.com> wrote:
>
> The Kernel-CLR runtime is basically a fancy privileged service loader, and
> doesn't run userspace applications.  Basically, if you can load a driver,
> you can get Kernel-CLR to process arbitrary input.
>
Then you effectively have a monolithic kernel, not a microkernel, if
you have a kernel module loader and drivers run in the kernel's
context rather than as normal processes. The whole point of a
microkernel is to make an OS that's extensible through normal
processes. A kernel module loader greatly increases the attack
surface, even if you are using language features to protect kernel
modules from one another (as a few people here have said,
hardware-based protection is generally more robust than language-based
protection).

>
> I've long considered the prospect of reverse paravirtualization, whereby
> you put a paravirtualizing driver inside an HVM OS and pass the OS direct
> IO mapping to a hardware device.  The PV driver then lets the hypervisor
> send it requests, and it arbitrates with the local operating system.  In
> other words:  the hypervisor is paravirtualized on the guest OS (reverse
> paravirtualization).  This would enable using Linux as a mega-driver, while
> L4Mx/Linux running a Linux kernel paravirtualized could do the opposite.
>
This is a little bit like what I was planning to do on UX/RT, although
I was planning to use the LKL project <https://github.com/lkl/linux>,
which turns the Linux kernel into a library (UX/RT will have good
support for virtualization, but it won't really focus on internal
full-system virtualization, and will focus on containers/overlays more
as far as built-in virtualization goes; it will probably also
eventually include a separate Type 1 VMM that will mostly be intended
for desktops and servers rather than embedded systems).