Information on implementing L4

[Gernot Heiser]

On 15 Sep 2018, at 11:22, John <john.r.moser at gmail.com> wrote:
> 
> On Fri, Sep 14, 2018 at 9:05 PM Andrew Warkentin <andreww591 at gmail.com <mailto:andreww591 at gmail.com>> wrote:
> On 9/14/18, Paul Boddie <paul at boddie.org.uk <mailto:paul at boddie.org.uk>> wrote:
> 
> On 9/14/18, John <john.r.moser at gmail.com <mailto: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).
> 
> It doesn't have to run at Ring-0 you know.  Think about if you loaded a malicious network card driver into L4.

You. don’t. ever. Running all drivers as encapsulated usermode processes is one of the core features of L4.

Eg seL4 has exactly two drivers in the kernel: a timer driver (for preemption interrupts) and an interrupt controller. And IOMMU (if you consider that a device, I consider it part of memory management). There’s also a serial driver for console output, but only when the kernel is compiled for debugging. Certainly no NIC drivers, that would completely undermine the fundamental microkernel design.

Gernot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20180915/745fe128/attachment.htm>