On Fri, Sep 14, 2018 at 10:00 PM John <[email protected]> wrote:
> > > On Fri, Sep 14, 2018 at 9:38 PM Gernot Heiser <[email protected]> > wrote: > >> On 15 Sep 2018, at 11:22, John <[email protected]> wrote: >> >> >> On Fri, Sep 14, 2018 at 9:05 PM Andrew Warkentin <[email protected]> >> wrote: >> >>> On 9/14/18, Paul Boddie <[email protected]> wrote: >>> >>> On 9/14/18, John <[email protected]> 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 >> [email protected] >> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers >> >
_______________________________________________ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
