Editing Microkernel (section)

==Device drivers==
[[Device driver]]s frequently perform [[direct memory access]] (DMA), and therefore can write to arbitrary locations of physical memory, including various kernel data structures. Such drivers must therefore be trusted. It is a common misconception that this means that they must be part of the kernel. In fact, a driver is not inherently more or less trustworthy by being part of the kernel.

While running a device driver in user space does not necessarily reduce the damage a misbehaving driver can cause, in practice it is beneficial for system stability in the presence of buggy (rather than malicious) drivers: memory-access violations by the driver code itself (as opposed to the device) may still be caught by the memory-management hardware. Furthermore, many devices are not DMA-capable, their drivers can be made untrusted by running them in user space. Recently, an increasing number of computers feature [[IOMMU]]s, many of which can be used to restrict a device's access to physical memory.<ref name="Wong_07">{{cite journal |title=I/O, I/O, It's Off to Virtual Work We Go |url=http://www.electronicdesign.com/embedded/io-io-its-virtual-work-we-go |last=Wong |first=William |journal=[[Electronic Design (magazine)|Electronic Design]] |date=27 April 2007 |access-date=8 June 2009 }}</ref> This also allows user-mode drivers to become untrusted.

User-mode drivers actually predate microkernels. The [[Michigan Terminal System]] (MTS), in 1967, supported user space drivers (including its file system support), the first operating system to be designed with that capability.<ref>{{cite conference |title=Organization and Features of the Michigan Terminal System |first=Michael T. |last=Alexander |book-title=Proceedings of the November 16–18, 1971, Fall Joint Computer Conference |volume=40 |year=1971 |pages=589–591 |doi=10.1145/1478873.1478951|s2cid=14614148 |doi-access=free }}</ref> Historically, drivers were less of a problem, as the number of devices was small and trusted anyway, so having them in the kernel simplified the design and avoided potential performance problems. This led to the traditional driver-in-the-kernel style of Unix,<ref name="Lions book">{{cite book |title=Lions' Commentary on UNIX 6th Edition, with Source Code |last=Lions |first=John |date=1 August 1977 |isbn=978-1-57398-013-5 |publisher=Peer-To-Peer Communications|title-link=Lions' Commentary on UNIX 6th Edition, with Source Code }}</ref> Linux, and Windows NT. With the proliferation of various kinds of peripherals, the amount of driver code escalated and in modern operating systems dominates the kernel in code size.