Device driver

A device driver is software that operates and controls a device attached to a computer. The purpose of device drivers is to provide hardware abstraction, i.e., to provide a standardized interface over which other software can take advantage of hardware without possessing intricate, specialized knowledge of each piece of hardware.

A driver communicates with the device through the computer bus or communications subsystem to which the hardware connects. A calling app can invoke a routine within the driver, which issues commands to the device and returns the resulting data to the calling app.

Drivers are hardware-dependent and operating-system–specific. They usually provide the interrupt handling required for any necessary asynchronous time-dependent hardware interface.

Purpose

The main purpose of device drivers is to provide hardware abstraction by acting as a translator between a hardware device and the app or operating systems using it. Software developers can write higher-level code independently of whatever specific hardware the end-user is using.

For example, an app for interacting with a serial port may have two routines to send data and receive data. At a lower level, a device driver implementing these functions would communicate with the computer's serial port controller. This driver knows the appropriate commands. For instance, the commands needed to control a 16550 UART are different from those of a USB-to-serial adapter, but the device driver abstracts these details into the same (or similar) software interface. Therefore, the same app on different computers uses the same routines to communicate with device drivers and gets the same results, without getting concerned with how drivers get said results.

Because of the diversity of modern hardware and operating systems, drivers operate in many different environments. Drivers may interface with printers, video adapters, network interface controllers (NICs), sound cards, PC chipsets, power- and battery management features, local buses (in particular, for bus mastering on modern systems), computer storage devices (such as hard disk, CD-ROM, and floppy disk drives), image scanners, digital cameras, digital terrestrial television tuners, IrDA adapters, wireless personal area networks (such as Bluetooth Low Energy, Thread, Zigbee, and Z-Wave), and even file systems. Choosing and installing the correct device drivers for the given hardware is often a key component of computer system configuration.

Development

Writing a device driver requires an in-depth understanding of how the hardware and the software work for a given platform function. Because drivers require low-level access to hardware functions in order to operate, drivers typically operate in a highly privileged environment and can cause system operational issues if something goes wrong. (In contrast, misbehavior in most user-level software on modern operating systems can be stopped without greatly affecting the rest of the system.) Even drivers executing in user mode can crash a system if the device is erroneously programmed. These factors make it more difficult and dangerous to diagnose problems.

The task of writing drivers thus usually falls to software developers or computer engineers who work for hardware vendors because they possess the necessary information at hand. It is in the manufacturer's interest to guarantee that their clients can use their hardware optimally. However, with the growth of the Linux operating systems, non-vendors have written numerous free and open-source device drivers for proprietary devices, including free and open-source graphics device drivers. In such cases, the necessary information on how device works must be obtained either from the hardware vendor (as is the case with open-source hardware) or via reverse engineering.

Operating systems support device drivers implemented as loadable kernel modules, which can be loaded into memory only when necessary and then unloaded, thus saving kernel memory. Each OS, however, has a different term for these modules, including "kernel loadable module" in FreeBSD, "kernel extension module" in AIX, "dynamically loadable kernel module" in HP-UX, and "downloadable kernel module" in VxWorks. They don't have a particular name in Microsoft Windows because all device drivers are loadable modules.

In Microsoft Windows

Device drivers in Microsoft Windows bear use the .sys filename extension. Kernel-mode device drivers interface with the OS through the Hardware Abstraction Layer (HAL), in implemented in hal.dll.

Windows uses a combination of full drivers and "minidrivers" (more specifically "miniclass" and "miniport" drivers), where the full driver is provided with the operating system while vendors develop minidrivers to implement or optimize a subset of the full driver stack.

APIs and frameworks

The operating system categorizes devices into classes and provides a number of class-specific driver APIs, including:

All of the above can have full drivers and minidrivers.

Microsoft develops and maintains Windows Driver Frameworks (WDF), a set of libraries and tools that intend to ease the process of creating high-quality drivers. WDF includes User-Mode Driver Framework (UMDF) that encourages development of user-mode drivers for devices that can communicate with the OS via message-based protocols. If such drivers malfunction, they do not cause system instability.

The Kernel-Mode Driver Framework (KMDF) caters to the development of traditional kernel-mode device drivers but attempts to provide standard implementations of functions that are known to cause problems, including cancellation of I/O operations, power management, and plug-and-play device support.

Design principles

Before 2017, it was common for hardware vendors to ship large software packages containing one or two device drivers, utilities (which may or may not be essential), and an installer for installing them in proper order. This meant that installing every device driver required knowledge specific to that driver alone. This posed a problem for automation.

In 2017, Microsoft introduced the DCH principle. DCH stands for "Declarative", "Componentized", and "Hardware Support Apps" (HSA). Device drivers adhering to the DCH principle can be installed solely through their INF files, meaning there is a standard, automation-friendly way for installing all DCH-compliant drivers. Edition-specific, OEM-specific, and optional customizations are kept separate from the driver package. The HSA package contains utilities and user interfaces for the device driver and is not shipped with the driver package, although the driver package is allowed to direct the user to Microsoft Store, where the HSA is hosted.

In macOS

Apple has an open-source framework for developing drivers on macOS, called I/O Kit.

In Linux distros

In Linux environments, developers can build device drivers as parts of the kernel, separately as loadable modules, or as user-mode drivers for certain types of devices where kernel interfaces exist, such as for USB devices. Makedev includes a list of the devices in Linux, including ttyS (terminal), lp (parallel port), hd (disk), loop, and sound (these include mixer, sequencer, dsp, and audio).

Linux distros provide a number of APIs and frameworks for developing or supporting device drivers, including:

Privilege levels

Depending on the operating system, device drivers may be permitted to run at various different privilege levels. The choice of which level of privilege the drivers are in is largely decided by the type of kernel an operating system uses. An operating system that uses a monolithic kernel, such as the Linux kernel, will typically run device drivers with the same privilege as all other kernel objects. By contrast, a system designed around a microkernel, such as Minix, will run drivers as processes independent from the kernel but that use drivers for essential input-output functions. On Windows NT, a system with a hybrid kernel, it is common for device drivers to run in either kernel-mode or user-mode.

The most common mechanism for segregating memory into various privilege levels is via protection rings. On many systems, such as those with x86 and ARM processors, switching between rings imposes a performance penalty, a factor that operating system developers and embedded software engineers consider when creating drivers for devices, such as network interface cards, which prefer to run with low latency. The primary benefit of running a driver in user mode is improved stability, since a poorly written user-mode device driver cannot crash the system by overwriting kernel memory.

Common levels of abstraction for device drivers include:

Virtual device drivers

Virtual device drivers represent a particular variant of device drivers. They are used to emulate a hardware device, particularly in virtualization environments, for example, when a guest operating system is run on a Xen host. Instead of enabling the guest operating system to control the hardware, virtual device drivers emulate a piece of hardware, so that the guest operating system and its drivers running inside a virtual machine can have the illusion of accessing real hardware. Attempts by the guest operating system to access the hardware are routed to the virtual device driver in the host operating system. The virtual device driver can also send simulated hardware-related events like interrupts to the virtual machine.

Virtual devices may also operate in a non-virtualized environment. For example, a virtual network adapter is used with a virtual private network, while a virtual disk device is used with iSCSI and Daemon Tools.

There are several variants of virtual device drivers, such as VxDs and VLMs.

Identifiers

A device on the PCI bus or USB is identified by two IDs which consist of two bytes each. The vendor ID identifies the vendor of the device. The device ID identifies a specific device from that manufacturer/vendor.

A PCI device often has an ID pair for the main chip of the device, and also a subsystem ID pair that identifies the vendor, which may be different from the chip manufacturer.

Security

Computers often have many diverse and customized device drivers running in their operating system kernel, which often contain various bugs and vulnerabilities, making them a target for exploits. A Bring Your Own Vulnerable Driver (BYOVD) attacker installs any signed, old third-party driver with known vulnerabilities that allow malicious code to be inserted into the kernel. Drivers that may be vulnerable include those for WiFi, Bluetooth, gaming controllers, graphics adapters, and printers.

There is a lack of effective kernel vulnerability detection tools, especially for closed-source operating systems such as Microsoft Windows where the source code of the device drivers is mostly proprietary and not available to examine, and drivers often have many privileges.

A group of security researchers considers the lack of isolation as one of the main factors undermining kernel security, and published an isolation framework to protect operating system kernels, primarily the monolithic Linux kernel whose drivers they say get ~80,000 commits per year.

This section is an excerpt from Kernel (operating system) § Protection.[edit]

An important consideration in the design of a kernel is the support it provides for protection from faults (fault tolerance) and from malicious behaviours (security). These two aspects are usually not clearly distinguished, and the adoption of this distinction in the kernel design leads to the rejection of a hierarchical structure for protection.

The mechanisms or policies provided by the kernel can be classified according to several criteria, including:

  • whether they are static (enforced at compile time) or dynamic (enforced at run time);
  • whether they are pre-emptive or post-detection;
  • whether they are hardware-supported or language-based;
  • whether they are more an open mechanism, or a binding policy;
  • according to the protection principles they satisfy (e.g., Denning);
  • and many more.

See also

References

  1. 1 2 "What is all device driver?". WhatIs.com. TechTarget. Archived from the original on 13 February 2021. Retrieved 19 March 2018.
  2. ↑ EMC Education Services (2010). Information Storage and Management: Storing, Managing, and Protecting Digital Information. John Wiley & Sons. ISBN 9780470618332. Archived from the original on 2021-02-13. Retrieved 2020-11-10.
  3. ↑ Deborah Morley (2009). Understanding Computers 2009: Today and Tomorrow. Cengage Learning. ISBN 9780324830132. Archived from the original on 2021-06-09. Retrieved 2020-11-10.
  4. ↑ "What are Device Drivers and why do we need them?". drivers.com. April 17, 2015. Archived from the original on November 20, 2016. Retrieved March 19, 2018.
  5. ↑ Burke, Timothy (1995). Writing device drivers: tutorial and reference. Digital Press. ISBN 9781555581411. Archived from the original on 2021-01-26. Retrieved 2016-08-05.
  6. ↑ "Introduction to Linux Loadable Kernel Modules". tldp.org. Retrieved 2026-11-10.
  7. ↑ "Managing and Developing DynamicallyLoadable Kernel Modules". Hewlett-Packard. June 7, 2001.
  8. ↑ "What Determines When a Driver Is Loaded". Microsoft Developer Network. Microsoft. November 21, 2012. Archived from the original on March 6, 2013. Retrieved May 5, 2013.
  9. ↑ Blunden, Bill (2009). The Rootkit Arsenal: Escape and Evasion in the Dark Corners of the System. Jones & Bartlett Learning. p. 101. ISBN 978-1-59822-061-2.
  10. ↑ "Choosing a driver model". Microsoft. Retrieved 2021-03-30.
  11. 1 2 Dell US. "What are DCH drivers and why do you need to know about them? | Dell US". www.dell.com. Retrieved 2020-10-29.
  12. ↑ Hudek, Ted; Harvey, Beth (14 July 2025). "DCH design principles and best practices". Windows hardware developer documentation. Microsoft – via Microsoft Learn.
  13. ↑ "MAKEDEV — Linux Command — Unix Command". Linux.about.com. 2009-09-11. Archived from the original on 2009-04-30. Retrieved 2009-09-17.
  14. ↑ "CCISS". SourceForge. 2010. Archived from the original on 2010-08-21. Retrieved 2010-08-11. Drivers for the HP (previously Compaq) Smart Array controllers which provide hardware RAID capability.
  15. ↑ Russell, Steve; et al. (2003-10-21). "Abbreviations and acronyms". Server Consolidation with the IBM eserver xSeries 440 and VMware ESX Server (PDF). IBM International Technical Support Organization. p. 207. ISBN 0-7384-2684-9. Archived from the original (PDF) on 20 July 2004.
  16. ↑ Tanenbaum, Andrew; Woodhull, Albert (2006). Operating Systems, Design and Implementation (3rd. ed.). Upper Saddle River, NJ: Pearson Pretence Hall. p. 256. ISBN 0-13-142938-8.
  17. ↑ Yosifovich, Pavel; Ionescu, Alex; Russinovich, Mark; Solomon, David (2017). Windows Internals, Part 1 (Seventh ed.). Redmond, Washington: Microsoft Press. ISBN 978-0-7356-8418-8.
  18. ↑ "Introduction to the User-Mode Driver Framework (UMDF)". Microsoft. 2006-10-10. Archived from the original on 2010-01-07. Retrieved 2008-03-04.
  19. ↑ Computer Peripherals and Interfaces. Technical Publications Pune. January 2008. pp. 5–8. ISBN 978-8184314748. Retrieved 2016-05-03.[permanent dead link]
  20. ↑ Chisnall, David (2007). The definitive guide to the xen hypervisor (First ed.). USA: Prentice Hall Press. ISBN 978-0-13-234971-0.
  21. ↑ Talebi, Seyed Mohammadjavad Seyed; Tavakoli, Hamid; Zhang, Hang; Zhang, Zheng; Sani, Ardalan Amiri; Qian, Zhiyun (2018). Charm: Facilitating Dynamic Analysis of Device Drivers of Mobile Systems. pp. 291–307. ISBN 9781939133045. Archived from the original on 5 November 2022. Retrieved 5 November 2022.
  22. ↑ Goodin, Dan (14 October 2022). "How a Microsoft blunder opened millions of PCs to potent malware attacks". Ars Technica. Archived from the original on 8 November 2022. Retrieved 8 November 2022.
  23. ↑ Ridley, Jacob (9 February 2022). "You're going to want to update your Wi-Fi and Bluetooth drivers today". PC Gamer. Archived from the original on 5 November 2022. Retrieved 5 November 2022.
  24. ↑ "Wireless 'BlueBorne' Attacks Target Billions of Bluetooth Devices". threatpost.com. Archived from the original on 5 November 2022. Retrieved 5 November 2022.
  25. ↑ Spadafora, Anthony (12 January 2022). "Installing gaming drivers might leave your PC vulnerable to cyberattacks". TechRadar. Archived from the original on 5 November 2022. Retrieved 5 November 2022.
  26. ↑ "HP patches vulnerable driver lurking in printers for 16 years". ZDNET. Archived from the original on 5 November 2022. Retrieved 5 November 2022.
  27. ↑ Pan, Jianfeng; Yan, Guanglu; Fan, Xiaocao (2017). Digtool: A {Virtualization-Based} Framework for Detecting Kernel Vulnerabilities. USENIX Association. pp. 149–165. ISBN 9781931971409. Retrieved 5 November 2022.
  28. ↑ King, Bertel (18 June 2022). "Closed Source vs. Open Source Hardware Drivers: Why It Matters". MUO. Archived from the original on 5 November 2022. Retrieved 5 November 2022.
  29. ↑ Branscombe, Mary (7 April 2022). "How Microsoft blocks vulnerable and malicious drivers in Defender, third-party security tools and in Windows 11". TechRepublic. Archived from the original on 5 November 2022. Retrieved 5 November 2022.
  30. ↑ Goodin, Dan (5 October 2022). "No fix in sight for mile-wide loophole plaguing a key Windows defense for years". Ars Technica. Archived from the original on 5 November 2022. Retrieved 5 November 2022.
  31. ↑ Davenport, Corbin. ""Bring Your Own Vulnerable Driver" Attacks Are Breaking Windows". How-To Geek. Archived from the original on 5 November 2022. Retrieved 5 November 2022.
  32. ↑ "Windows 10 Security Alert: Vulnerabilities Found in Over 40 Drivers". BleepingComputer. Archived from the original on 5 November 2022. Retrieved 5 November 2022.
  33. ↑ "Fine-grained kernel isolation". mars-research.github.io. Archived from the original on 15 September 2022. Retrieved 15 September 2022.
  34. ↑ Fetzer, Mary. "Automatic device driver isolation protects against bugs in operating systems". Pennsylvania State University via techxplore.com. Archived from the original on 15 September 2022. Retrieved 15 September 2022.
  35. ↑ Huang, Yongzhe; Narayanan, Vikram; Detweiler, David; Huang, Kaiming; Tan, Gang; Jaeger, Trent; Burtsev, Anton (2022). "KSplit: Automating Device Driver Isolation" (PDF). Archived from the original (PDF) on 15 September 2022. Retrieved 15 September 2022.
  36. ↑ Wulf 1974 pp.337–345
  37. ↑ Denning 1976
  38. ↑ Swift 2005, p.29 quote: "isolation, resource control, decision verification (checking), and error recovery."