Information on implementing L4

[John]

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>
> wrote:
>
>> 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>
>> wrote:
>>
>>> 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,
>>> 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.
>>
>>
> 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.

https://imgur.com/9pPKZ9c

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.


> Gernot
>> _______________________________________________
>> l4-hackers mailing list
>> l4-hackers at os.inf.tu-dresden.de
>> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20180914/0afaa329/attachment.htm>