Device driver

A device driver is software that operates and controls a device attached to a computer.^[1] 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.^[2]

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.^[1] 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^[update] hardware and operating systems, drivers operate in many different environments.^[3] 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.^[4]

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.^[5]

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.^[6] 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,^[7] and "downloadable kernel module" in VxWorks. They don't have a particular name in Microsoft Windows because all device drivers are loadable modules.^[8]

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.^[16] On Windows NT, a system with a hybrid kernel, it is common for device drivers to run in either kernel-mode or user-mode.^[17]

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.^[18]

Common levels of abstraction for device drivers include:

• For hardware:
  • Interfacing directly
  • Writing to or reading from a device control register
  • Using some higher-level interface (e.g. Video BIOS)
  • Using another lower-level device driver (e.g., file system drivers using disk drivers)
  • Simulating work with hardware, while doing something entirely different^[19]
• For software:
  • Allowing the operating system direct access to hardware resources
  • Implementing only primitives
  • Implementing an interface for non-driver software (e.g. TWAIN)
  • Implementing a language, sometimes quite high-level (e.g. PostScript)

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.^[20] 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.

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.

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.^[21] 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.^[22] Drivers that may be vulnerable include those for WiFi, Bluetooth,^[23][24] gaming controllers, graphics adapters,^[25] and printers.^[26]

There is a lack of effective kernel vulnerability detection tools, especially for closed-source operating systems such as Microsoft Windows^[27] where the source code of the device drivers is mostly proprietary and not available to examine,^[28] and drivers often have many privileges.^{[29][30][31][32]}

A group of security researchers considers the lack of isolation as one of the main factors undermining kernel security,^[33] 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.^[34][35]

• Class driver
• Device driver synthesis and verification
• Driver (software)
• Driver wrapper
• Installable File System (IFS) – a file system API for IBM OS/2 and Microsoft Windows NT
• Makedev
• Microcontroller
• Open Data-Link Interface (ODI) – network card API similar to NDIS
• Printer driver
• udev (userspace /dev)
• Uniform Driver Interface (UDI) – a discontinued, cross-platform driver interface project

• Windows Hardware Dev Center
• Linux Hardware Compatibility Lists and Linux Drivers
• Understanding Modern Device Drivers(Linux)
• BinaryDriverHowto, Ubuntu.
• Linux Drivers Source