Information on implementing L4

Gernot Heiser gernot at cse.unsw.edu.au
Sat Sep 15 04:44:08 CEST 2018


On 15 Sep 2018, at 12:00, John <john.r.moser at gmail.com> wrote:
> 
> The fact that you separated the drivers into different process contexts doesn't mean they're now some userland program. 

It means exactly that.

> These are privileged parts of the operating system. 

Sorry, they are not. There seems to be a fundamental misunderstanding of microkernels.

A driver is a normal usermode program. Like any program, it has some privileges, authorised by caps. These include the rights to its own memory and some communication channels (like any process). In the case of a driver, it also includes rights to access device registers, and to receive interrupt notifications. That’s it.

The driver reads and writes device registers, receives and acknowledges interrupts, and communicates with other parts of the system by some system-defined protocols, which may be via IPC endpoints, notifications, shared memory, or DMA memory. It cannot do more damage than corrupting I/O buffers, sending garbage to the device, deny service. (Yes, there are broken devices where by controlling them you can cause other damage, such as re-flashing firmware, but that’s a hardware flaw against which all software is defenceless.)

> 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.

Yes, the driver can launch integrity, confidentiality and availability attacks against *the data that is read or written by the device*. But there are well-known means to protect against the first tow: sign and encrypt all data. The only thing threat that cannot easily be prevented is availability, but only as far as the specific device is concerned.

I can recommend the following paper on the threat scenarios that can and cannot be dealt with by a microkernel design: https://ts.data61.csiro.au/publications/csiroabstracts/Biggs_LH_18.abstract.pml

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


More information about the l4-hackers mailing list