device driver
Enable an AI agent to recognise a device driver, assess whether it can safely mediate access to a particular device in a particular execution environment, and determine permitted lifecycle and operational actions.
Research draft, second pass
A second pass drafted this model: the structure a model of this thing needs, and what is known about it in the world. The line under this one says how the second half was obtained - researched against sources, or recalled without web access, in which case nothing here was read anywhere and every claim is a lead to verify. Unreviewed either way.
Researched by: Codex + Grok
Purpose and description
Enable an AI agent to recognise a device driver, assess whether it can safely mediate access to a particular device in a particular execution environment, and determine permitted lifecycle and operational actions.
A kernel-mode or privileged software component that implements a device-class or bus protocol so the operating system and user-space programs can access a specific hardware device (or a virtual stand-in) through a stable, OS-defined interface rather than by programming the device registers themselves.
It can be Identify the driver actually bound to a device and compare it with the intended release.; Check device, host and dependency compatibility before proposing deployment.; Inspect available logs, counters and device-operation results to assess health.; Install, update, bind, disable or remove the driver when authority and operational preconditions permit.; Run supported diagnostics or recovery actions within an explicit disruption budget.; Prepare and verify rollback or alternate device access before changing a critical driver..
Distinguishing features
Identify the host interface through which the component exposes device operations; merely calling an existing device interface does not establish that an application is a driver.
Identify the device endpoint or device class whose access the component mediates; distinguish the mediating software from the hardware it controls.
Establish the component's execution and deployment boundary to distinguish host driver code from firmware executed within the device.
Inspect package contents and active components to distinguish the driver implementation from its installer, configuration utility and supporting services.
Determine whether the component serves a physical device, a virtual device or a device-stack filtering role before assigning its operational boundaries.
Scope
+ Driver implementation, release and installed-instance identity
+ Supported device identities, revisions and binding rules
+ Host interfaces, dependencies and execution requirements
+ Installation, loading, binding, updating and removal conditions
+ Device-control behaviour, operational health and recovery evidence
+ Driver provenance, privileges and restrictions on agent actions
- Physical device construction, ownership and hardware maintenance
- Device firmware implementation and its independent update lifecycle
- Operating-system internals beyond the driver's dependencies and interfaces
- Application workflows that consume device services
- Generic package distribution infrastructure
- Human-operated tools or circuits called drivers unless registry research establishes that meaning
Characteristics
- Driver identity and release
- Implementation name, provider, version, build identifier and artifact digest where available Separates similarly named drivers and identifies exactly which implementation the evidence concerns.
- Supported device match
- Device identifiers, classes, revisions and exclusions linked to supporting evidence Prevents a broad product-family match from being treated as proof of compatibility.
- Host compatibility
- Operating-system release, architecture, driver-interface requirements and dependencies Determines whether the driver can be installed and executed in the target environment.
- Execution placement
- Kernel, user-space, mixed or unresolved; associated process or module Helps assess isolation, failure impact and required authority.
- Deployment and binding state
- Separately evidenced package presence, load state, device binding, enablement and restart requirement An installed package does not establish that its driver is active for a device.
- Device-stack role
- Environment-specific role such as function, bus, filter, class or virtual-device provider Clarifies which operations and failures can reasonably be attributed to this driver.
- Granted access
- Granted privileges and access to device resources, memory and caller interfaces Establishes the driver's authority and the consequences of misuse or compromise.
- Observed operation failures
- Failed operations / observed operations, with operation type, interval and configuration Provides contextual health evidence without treating every device failure as a driver defect.
- Operation latency
- Milliseconds, with operation, percentile, workload and measurement boundary Supports diagnosis of timeouts and performance changes under comparable conditions.
- Trust and support assessment
- Signature verification result, policy acceptance, support status and assessment date recorded separately Distinguishes artifact authenticity, local permission to load and ongoing maintenance.
Also called
Where this came from
wikidata · CC0 1.0
Drafted structure
Bundle to layer to finding to question, as the second pass will find it: 6 bundles · 11 layers · 18 findings · 29 questions.
Driver identity and role Establish what component is being modelled and where it participates in device access.
Driver packages, loaded implementations and device-bound instances can have different identities and responsibilities.
Implementation and instance
Connect the named driver to concrete artifacts and runtime instances.
Artifact-to-runtime identity
Record the evidence connecting a provider release, installed files and the active driver instance.
- Does this record describe a driver family, a specific release or an instance running on a particular host? definition
- Which package metadata, artifact identifiers and runtime observations establish that identity? provenance
Device-stack position
Locate the driver's responsibility between callers, other drivers and device endpoints.
Mediation responsibility
Identify the device operations this component implements, translates, forwards or filters.
- Which device endpoint and caller-facing interface does this driver connect? definition
- Which responsibilities belong to adjacent drivers, firmware or supporting services? boundary
Compatibility and binding Describe the conditions under which the driver can serve a target device.
Device recognition, host compatibility and actual driver selection are separate conditions for usable access.
Device eligibility
Determine which devices and revisions are eligible for this implementation.
Supported device evidence
Record declared matches, exclusions and observed compatibility without conflating them.
- Which device identifiers, interface classes and hardware or firmware revisions are declared supported? boundary
- Which provider documentation, matching metadata or tests support compatibility with this exact device? provenance
Host and selection conditions
Capture host requirements and the mechanism selecting a driver for a device.
Loadability and binding
Establish whether the host can load the implementation and whether it is selected for the intended endpoint.
- Which host release, architecture, driver interface and dependencies must be satisfied? boundary
- What evidence shows the current binding, and what selection rule or competing driver could change it? measurement
Deployment and recovery Represent driver lifecycle transitions and their operational consequences.
Changing a driver can interrupt access to the very storage, network or input device needed to recover the host.
Lifecycle transitions
Separate package installation from loading, binding and effective activation.
Effective activation state
Record the current lifecycle state and prerequisites for a requested transition.
- Is the intended release present, loaded, bound and enabled, and is any transition pending a restart? measurement
- Which supported procedure and prerequisites apply to installation, replacement, unbinding or removal? action
Continuity and rollback
Protect dependent operations and preserve a workable recovery route.
Recoverable driver change
Identify disruption risks and evidence that the previous working configuration can be restored.
- Which active workloads and recovery channels depend on the device whose driver will change? boundary
- What retained driver, configuration and alternate access path enable rollback, and how will restored operation be verified? action
Device operations and health Connect supported device behaviour with observations of correct or degraded operation.
A loaded driver can still fail particular commands, workloads or device-state transitions.
Operation contract
Describe the operations exposed through this driver and their applicable conditions.
Supported commands and transitions
Record available operations, completion behaviour and relevant device-state constraints.
- Which operations does this driver expose, and how are successful completion, failure and cancellation reported? definition
- What restrictions apply during device removal, power transitions, reset or concurrent access? boundary
Health and fault attribution
Assess observed operation and separate driver evidence from neighbouring failure causes.
Diagnostic evidence
Associate errors and performance observations with a specific driver, device and workload configuration.
- Which logs, error counts, timeout observations or latency measurements describe this driver's operation under a stated workload? measurement
- What evidence distinguishes a driver defect from hardware, firmware, transport or caller failure? boundary
- Which supported diagnostic or reset action can narrow the cause within the permitted service interruption? action
Trust and control authority Determine whether the driver is acceptable to execute and which changes an agent may perform.
Drivers mediate device resources, so artifact trust and authority to alter device access require explicit evidence.
Artifact trust
Assess origin, integrity, policy acceptance and maintenance evidence for the specific release.
Release trust evidence
Record independently evidenced authenticity, load-policy acceptance and known release restrictions.
- Where was this artifact obtained, and what integrity or signature verification was actually performed? provenance
- Which current support notices, security advisories or local load policies constrain use of this release? boundary
Privileges and agent actions
Connect execution privileges and resource exposure to permitted interventions.
Device-control authorisation
Record the driver's resource access and the agent's separate authority to inspect or change it.
- Where does the driver execute, which device or memory resources can it access, and which callers can invoke its control interface? boundary
- Which driver changes and device-control operations is this agent authorised to perform, under what conditions? action
Evidence and external alignment What the world already says about this thing, gathered so the model can be checked against it.
A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.
Reported evidence
Findings from the breadth pass, kept separate from the structural claims.
Kinds and varieties
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Kernel-mode / ring-0 driver (Windows KMDF/WDM, Linux in-tree module, BSD kmod)
- User-mode driver (Windows UMDF, Linux FUSE/UIO/VFIO userspace, some printer and scanner stacks)
- Bus / host-controller driver (PCI, USB, I2C, SPI, Thunderbolt)
- Class / function driver (storage, network, display, audio, HID, serial)
- Filter / miniport / stacked driver (upper/lower filters, NDIS miniport, SCSI miniport)
- Virtual / paravirtual / hypervisor driver (virtio, Hyper-V VSC/VSP, vGPU)
- Firmware-assisted / offloaded driver (SmartNIC, DPDK PMD, GPU kernel-mode plus user-mode ICD)
- Boot / early-init driver (UEFI driver, initramfs storage/network, Windows boot-start)
- Which of these kinds and varieties hold for the sense of device driver this model covers, and on what evidence? provenance
Identifiers and schemes
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Wikidata - Q750548 - item 'device driver' (software that operates or controls a particular type of device)
- PCI ID - VVVV:DDDD[.SSSS] (4-digit hex Vendor ID : Device ID, optional Subsystem) - pci.ids / PCI-SIG assigned IDs used by OS match tables (Linux modalias, Windows INF Hardware IDs)
- USB ID - USB\VID_vvvv&PID_pppp[&REV_rrrr[&MI_nn]] - USB-IF vendor/product IDs; Windows hardware-ID syntax; Linux usb:vXXXXpYYYY*
- Windows Hardware ID / Compatible ID - PCI\VEN_vvvv&DEV_dddd&SUBSYS_ssssrrrr&REV_nn ; USB\... ; ACPI\... ; HID\... - INF matching keys that bind a .sys/.dll package to a PnP node
- Linux modalias / MODULE_DEVICE_TABLE - pci:v0000VVVVd0000DDDDsv*sd*bc*sc*i* ; usb:vXXXXpYYYY* - depmod/udev alias used to autoload a kernel module
- Windows driver package / catalog - INF file + CAT catalog + Authenticode/attestation signature; Driver Store path FileRepository\<inf>_<hash> - the installable identity of a Windows driver, distinct from the binary .sys name
- Which of these identifiers and schemes hold for the sense of device driver this model covers, and on what evidence? provenance
Standards and regulation
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- USB-IF USB 2.0/3.x specifications - device class documents that define which class driver (HID, MSC, CDC, UVC, UAC) an OS may bind without a vendor driver
- PCI-SIG PCI Express Base Specification - configuration space, BARs, Vendor/Device/Class IDs used for driver matching
- UEFI Forum UEFI Specification (Driver Execution Environment, EFI Driver Model) - boot-time device drivers loaded from firmware or option ROMs
- IEEE 1275-1994 (Open Firmware / IEEE Std 1275) - historical open firmware driver model (SPARC, PowerPC, some ARM)
- ISO/IEC 9945 (POSIX.1) - portable I/O and device-file semantics that user programs see; does not specify kernel driver ABI
- Microsoft Windows Hardware Compatibility Program / WHCP and kernel-mode code integrity (Attestation / EV signing, HVCI) - required to load drivers on 64-bit Windows
- Linux kernel ABI / DKMS practice and GPLv2 licensing of in-tree drivers - de facto standard for Linux driver form, not an ISO standard
- UNECE WP.29 / ISO 21434 and IEC 62443 (when the driver is in an automotive or industrial control system) - cybersecurity process applied to driver supply chain rather than the driver format itself
- EU Cyber Resilience Act (Regulation (EU) 2024/2847) and US FDA premarket guidance for device software (when the driver ships with a medical or consumer connected product) - product-level duties that include driver update and vulnerability handling
- Which of these standards and regulation hold for the sense of device driver this model covers, and on what evidence? provenance
Real-world use
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- OS boot: a storage and filesystem driver (AHCI/NVMe + NTFS/ext4) must load before the root volume is mounted; network drivers load for PXE/iSCSI boot.
- Plug-and-play: inserting a USB stick or PCIe NIC causes the OS to match Vendor/Product or Class IDs and bind a class or vendor driver; Windows copies the package into the Driver Store.
- OEM system image: laptop vendors ship INF + signed binaries for GPU, Wi-Fi, audio, and HID; Linux distros ship the same hardware via in-tree modules or linux-firmware blobs plus a kernel module.
- Printers and scanners: often a user-mode driver (Windows print driver / IPP Everywhere / CUPS filter) rather than a kernel module; the kernel only exposes USB/IPP.
- Virtual machines: guest virtio-net/blk or Hyper-V synthetic drivers replace emulated hardware for I/O.
- Embedded and RTOS: a board-support package registers drivers for SoC peripherals (UART, I2C, GPIO, Ethernet MAC) against a HAL or device-tree.
- Malware and anti-cheat: kernel drivers are used both as signed anti-cheat / EDR sensors and as a persistence/privilege-escalation vehicle (vulnerable signed drivers).
- Which of these real-world use hold for the sense of device driver this model covers, and on what evidence? provenance
Typical measurements
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Driver binary / package size - 10 KiB (GPIO/UART) to 50-500 MiB (GPU packages with user-mode stacks) - bytes
- Initialization / probe latency - 0.1-50 ms for simple USB/PCI functions; 0.5-10 s for GPU or Wi-Fi firmware load - seconds
- I/O throughput of the bound device (as seen through the driver) - 12-480 Mbit/s (USB 2), ~1-200 Gbit/s (NIC), ~1-14 GB/s (NVMe) - bit/s or byte/s
- Interrupt / DPC / NAPI latency - 1-100 µs typical; milliseconds under load or with poorly written ISRs - seconds
- Kernel-mode CPU overhead - <1 % idle polling-off; 5-30 % of one core under high packet or block I/O without offload - percent of CPU
- CVE / vulnerability count in a vendor driver family per year - 0-several dozen for large GPU/Wi-Fi stacks; long-tail of BYOVD (bring-your-own-vulnerable-driver) CVEs - count per year
- Which of these typical measurements hold for the sense of device driver this model covers, and on what evidence? provenance
Failure modes and hazards
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Bugcheck / kernel panic from a null pointer, use-after-free, or deadlock in kernel-mode code (Windows DRIVER_IRQL_NOT_LESS_OR_EQUAL, Linux oops in module).
- Device not found / Code 28 / missing module: no matching INF or modalias, unsigned driver blocked by Secure Boot or HVCI.
- Wrong driver bound (generic class driver vs vendor driver) causing missing features, reduced speed, or bricked firmware updates.
- Firmware load failure or version skew between driver and device firmware (Wi-Fi, GPU, SSD).
- Resource leak: DMA buffers, interrupt lines, or I/O memory not released on surprise removal; can stall the bus.
- Privilege-escalation hazard: a signed kernel driver with a write-what-where IOCTL is reused by malware (BYOVD).
- Performance collapse from interrupt storms, disabled offloads, or polling threads that pin CPUs.
- Supply-chain / update hazard: a compromised driver update signs and loads into every kernel that trusts the vendor certificate.
- Which of these failure modes and hazards hold for the sense of device driver this model covers, and on what evidence? provenance
Regional variation
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Windows-centric OEM markets (consumer PCs) distribute drivers as WHQL/attestation-signed INF packages; Linux-centric servers and Android/embedded use in-tree modules plus a linux-firmware blob, with no INF.
- China and some enterprise environments require domestic cryptographic modules and locally signed kernel modules; Western Windows requires Microsoft attestation or EV + WHCP.
- Japanese and some industrial OEMs still ship vendor-specific serial and GPIB drivers; EU public-sector printing has shifted toward driverless IPP Everywhere / Mopria.
- macOS/iOS use the DriverKit / I/O Kit user-space dext model and App Store notarization rather than kernel kexts (kexts largely deprecated since macOS Catalina/Big Sur).
- Naming: US/Windows 'device driver' vs Unix 'kernel module' / 'device driver' vs historical 'device handler'; printers often called 'print driver' even when entirely user-mode.
- Which of these regional variation hold for the sense of device driver this model covers, and on what evidence? provenance
Neighbouring kinds and how to tell them apart
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- firmware (device ROM, option ROM, UEFI driver, microcontroller code) - Firmware runs on the device or in pre-OS firmware; a device driver runs on the host CPU under the OS. Test: after the OS has booted, is the code loaded into the kernel/user driver framework and bound to a PnP node or /dev node? If it ran from SPI flash before the OS, it is firmware.
- userspace library / SDK / HAL (OpenGL/Vulkan ICD, libusb, vendor SDK) - A library is linked by an application and has no kernel privilege unless it talks to a driver. Test: does unloading it require a kernel module unload, DriverStore removal, or just unlinking a .so/.dll from a process?
- operating-system kernel / HAL - The kernel is the host; a driver is a loadable (or compiled-in) component that the kernel binds to a device class. Test: is it optional per device and matched by hardware ID, or is it the scheduler/memory manager itself?
- device tree / ACPI / INF / udev rule (hardware description) - These describe which driver to bind and with which properties; they are not the driver. Test: can the file execute I/O to the device by itself? If it only names a compatible string or Hardware ID, it is description, not a driver.
- microcode / CPU update - Microcode patches the processor itself and is applied by the BIOS or OS early; it is not bound to a peripheral. Test: is the payload a CPUID-matched patch from Intel/AMD, or a module matched to a PCI/USB ID?
- virtual device / hypervisor backend (QEMU device model, Hyper-V VSP) - The backend emulates or multiplexes the device in the host; the guest still loads a (para)virtual driver. Test: which address space does the code run in - guest kernel (driver) or host hypervisor (backend)?
- Which of these neighbouring kinds and how to tell them apart hold for the sense of device driver this model covers, and on what evidence? provenance
Sources
- Device driver - Core definition as hardware-interface software; kernel vs user-mode placement; virtual devices; class/bus/function distinctions used in practice.
- Getting started with drivers - Windows Driver Kit (WDK) - Windows KMDF/UMDF/WDM kinds, driver stacks, INF packaging, WHQL/attestation signing as the practical identity of a Windows driver.
- Linux Device Drivers, 3rd Edition - Chapter 1: An Introduction to Device Drivers (online) - POSIX/Linux character, block and network device classes; module vs in-tree; the driver as the kernel's hardware abstraction, not the userspace library.
- PCI Express Base Specification (overview of software/device interface) - Bus-level identifiers (Vendor ID / Device ID / Class Code) that operating systems use to bind a driver to a function; neighbour relationship to firmware and BARs.
What the second pass must settle
- Does this registry entry mean software that mediates device access, an electronic driver component, or another physical object, given its PHY / PHY.OBJ placement and missing definition?
- Does an existing Vercy world model already cover the intended concept and require this registry entry to link to it?
- Should the model cover a driver family, release and deployed instance together, or treat them as related records with distinct state evidence?
- Which operating systems and driver frameworks must the model support, and which lifecycle or device-stack terms require platform-specific interpretation?
- Are virtual-device, filter and user-space drivers included, and where should their boundaries with firmware and supporting services be drawn?