Hardware Abstraction

Technical Overview

Hardware abstraction is the process by which an operating system presents a uniform, stable interface to software above it, regardless of the enormous variety of hardware below it. Without abstraction, every application would need to know the precise command set of every disk controller, network chip, and timer it might encounter — an impossibility in a world with hundreds of hardware vendors and thousands of device variants. The abstraction layer translates the physical reality of hardware into logical primitives: a "file," a "socket," a "clock," a "CPU."

Linux approaches hardware abstraction through architecture-specific code organized under arch/, a driver model with a bus/device/driver trichotomy, and standardized hardware discovery mechanisms. Windows implements a Hardware Abstraction Layer as a separately loadable component (hal.dll). Both approaches achieve the same goal: the upper layers of the OS — the scheduler, the VFS, the network stack — are written once and run on every supported hardware configuration.

Prerequisites

01-what-is-a-kernel.md: understanding of kernel subsystems
02-user-space-vs-kernel-space.md: where hardware access occurs
Basic understanding of computer hardware components (CPU, RAM, buses, devices)

Core Content

Why Abstraction Is Needed

Consider these concrete problems that hardware abstraction solves:

Portability: The same Linux kernel source compiles and runs on x86-64, ARM64, RISC-V, MIPS, PowerPC, and s390. The scheduler, the VFS, and the TCP stack are identical; only the architecture-specific code (arch/x86/, arch/arm64/, etc.) differs.

Stability: A program compiled against the POSIX API for Linux 2.6 in 2003 still runs on Linux 6.6 in 2024. The hardware underneath has changed dramatically — NVMe replaced SATA, multi-core replaced single-core — but the abstraction is stable.

Driver isolation: A buggy Realtek network driver doesn't break the ext4 filesystem implementation. Both use the same kernel APIs (PCI bus, DMA mapping, interrupt handling), but they are isolated subsystems.

Power management: ACPI provides a unified interface for suspending, hibernating, and adjusting CPU frequency regardless of whether the hardware is from Intel, AMD, or ARM.

Linux HAL Approach: `arch/` and Driver Model

Linux does not have a single "HAL module." Instead, abstraction is achieved through two orthogonal mechanisms:

Architecture-specific code (arch/): Every CPU architecture gets a directory: arch/x86/, arch/arm64/, arch/riscv/, etc. Each provides implementations of architecture-specific functions that the rest of the kernel calls through a fixed interface:

Abstraction	Architecture-independent call	x86-64 implementation
Context switch	`switch_to(prev, next, last)`	`arch/x86/include/asm/switch_to.h`
CPU idle	`arch_cpu_idle()`	`arch/x86/kernel/process.c`
TLB flush	`flush_tlb_mm()`	`arch/x86/mm/tlb.c`
Memory barrier	`smp_mb()`	`arch/x86/include/asm/barrier.h` → `mfence`
Atomic operations	`atomic_add()`	`arch/x86/include/asm/atomic.h` → `LOCK XADD`
I/O memory access	`readl()`, `writel()`	Memory-mapped I/O, volatile reads

The kernel build system selects the correct arch/ subtree based on ARCH= at compile time.

Driver model (drivers/base/): The Linux device model, introduced with kernel 2.6.0 (2003), unifies all devices into a struct device hierarchy. Every device is a node in the sysfs tree (/sys/). The model has three components:

  Bus (struct bus_type)
    - Knows how to enumerate devices on the bus
    - Matches devices to drivers
    Examples: PCI, USB, I2C, SPI, platform

  Device (struct device)
    - Represents one piece of hardware
    - Parent/child relationships (e.g., USB hub → USB device)
    - Power management state
    - sysfs representation

  Driver (struct device_driver)
    - Implements the device's functionality
    - id_table[] lists which devices it handles
    - .probe() called when matched to a device
    - .remove() called on hot-unplug

A PCI NIC registers itself on the PCI bus. The kernel scans the PCI bus, reads the device's Vendor ID and Device ID, and finds the matching driver. The driver's probe() function is called with the device object. From that point, the driver owns the device and can map its BARs (Base Address Registers), register interrupt handlers, and create network interface objects.

Windows HAL: `hal.dll`

Windows NT separates hardware abstraction more explicitly. hal.dll (Hardware Abstraction Layer DLL) is a kernel-mode component loaded by the boot loader before ntoskrnl.exe. It provides:

Interrupt controller access (PIC/APIC/SAPIC)
Bus enumeration (PCI, ISA)
Timer and clock services
DMA controller services
Processor synchronization primitives

Different HAL builds exist for different hardware configurations (e.g., ACPI HAL vs. MPS HAL). The rest of the NT kernel calls HAL functions rather than touching hardware directly. This design influenced Windows' portability: Windows NT ran on MIPS, Alpha, and PowerPC in its early years.

Modern Windows (Vista+) ships a single unified HAL that detects hardware at runtime rather than requiring different HAL builds.

Hardware Discovery: ACPI, Device Tree, PCI Enumeration

ACPI (Advanced Configuration and Power Interface)

ACPI is a standard maintained by UEFI Forum (originally Compaq, Intel, Microsoft, 1996). It provides: 1. Hardware discovery tables describing the platform topology 2. AML (ACPI Machine Language) bytecode that runs in a kernel-embedded interpreter, allowing platform-specific behavior without platform-specific kernel code 3. Power management interface for S0–S5 sleep states, CPU C-states, P-states

Key ACPI tables (stored in firmware, mapped into memory at boot):

Table	Full Name	Contents
RSDP	Root System Description Pointer	Points to RSDT/XSDT
RSDT/XSDT	Root/Extended System Description Table	Index of all other tables
DSDT	Differentiated System Description Table	AML code describing devices and their resources
SSDT	Secondary System Description Table	Additional AML, loaded dynamically
MADT	Multiple APIC Description Table	CPU cores, APIC IDs, interrupt routing
SRAT	System Resource Affinity Table	NUMA topology: which CPUs are near which memory
SLIT	System Locality Information Table	NUMA inter-node distances
MCFG	PCI Express Memory Mapped Config Space	PCIe config space base address
HPET	High Precision Event Timer	Timer hardware description
BERT	Boot Error Record Table	Firmware errors from previous boot

The kernel's ACPI subsystem (drivers/acpi/) parses these tables during boot. acpica/ contains the embedded ACPICA interpreter that executes AML bytecode. When you run cat /sys/firmware/acpi/tables/MADT, you get the raw binary of the MADT table.

ACPI Boot Discovery Flow:
  Firmware (UEFI/BIOS) → builds tables in memory
       |
  Bootloader (GRUB/shim) → passes table addresses to kernel via boot_params
       |
  Kernel early_acpi_boot_init() → maps RSDP, reads XSDT
       |
  acpi_table_init() → reads DSDT, SSDT, MADT, SRAT, etc.
       |
  acpi_bus_scan() → enumerates devices described in DSDT
       |
  Platform device objects created → driver probe() called

Device Tree (DT)

Device Tree is used on ARM, RISC-V, PowerPC, and other architectures where hardware is not self-describing (no PCI enumeration possible). It is a data structure (.dts source, compiled to .dtb binary blob) that describes the hardware topology.

// Example Device Tree fragment (simplified)
/ {
    compatible = "rpi,4-model-b", "brcm,bcm2711";

    cpus {
        cpu@0 {
            compatible = "arm,cortex-a72";
            reg = <0>;
            enable-method = "spin-table";
        };
    };

    uart0: serial@7e201000 {
        compatible = "brcm,bcm2835-pl011";
        reg = <0x7e201000 0x200>;
        interrupts = <2 25>;
        clocks = <&clk_uart>;
    };
};

The bootloader (U-Boot, UEFI) passes the .dtb blob address to the kernel. The kernel's OF (Open Firmware) / DT layer (drivers/of/) parses it and creates platform_device objects for each node. The driver for brcm,bcm2835-pl011 gets probed with the resource information from the DT node.

Linux's DT bindings are documented in Documentation/devicetree/bindings/. Every new ARM SoC requires a DT source file in arch/arm64/boot/dts/.

PCI Enumeration

PCI (and PCIe) is self-describing: the bus supports a standard configuration space accessible at fixed addresses. The kernel scans the bus at boot:

PCI Enumeration:
  pci_scan_root_bus() → scans bus 0
       |
  For each slot 0-31, function 0-7:
    Read Vendor ID (offset 0x00 in config space)
    If 0xFFFF → no device
    If valid → read Device ID, Class, BAR registers
    If bridge (Class 0x0604) → scan subordinate bus (recursive)
       |
  pci_register_device() → creates struct pci_dev
       |
  Bus match → driver probe() called

The PCI config space is accessed via ECAM (Enhanced Configuration Access Mechanism) on PCIe: memory-mapped at the base address from the MCFG ACPI table. On older x86, via I/O ports 0xCF8/0xCFC.

Abstraction for CPU: `arch_cpu_idle`, `switch_to`

arch_cpu_idle() (arch/x86/kernel/process.c): called by the scheduler when a CPU has no runnable tasks. On x86, this executes HLT (halt until next interrupt) or MWAIT/MONITOR for deeper sleep states. On ARM, it executes WFI (Wait For Interrupt).

switch_to(prev, next, last) (arch/x86/include/asm/switch_to.h): called by the scheduler to perform a context switch. It saves the outgoing process's registers (including the stack pointer into prev->thread.sp) and loads the incoming process's state. On x86-64, this saves/restores extended registers via XSAVE/XRSTOR and switches the stack. It is a few dozen assembly instructions — among the most performance-critical code in the kernel.

Abstraction for Memory: `pte_t`, `pgd_t`

Page table types are defined per-architecture: - pgd_t (Page Global Directory entry): include/asm-generic/pgtable-nopgd.h vs. arch/x86/include/asm/pgtable_types.h - pud_t, pmd_t, pte_t: similarly architecture-specific

The generic MM code uses pgd_val(), pte_val(), mk_pte(), etc. as accessor macros that compile to the appropriate operations for each architecture. A 64-bit x86 pte_t encodes the physical page frame number plus flags (Present, Read/Write, User/Supervisor, NX, etc.). A 32-bit ARM pte_t has a completely different bit layout. The accessor macros hide this.

Abstraction for Time: `clocksource`, `clockevent`

Linux's timekeeping is built on two abstractions (kernel/time/):

struct clocksource (include/linux/clocksource.h): a monotonically increasing hardware counter. Registered implementations include: - tsc: x86 Time Stamp Counter (RDTSC instruction) - hpet: High Precision Event Timer (memory-mapped hardware) - acpi_pm: ACPI PM Timer - arch_sys_counter: ARM Generic Timer (CNTPCT_EL0)

The kernel selects the best clocksource (highest frequency, lowest uncertainty) and uses it for ktime_get(), clock_gettime(), etc. The vDSO shares the current clocksource state with user space to enable syscall-free clock_gettime().

struct clock_event_device (include/linux/clockchips.h): a programmable timer that generates interrupts at specified future times. Used by the tick subsystem, hrtimer, and NO_HZ (tickless) mode. Implementations: LAPIC timer (per-CPU on x86), ARM Generic Timer, HPET.

Historical Context

The concept of hardware abstraction in operating systems traces to IBM's System/360 (1964), which defined a common instruction set and I/O interface across an entire product line with different physical implementations. IBM's goal — write software once for the entire 360 line — is exactly the HAL goal.

Digital Equipment Corporation's VMS (1977) for the VAX architecture had explicit HAL-like components for adapters and bus interfaces. The MIPS-based SGI IRIX (1988) and Sun's SPARC-based SunOS/Solaris had machine-dependent layers.

The modern notion of a formal HAL as a loadable component came with Windows NT (1993), designed explicitly for multi-architecture portability. The DEC Alpha, MIPS R4000, and x86 NT ports all used the same executive but different HAL DLLs.

Linux's approach emerged organically. The arch/ split was present from early days (the original Linux 0.01 was x86-only; arch/alpha/ was added in 1994). The unified driver model under drivers/base/ was a deliberate refactor by Greg Kroah-Hartman for Linux 2.6, replacing the ad-hoc bus-specific structures of 2.4.

ACPI was designed in 1996 specifically to abstract power management and hardware discovery away from OS-specific code. Before ACPI, each OS needed platform-specific code for sleep states, fan control, and battery management — a maintenance nightmare.

Production Examples

AWS Graviton: Amazon's ARM-based Graviton processors run the same Linux kernel as their x86 instances. The arch/arm64/ code provides the architecture-specific implementations; the scheduler, networking, and storage stacks are unchanged. AWS customers can switch instance types without recompiling application code (assuming it's dynamically linked against glibc for the target arch).

Android's HAL: Android introduced its own hardware abstraction layer (HIDL, then AIDL/VNDK) between the Android framework and vendor drivers. A Samsung driver for the camera sensor implements the Android Camera HAL interface (camera3_device_ops_t). The camera app calls the Android camera API, which calls through the HAL to the vendor driver. This allows Android OS updates to proceed without requiring every OEM to update every driver simultaneously — the HAL version is stable between major Android releases.

Linux on IBM Z (s390x): IBM mainframes run Linux. The arch/s390/ directory contains all the z/Architecture-specific code. Mainframe I/O uses a completely different model (Channel Command Words, DASD disks) from x86 PCIe, but the kernel VFS, MM, and scheduler are identical. The abstraction is so complete that the same PostgreSQL binary runs on both x86-64 servers and IBM mainframes.

Debugging Notes

Viewing ACPI tables:

# List all ACPI tables
ls /sys/firmware/acpi/tables/
# Dump a table (e.g., MADT)
cat /sys/firmware/acpi/tables/APIC | hexdump -C
# Decompile DSDT to AML source (requires iasl)
cp /sys/firmware/acpi/tables/DSDT /tmp/dsdt.dat
iasl -d /tmp/dsdt.dat  # produces dsdt.dsl

Device Tree inspection:

# On ARM/RISC-V systems
ls /proc/device-tree/
# DT entries appear in sysfs as well
ls /sys/firmware/devicetree/base/
# Human-readable DT (requires dtc)
dtc -I fs /sys/firmware/devicetree/base/ 2>/dev/null

PCI device enumeration:

lspci -vvv          # Full PCI device info
cat /proc/bus/pci/devices  # Raw PCI device list
ls /sys/bus/pci/devices/   # sysfs PCI tree
# Check a specific device's config space
setpci -s 00:1f.2 VENDOR_ID  # Read Vendor ID

Clocksource inspection:

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
# Should show: tsc hpet acpi_pm

Security Implications

ACPI AML as an attack surface: ACPI AML bytecode runs in the kernel at ring 0 during boot and during runtime ACPI events (lid open/close, thermal events). Malicious or buggy ACPI tables can compromise the kernel. CONFIG_ACPI_CUSTOM_DSDT allows overriding firmware ACPI tables, used by Linux distros to work around buggy firmware. Secure Boot does not validate ACPI table content.

Device Tree security: DTBs on embedded systems are sometimes modifiable by attackers with physical access. Since DT data is parsed by the kernel in ring 0, a carefully crafted malicious DTB could overflow buffers in the DT parsing code. CVE-2016-10229 and related bugs in Linux's DT handling have been found and fixed.

IOMMU as HAL security: IOMMU (Intel VT-d, AMD-Vi, ARM SMMU) is a hardware extension that limits which memory addresses a device's DMA engine can access. Without IOMMU, a compromised PCIe device could DMA-write to arbitrary physical memory, bypassing all software protections. The IOMMU is the hardware-level abstraction that enforces device isolation. Linux enables IOMMU via intel_iommu=on or iommu=force kernel parameters.

Performance Implications

Abstraction has a cost: Every readl()/writel() call for memory-mapped I/O goes through a volatile pointer dereference plus a compiler/hardware memory barrier. On x86, memory-mapped I/O to device registers is slower than main memory reads because the CPU cannot reorder or cache device register accesses. On ARM (weakly-ordered), explicit memory barriers (dsb()) are required.

ACPI interpreter overhead: ACPI events (thermal throttling, power button) execute AML bytecode in the kernel. This is interpreted bytecode running in ring 0. For high-frequency events, this is a bottleneck. Embedded systems often avoid ACPI entirely (using Device Tree) for this reason.

Clocksource selection performance: Using TSC as the clocksource gives nanosecond-resolution time reads in ~2ns (no memory accesses needed, just RDTSC). Falling back to acpi_pm (I/O port read) costs ~300ns. The kernel selects TSC when it is stable (constant TSC, invariant TSC flags in cpuid). Unstable TSC (some older multi-socket systems with TSC skew between sockets) forces fallback to slower clocksources.

Failure Modes and Real Incidents

Buggy ACPI tables causing kernel panics: Every year, multiple laptops ship with firmware containing AML bugs that cause Linux kernel panics during S3 suspend/resume, AC adapter events, or thermal management. Linux maintains a drivers/acpi/blacklist.c quirk table that disables or patches specific ACPI behaviors for known-buggy firmware versions. The fix is usually either a BIOS update or a kernel workaround.

Device Tree regression (2013, ARM Linux): A refactor of ARM board support code to use Device Tree instead of board files caused hundreds of ARM boards to stop booting in Linux 3.x. The DT bindings were incompatible across kernel versions, and updating the DT required matching kernel changes. This led to the "ARM DT ABI stability" policy: upstream DT bindings are stable.

IOMMU group passthrough misconfiguration (KVM): PCIe devices in the same IOMMU group must be passed through to the same VM (or kept in the host). Users who ignored IOMMU groups when using VFIO passthrough experienced memory corruption because two devices in the same group could DMA into each other's memory. The kernel enforces this with group-level IOMMU API (iommu_group_*).

Modern Usage

eBPF and hardware abstraction: eBPF programs can attach to hardware events (performance counters via perf_event, tracepoints that fire on hardware interrupts) without knowing the specific hardware. The kernel abstracts the PMU (Performance Monitoring Unit) through struct perf_event_attr, and eBPF reads counter values through the abstraction.

Rust in arch/ code: The Rust for Linux project (rust/) is beginning to provide Rust abstractions over the kernel's C abstractions. For example, rust/kernel/io_mem.rs provides Rust wrappers for readl/writel. This adds a third layer of abstraction (Rust type system → kernel C API → hardware) but with memory safety guarantees.

CXL (Compute Express Link): CXL is a new bus standard (PCIe 5.0-based) for memory expansion, memory pooling between CPUs, and accelerator memory sharing. Linux 5.12+ includes drivers/cxl/ — a new driver subsystem. CXL devices require new hardware abstraction at the memory management level, since CXL memory can appear as regular DRAM, as a cache, or as persistent memory depending on configuration.

Future Directions

Unified driver frameworks: Projects like io-pgtable (unified IOMMU page table abstraction) and regmap (unified register map abstraction for buses) continue the trend of abstracting entire bus protocols rather than individual device characteristics.
Hardware discovery for heterogeneous computing: As SoCs add NPUs, DSPs, and custom accelerators, the DT and ACPI models need extensions. ACPI 6.5 adds new tables for CXL. Linux's dma-buf and dma-heap frameworks abstract memory sharing between CPU and accelerators.
P2P (Peer-to-Peer) DMA: PCIe P2P DMA (GPU directly to NVMe, bypassing host memory) breaks the assumption that the CPU mediates all data movement. New kernel abstractions in mm/ and drivers/pci/p2pdma.c support this, but it remains an area of active development.

Exercises

On a Linux system with ACPI, dump the DSDT table using cat /sys/firmware/acpi/tables/DSDT > /tmp/dsdt.dat && iasl -d /tmp/dsdt.dat. Open the resulting .dsl file. Find the _PRT (PCI Routing Table) method or a device _STA (Status) method. Explain what it does in plain English.
Run lspci -t to see the PCI device tree. Identify the root complex (bus 0), any PCI bridges (bus controllers), and leaf devices. Draw a tree diagram. Now run cat /sys/bus/pci/devices/0000:00:00.0/config | hexdump -C | head -2 and identify the Vendor ID and Device ID bytes (bytes 0-3).
Write a minimal Linux kernel module that reads and logs the current clocksource name and the current ktime_get() value. Use current_clocksource->name (via clocksource_get_by_name) and ktime_to_ns(ktime_get()). What is the clocksource in use on your system?
On an ARM device (or VM), find the Device Tree blob at /sys/firmware/devicetree/base/. Navigate the directory tree and find the compatible string for the CPU. How does this string get matched to a driver in the kernel?
Read Documentation/driver-api/driver-model/overview.rst in the Linux kernel source. Describe the lifecycle of a device: from the moment it appears on the bus to the moment its driver's probe() function is called. What data structures are involved at each step?

References

ACPI Specification 6.5: https://uefi.org/specifications
Device Tree Specification 0.3: https://www.devicetree.org/specifications/
PCI Express Base Specification 5.0: https://pcisig.com
Linux kernel source: arch/x86/, arch/arm64/, drivers/acpi/, drivers/of/, drivers/base/, kernel/time/
Linux kernel documentation: Documentation/driver-api/, Documentation/firmware-guide/acpi/
Jonathan Corbet, Alessandro Rubini, Greg Kroah-Hartman, Linux Device Drivers, 3rd ed. (free at https://lwn.net/Kernel/LDD3/)
Greg Kroah-Hartman, "The Linux Driver Model", Ottawa Linux Symposium 2003
LWN.net ACPI overview: https://lwn.net/Articles/574439/
CXL specification: https://www.computeexpresslink.org