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