Faculty of Computer Science Institute for System Architecture, Operating Systems Group Hardware and Device Drivers Björn Döbel Dresden, 2007-11-13
Outline • What's so different about device drivers? • Hardware access • Writing device drivers on L4 – Reuse of legacy drivers • Device virtualization • Device drivers and security TU Dresden, 2007-11-13 Device Drivers Slide 2 von 45
Why are Drivers so hard? • Typically need kernel privileges because of – Interrupt handling – Hardware access • data transfer • config registers • firmware – Special memory management – DMA • physical adresses • DMA vs. paging – Synchronization & Timing mechanisms • complex state machines • Unsexy solution: keep drivers in the kernel TU Dresden, 2007-11-13 Device Drivers Slide 3 von 45
Idea: User-level Drivers • Isolate components – device drivers (disk, network, graphic, USB cruise missiles, ...) – stacks (TCP/IP, file systems, ...) • Separate address spaces for each • More robust components – Crashing network device does not hurt the file system • HW multiplexing TU Dresden, 2007-11-13 Device Drivers Slide 4 von 45
System Layout • Devices connected by busses (USB, PCI, PCIx) • Host chipset (DMA logic, IRQ controller) connects busses and CPU PCI Network Card System PCI Bus Bus Controller CPU Chipset Sound Card PCI Bus Memory USB PCI Bridge Bus Bus USB Host PCI Controller Memory Bus PCI Wifi USB Coffee Maker TU Dresden, 2007-11-13 Device Drivers Slide 5 von 45
Real World Example Intel 925x Chipset (source: http://www.intel.com) TU Dresden, 2007-11-13 Device Drivers Slide 6 von 45
Buses and Devices • A long long time ago: – device architecture hard-coded • Problem: more and more devices – need means of dynamic device discovery • Probing: try out every driver to see if it works • Plug&Play: first try of dynamic system description – device manufacturers provide unique IDs • PCI: dedicated config space • ACPI: system description without relying on underlying bus/chipset TU Dresden, 2007-11-13 Device Drivers Slide 7 von 45
Buses: PCI • Peripheral Component Interconnect • Hierarchy of busses, devices and functions • Configuration via I/O ports • Address + data register (0xcf8-0xcff) Chipset PCI-to-PCI Device 1 Device 2 Bridge Device 4 Device 3 Func 1 Func 2 TU Dresden, 2007-11-13 Device Drivers Slide 8 von 45
Buses: PCI (2) • PCI config space • 64 byte header – Busmaster DMA – Interrupt line – I/O port regions – I/O memory regions – + 192 byte additional space • must be provided by every device function • must be managed to separate device drivers TU Dresden, 2007-11-13 Device Drivers Slide 9 von 45
Buses: USB • Intel, 1996 • One bus to rule them all? – Firewire has always been faster • Tree of devices – root = Host Controller (UHCI, OHCI, EHCI) – Device drivers use HC to communicate with their device via USB Request Blocks (URBs) – USB is a serial bus • HC serializes URBs • Wide range of device classes (input, storage, peripherals, ...) • Device classes allow generic drivers TU Dresden, 2007-11-13 Device Drivers Slide 10 von 45
Interrupts • Signal device state change • Programmable Interrupt Controller (PIC, APIC) – map HW IRQs to CPU's IRQ lines – prioritize interrupts System PCI Bus Bus CPU PIC INT INT A INT B IDE NET USB INT C Chipset Memory Bus Memory TU Dresden, 2007-11-13 Device Drivers Slide 11 von 45
Interrupts (2) • Handling interrupts involves – examine / manipulate device – program PIC • acknowledge/mask/unmask interrupts System PCI Bus Bus CPU PIC INT INT A INT B IDE NET USB INT C Chipset Memory Bus Memory TU Dresden, 2007-11-13 Device Drivers Slide 12 von 45
L4: Interrupt handling • IRQs mapped to IPC • threads call ipc_recv() at a dedicated interrupt kernel thread • exactly one thread can wait for exactly one interrupt – no IRQ sharing support in the kernel Device Driver l4_ipc_receive(irq_id,…) Kernel Fiasco Microkernel Software Hardware CPU Chipset Device TU Dresden, 2007-11-13 Device Drivers Slide 13 von 45
L4: Problems with interrupts • IRQ lines are limited – IRQ sharing is needed • Multiple user-level drivers need to access PIC – locking – we don't want to trust our drivers' • IRQ priorities vs. thread priorities -> priority inversion • IRQs are a resource and must be managed! • Some drivers need to disable interrupts. TU Dresden, 2007-11-13 Device Drivers Slide 14 von 45
IRQ management: Omega0 • Omega0 – Hides all interrupt logic from device drivers • one interface for all architectures – Provides sharing of interrupts – Provides interrupt hand-over to another thread – Prevents priority inversion – Implementation may require a user-level server, depending on the kernel APIs TU Dresden, 2007-11-13 Device Drivers Slide 15 von 45
Omega0 layout • x86: user-level management server • ack IRQs immediately at PIC -> prevent priority inversion Device Device Driver 1 Driver 2 IRQ A IRQ B Omega0 Kernel IRQ A IRQ B Fiasco Microkernel Software Hardware CPU PIC INT INT A Device 1 Device 2 INT B Chipset TU Dresden, 2007-11-13 Device Drivers Slide 16 von 45
Omega0: Multiple IRQs per Thread • e.g.: one IDE driver for both IDE ports Device Driver IRQ A IRQ B Omega0 Kernel IRQ A IRQ B Fiasco Microkernel Software Hardware CPU PIC INT INT A Device 1 Device 2 INT B Chipset TU Dresden, 2007-11-13 Device Drivers Slide 17 von 45
Omega0: IRQ sharing • e.g., USB storage and USB missile launcher on the same IRQ line Device Device Driver 1 Driver 2 IRQ A Omega0 Kernel IRQ A Fiasco Microkernel Software Hardware CPU PIC INT INT A Device 1 Device 2 Chipset TU Dresden, 2007-11-13 Device Drivers Slide 18 von 45
Disabling interrupts • CLI – only with IO Privilege Level (IOPL) 3 • Should not be allowed for every user-level driver – unstrusted drivers – security risk • Observation: drivers often don't need to disable IRQs globally, but only access to their own IRQ – in this case dropping pending IRQs at omega0 is enough, no need to mingle with others TU Dresden, 2007-11-13 Device Drivers Slide 19 von 45
Hardware access • Apart from IRQs, drivers need to access device hardware – data transfer – configuration • Approaches – memory-mapped I/O – I/O ports (x86-specific) TU Dresden, 2007-11-13 Device Drivers Slide 20 von 45
I/O ports • x86-specific feature • I/O ports define own I/O address space – Each device uses its own area within this address space • Special instruction to access I/O ports – in / out: I/O read / write – Example: read byte from serial port mov $0x3f8, %edx in (%dx), %al • Everyone who can access I/O ports of a device can manipulate the device • Need to restrict I/O port access – Allow device drivers access to I/O ports used by its device only TU Dresden, 2007-11-13 Device Drivers Slide 21 von 45
I/O Bitmap • Tasks have I/O privilige level (IOPL) • If IOPL > current PL, all accesses are allowed (kernel mode) 1111111111011011 #0xfff0 • Else: I/O bitmap is checked 1111111111111111 #0xffe0 • 1 bit per I/O port . . . – 65536 ports -> 8kB 1111111111111111 #0x0000 • Controls port access (0 == ok, 1 == GPF) • L4: per-task I/O bitmap I/O Map Base Address – Switched during task switch – Allows per-task grant/deny of I/O port access TSS TU Dresden, 2007-11-13 Device Drivers Slide 22 von 45
I/O Flexpages • Reuse kernel's map/grant mechanism for mapping I/O port rights -> I/O flexpages • Kernel detects type of flexpage and acts accordingly • Task with all I/O ports mapped is raised to IOPL 3 Map/Grant Base Port log 2 #Ports 1111 0000 0 L4.Fiasco I/O flexpage format TU Dresden, 2007-11-13 Device Drivers Slide 23 von 45
I/O Memory • Devices often contain on-chip memory (NICs, graphcis cards, ...) • Instead of accessing through I/O ports, drivers can map this memory into their address space just like normal RAM – no need for special instructions – increased flexibility by using underlying virtual memory management Driver Memory Kernel Fiasco Microkernel Software Hardware CPU Chipset Memory Device Memoy TU Dresden, 2007-11-13 Device Drivers Slide 24 von 45
I/O memory (2) • Device memory looks just like phys. memory • Chipset needs to – map I/O memory to exclusive address ranges – distinguish physical and I/O memory access Driver Kernel Fiasco Microkernel Software Hardware CPU Chipset Memory Device Memory TU Dresden, 2007-11-13 Device Drivers Slide 25 von 45
I/O memory in L4 • Like all memory, I/O memory is owned by sigma0 • Sigma0 implements protocol to request I/O memory pages • Abstraction: Dataspaces containing I/O memory Driver 1 Driver 2 Sigma0 Kernel Fiasco Microkernel Software Hardware CPU Chipset Device 1 Device 2 Memory TU Dresden, 2007-11-13 Device Drivers Slide 26 von 45
Recommend
More recommend
