Windows Internals for Linux Kernel Developers

kTLV Windows Internals for Linux Kernel Developers @goldshtn
kTLV https://s.sashag.net/ktlv0316 @goldshtn
Sasha Goldshtein
@goldshtn
Windows Internals for
Linux Kernel Developers

In This Talk…
• Windows history and design goals
• Processes, threads, virtual memory
• Interrupts, IRQLs, DPC, APC, system threads
• IRPs, driver structure
• Debugging and tracing, poking into the system

The Windows Family Tree
NT CE DOS
2000
XP
Vista
8RT
10IoT Core Nano
Server
Core
WM 6
WP 7
WP 8
PoS
💀
98
ME
💀
Xbox
One
XP
Embedded
bi-annual visit for the holidays
Surface
Hub
Holo
Lens
WM 10
WM 5

Windows Design Goals and Architecture
• Portability across hardware
platforms
• Multitasking, multiprocessing,
SMP operating system
• Fully preemptable kernel
• Virtual memory
• User- and role-level security,
auditing, access control
• Modular, component-based OS
• Platform for distributed
computing
• Backwards compatibility for
applications and drivers
• Supports multiple API “flavors”
or subsystems (POSIX, OS/2,
SUA, LXSS)
• Moving towards a micro-kernel

HAL
Kernel
Executive
Kernel-Mode Drivers Win32k.sys
Ntdll.dll
Subsystem DLLs
Applications, Services, User-Mode Drivers

Windows Programming Interfaces
• The Win32 API – a flat collection of C functions and structures that
can be called from C, C++, .NET, Python, Perl, etc.
• Names are clear and descriptive, e.g.: ReleaseMutex,
CoMarshalInterThreadInterfaceInStream,
AccessCheckByTypeResultListAndAuditAlarmByHandle
• As of Windows 8, a modern interface called Windows Runtime or
Universal Windows Platform provides a COM-based abstraction of
parts of Win32, accessible from C++, .NET, and JavaScript

Processes and Threads
Windows Processes
• Container for code execution,
but not schedulable
• Private virtual address space
• Handle table for kernel objects
• Isolation and security boundary
• Relatively expensive to create
• Various IPC mechanisms: named
pipes, sockets, mailboxes, etc.
Windows Threads
• Execution path through
program, schedulable
• All resources are shared within
the parent process
• Private UM and KM stack
• Relatively cheap to create

Jobs
• Windows does not maintain a meaningful process tree (although
parent pid is recorded)
• Processes may be assigned to a job
• Jobs can be controlled as a unit (e.g., wait, terminate)
• Jobs can be assigned limits (quotas)

Thread Scheduling
• Threads are scheduled according to priority (0-31) and CPU affinity
• Priorities are not weights; the highest-priority thread always runs
• Using “realtime” priorities (16-31) requires a special privilege,
because they can directly compete with important system threads
• Thread quantum is configured globally (ranging from 30ms to 180ms)
• Tickless kernel since Windows 8
• Special priority and quantum boosts in some scenarios
• SMP scheduling based on processor-local queues and work stealing,
NUMA and HyperThreading awareness

Synchronization
• Large variety of user-mode synchronization mechanisms: mutex,
semaphore, event, condition variable, one-time init, reader-writer
lock, WaitOnAddress (a la futex)
• Some kernel-only synchronization mechanisms: ERESOURCE, fast
mutex, gate, spinlock, queued (FIFO) spinlocks

Virtual Memory
• 32-bit: 4GB address space, 1-2GB reserved for kernel
• 64-bit: 256TB address space, 128TB reserved for kernel
• Memory is reserved and then committed, no over-commit, physical
mapping only on first access
• Paging out based on age, size, process memory priority
• Services for protecting memory (RWX), sharing memory, mapping
files into memory, locking physical pages, and more
• User-mode heap layer in ntdll.dll, kernel-mode pools (paged and non-
paged), lookaside lists

Interrupts and Kernel Processing
• Support for both classic interrupts and MSI (since Windows Vista)
• Interrupt priorities (IRQL) 0-15 or 0-31 (determined by PnP manager)
• Waiting (or paging) is not allowed at IRQL 2+
• Deferred work goes into DPC (IRQL 2 or priority 31 thread) which can
be delivered to current or other processor
• Context-sensitive work goes into APC (IRQL 1)
• Can also use system threads, kernel thread pool

Windows I/O Concepts
• Applications perform I/O operations on file handles, which are
internally translated to _FILE_OBJECT
• File objects are created by drivers and associated with
_DEVICE_OBJECT (that has a pointer to _DRIVER_OBJECT)
• The I/O manager manages I/O requests using IRPs that are routed
between drivers; the IRP knows which driver is currently handling it
• Any I/O can be synchronous or asynchronous – it’s just a flag that tells
the I/O manager whether to block the calling thread
• Most I/Os can be prioritized by the calling thread
• Most disk and network I/Os are cancelable

I/O Request Flow
NtWriteFile
determines target device
from _FILE_OBJECT,
creates and routes the
_IRP
Ntfs.sys
Application calls WriteFile(hFile, …)
Volmgr.sys
Vendorzzz.sys

Plug and Play
• At boot time, the Plug and Play (PnP) manager creates a device
enumeration tree
• For each bus (PCIe, 1394, USB, etc.), a bus driver is responsible for
detecting and configuring new hardware and its power state
• Buses can be nested
• Resources such as IRQs, DMA channels, I/O memory ranges are
arbitrated by the PnP manager
• Driver software can be installed on-demand using a user-mode
component that optionally talks to Windows Update

Driver Frameworks
• Non-software-only drivers adhere to the Windows Driver Model
(WDM), which has bus drivers, function drivers, and filter drivers
• A driver is a collection of callback functions (DriverEntry, AddDevice,
DispatchNnn, Isr, DpcForIsr, …)
• Windows Driver Framework, introduced in Windows Vista, provides a
more object-oriented wrapper on top of WDM
• Also introduces user-mode drivers (UMDF) originally based on COM
• In UMDF 2.0, APIs for user-mode and kernel-mode drivers are
identical; in theory, can port a kernel-mode driver to user-mode

Debugging and Tracing
• A kernel debugger is built into the kernel and Windows boot process
• Can debug over serial port, USB, 1394, Ethernet (as of Windows 8)
• Local kernel debugging enables view-only, no breakpoint kernel
debugging on a single machine (Livekd emulates a memory dump)
• Crash dumps are generated by default when the system fails, can be
analyzed later and/or reported to Microsoft (and then vendor)
• ETW (Event Tracing for Windows) is a tracepoint-like framework for
tracing – performance and general diagnostics
• Windows Performance Toolkit has ETW recording and analysis tools

Thank You!
Sasha Goldshtein
@goldshtn

Windows Internals for Linux Kernel Developers

More Related Content

What's hot

Viewers also liked

Similar to Windows Internals for Linux Kernel Developers

More from Kernel TLV

Recently uploaded

Windows Internals for Linux Kernel Developers

Editor's Notes