"Introduction to writing Device Drivers for Windows" Speaking: Ben Bernstein, Microsoft slides available at http://webcourse.cs.technion.ac.il/234120/Winter2003-2004/ho/WCFiles/drivers_ppt.ps.zip, http://webcourse.cs.technion.ac.il/234120/Winter2003-2004/ho/WCFiles/drivers_doc.ps.zip These notes represent my personal opinion and interpretations of the material presented. In particular, anything that is prefixed by 'ed:' is my musings. For mistakes, blame me. I will write up a more coherent summary of the talk as soon as time permits (Real Soon Now(TM)). ed: 116 people present - lots of marketing stuff, what is his background, what do they do in Microsoft, projects they are guiding in the Technion. - one project sounds exactly like a windows port of syscalltrack - Device Drivers - why do we need them - the only way to connect IO devices - the only way to inject code into the windows kernel - doing stuff in the utmost low level firewall, av, ids - why I hate them - mostly undocumented, very few web resources - very primitive dev tools - speaks a lot in favor of IDEs, then mentions there's no IDE for drivers development - no GUI, cannot impress anyone - the kernel never forgives my bugs - so much cryptic knowledge we cannot cover the whole subject in two hours the slides are very austere, no fleshy power point animations (kudos) - Windows IO - uses the same mechanism for communicating with files, and communicating with devices - CreateFile - CloseHandle - WriteFile - ReadFile "you can use CreateFile instead of fopen() and it would still work" (ed. except it would no longer be portable) "the same APIs are used to talk with devices" (ed. never mentions "device files") - DeviceControl (exactly like ioctl()) ed: so far, no code shown. "DeviceControl has both an input and output buffer" Shows code! an example of a main function, opening, writing, ioctl() and close on a device file. No error checking... ed: what an ugly naming convention for device files "\\.\devname" - Calling DeviceIOControl ed: contrary the my expectations, the lecture assumes background in Linux programming(!) and no Windows programming(!) background. - NtDll - all of the system calls (doesn't use the term "system calls") - mentions yet again something like strace / system calls - when moving into kernel space, the stack is explicitly passed in edx?! - Windows IO - IRPs - every IO request from a file or a device gets to the kernel - the IO manager - the IO manager creates an IRP and dispatches it to the proper driver(s) of the device - the driver may make the request pending and answer it after a while - the driver may decide to pass the IRP to another driver ed: short digression into asynch. IO "the IO manager decides whether a call is synch. or asynch - the driver only knows to handle synch. IO" - Device Driver Code - A code that runs inside the windows kernel - C/C+/C++ (C+ is "C with some C++ features") - Device Driver Code - the smallest driver in the world ("IN", "OUT", in function parameters) - doesn't actually do anything ed: no printf in the kernel... (none in AIX either) (something call KdPrint that prints to the debugger) - Few Question (MS driver rules) - You have to order the SDK (delivery is free (ddk is free?)) - Compiling - just BUILD.EXE - no Makefile, just dirs and sources (Makefile replacement?) - BDG/FRE dos build environment (debug and non debug) - The .SYS files - export and import, driver entry is the entry point "one driver can call another driver's entry points" - curious: all functions, or just those that are exported? - Weird types - UNICODE_STRING, NTSTATUS, some undocumented ed: does the NT kernel use unicode internally? - BREAK - ed: pace shifts up, more complex examples - DriverEntry - The DriverEntry RegistryPath parameter - Points to the registry - The registry info is usually created by an INF file - The DriverObject parameter - used for passing the function pointers for the driver's operations - Device Driver - Initializing Callbacks ed: why both MyCleanup and MyClose (answer: MyCleanup - called when the last handle to the device is deleted) - MyPnpAddDevice for plug and play support - Device Driver - Dispatch Functions - Dispatch Functions - All in the form of NTSTATUS MyDispatchFunc(IN PDEVICE_OBJECT ..) - sysinternals FileMon example - Device Driver - Dispatch Functions - What can the driver functions do? call the kernel APIs - Executive - Memory manager - Rtl - FsRtl - Io - Hal (hardware abstraction layer) - Zw (File and registry) - Ke (general kernel) - Use DMA to talk to the device - Queue the IRP for later completion - Device Driver - Interrupts - Interrupts - the way the actual device dispatches the OS - In order to register to a certain Interrupt one uses the IoConnectInterrupt API - Easier with PNP support - A completion function is passed to IoConnectInterrupt - Device Driver - Interrupts example of an ISR - what is a DPC ed: a bottom half mechanism of some sort (does not go into details) - DPC - Deferred Procedure Call ed: drivers code sucks in general. Some things are universal :-) - Interrupt example - Other Important Issues (that we have not quite covered) - IRQL & Interrupts (IRQ level (priorities)) ed: driver memory comes from "non paged pool" - to avoid a page fault in driver code (how does Linux handle page faults inside interrupts? look at the fixmap table and the page fault code) - DDK API calls and IRQL - class filter driver - spin locks - noon paged pool - WinDBG/SoftIce - fast IO dispatch - IFS - filter drivers - PNP dispatch functions - the slides appear on the course's site