[SOLVED]Drivers in a microkernel.

[handuel]

I have recentely got interested in microkernel design, but am struggling to understand how drivers would work. As all of the drivers are usermode processes, how do they actually communicate with the hardware? The system I am working on uses memory mapped io, so I could just give any driver permissions to access all the locations in memory that correspond to a device, however this would kind of defeat the point of increasing security by running drivers in user mode. What are common methods of working out what permissions to give to each driver?

[dschatz]

The point of running the driver in userspace is to restrict its privileges. My device driver needs a region of memory for mmio so I will map that region into the drivers address space. If the driver is somehow compromised or buggy, then it can only do things it has privileges to do, such as read/write to the mmio region, but it can't write to arbitrary memory like a supervisor level kernel could.

[handuel]

I understand that, but my question is how the kernel should actually allocate permissions. Obviously the currently installed drivers can be extremely arbitary, so how does it know what memory it should allow each one to access?

[Combuster]

so how does it know what memory it should allow each one to access?

Another device driver.

When you build for a certain platform, you know by virtue of that platform that it's sure to have a few things, and where those things are. Everything that might be present can be enumerated by another driver, most by plug-and-play, and for the remaining few, by probing. When you find a device, you also know what regions it uses, and you can delegate that and only that region to the driver you're about to start.

[handuel]

I suppose that was kind of obvious (or at least it is now it was pointed out) , sorry for the stupid question, and thank you very much for your help.

[Gigasoft]

Running drivers in user mode only gives a false sense of security. If a malicious driver is loaded for a device that can access arbitrary memory locations, then so can the driver. Furthermore, with level triggered interrupts, any IRQ asserted by a device will prevent lower priority IRQs from being serviced until deasserted (which requires an action by the driver).

[Brendan]

Hi,

Running drivers in user mode only gives a false sense of security. If a malicious driver is loaded for a device that can access arbitrary memory locations, then so can the driver. Furthermore, with level triggered interrupts, any IRQ asserted by a device will prevent lower priority IRQs from being serviced until deasserted (which requires an action by the driver).

If the device doesn't use any DMA or bus mastering; then you can guarantee 100% security.

If the device uses the old ISA DMA controller, then you can provide functions to setup the ISA DMA transfer in the kernel and do your own sanity/permission checks (and not give the driver access to the ISA DMA chips at all).

For things like PCI bus mastering; if the system has an IOMMU then you use it to prevent the device (and the device driver) from doing anything it shouldn't.

That only leaves devices that do things like PCI bus mastering in systems that don't have an IOMMU. For these cases, you can't guarantee 100% security (e.g. prevent malicious drivers), but you can ensure that 99% of accidents (bugs in normal drivers) don't end up trashing things like the kernel.

In contrast; if you use a monolithic kernel you're screwed in 100% of cases. Something like finding an "uninitialised pointer" bug in a driver can be a nightmare (e.g. starting with symptoms like "something somewhere is causing applications to crash at random times") rather than just getting a page fault that makes the problem obvious or having the symptoms isolated to the device driver's address space. For malicious drivers (even for drivers for devices like USB coffee cup warmers that only need to talk to the USB controller driver and don't need any access to any IO ports or memory at all), there are only 2 options - an expensive and annoying "digitally signed drivers" scheme that can only work if you can prove the driver isn't malicious before signing it, and making it impossible to use device drivers that aren't in source code form (for open source drivers, you can't assume a cracker hasn't modified/replaced the binary after it was compiled, and also can't assume that the original source code isn't malicious and nobody has noticed).

Furthermore, with level triggered interrupts, any IRQ asserted by a device will prevent lower priority IRQs from being serviced until deasserted (which requires an action by the driver).

If the driver doesn't ask the kernel to send EOI then kernel can assume the driver is dodgy after some sort of time-out. If the driver asks the kernel to send EOI but hasn't serviced the device itself, then (for level triggered IRQs) you get an IRQ flood that can be easily detected by the kernel. In either case, when the kernel detects the problem it can mask the IRQ, terminate the dodgy driver, etc; and everything else (e.g. kernel, applications, other drivers using other IRQs, etc) can continue to function without any interruption.


Cheers,

Brendan