Information on implementing L4
john.r.moser at gmail.com
Sat Sep 15 04:15:01 CEST 2018
On Fri, Sep 14, 2018 at 10:00 PM John <john.r.moser at gmail.com> wrote:
> On Fri, Sep 14, 2018 at 9:38 PM Gernot Heiser <gernot at cse.unsw.edu.au>
>> 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>
>>> On 9/14/18, Paul Boddie <paul at boddie.org.uk> wrote:
>>> On 9/14/18, John <john.r.moser at gmail.com> wrote:
>>> > The Kernel-CLR runtime is basically a fancy privileged service loader,
>>> > doesn't run userspace applications. Basically, if you can load a
>>> > 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
>> 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.
> The fact that you separated the drivers into different process contexts
> doesn't mean they're now some userland program. These are privileged parts
> of the operating system. You're thinking about being able to directly
> access and write to parts of the kernel; I'm thinking about being able to
> control security contexts, inject malicious code into applications as they
> load from disk, and otherwise use the service's context as an underlying
> operating system component to do bad things.
> Unless all of your drivers load with the boot loader and nothing can be
> loaded when someone plugs in a new USB device, you have some sort of driver
> loader to load new services into L4. Those drivers run with their own VMA,
> in Ring-3, sure; and they could be drivers for things like disk control and
> file systems, for security contexts, and the lot, thus giving a way to
> replace parts of the underlying OS with malicious code.
> Your fences are only around memory areas and privileged instruction
> calls. These are still hardware drivers and software schedulers supporting
> userspace applications.
This might help clear things up.
In that diagram, the proposed malicious NIC driver would be somewhere in
the hardware layer. It might have its own VMA and run in Ring-3, but it's
still a driver loaded into the OS. That's not a monolithic kernel unless
Minix3 is a monolithic kernel.
>> l4-hackers mailing list
>> l4-hackers at os.inf.tu-dresden.de
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the l4-hackers