Microsoft Windows Kernel Architecture Flashcards
Operating systems are fundamentally an abstraction layer between users and physical components:
- Simplification of interactions
- Ability to replace components, at times including emulation
- Most modern systems provide different types of multiplexing and protective mechanisms
- Requirements vary considerably: General-purpose systems value responsive multi-programming, transaction processing can be accomplished with batch programming and real-time systems require provable response-time boundaries
Core Operating System Functions - Scheduling:
- Prioritisation, fairness
* Deadlock avoidance
Core Operating System Functions - Memory Management:
- Protection of concurrent programs, self-protection
* Virtual memory abstraction
Core Operating System Functions - Storage Management:
Persistent storage provisioning in a consistent abstraction
Core Operating System Functions - I/O Management:
- Abstraction of hardware properties
* Synchronization and concurrency management
Most modern operating systems use a modular or layered construction. Privileges are also used in different modes or rings, Windows uses…
Ring based approach, but with only two rings active. Legacy of the original multi-platform design : MIPS, PPC. Only supported two modes. Important ramifications for security
While subsequent generations have embellished the architecture of Windows NT…
The current generation (Win8) takes a step back an uses a more minimal (MinWin) core. Several subsystems have since been added, but some also have been depreciated
The Universal Windows Platform app mechanism introduces a parallel user mode layer; on desktop platforms the Win32 layer will be retained. UAP is a…
Superset of the earlier Windows 8, RT and WinRT user-mode runtime environment based in part of the Metro interface. UAP Applications are sandboxed and restricted to only a subset of the Win32 and COM APIs either via a Windows Runtime component or the Platform Invocation Services
The Hardware Abstraction Layer (HAL) provides an abstraction to upper kernel layers that insulates particulars of given hardware platforms, primarily:
- Multi-processor, multi-core and independent execution units
- Interrupt controllers
- Low-level I/O interfaces
Layered between the HAL and Executive is the Kernel, which was the core of the original microkernel design:
Layered between the HAL and Executive is the Kernel, which was the core of the original microkernel design:
Executive Components - Object Manager:
Windows uses objects to encapsulate most resources, their creation, destruction, control and protection is handled through the Object Manager, which also provides name spaces
Executive Components - Objects are divided into Administrative Elements:
Name, handle and reference count, type information
Executive Components - Kernel Objects:
Owned by the kernel
Executive Components - Executive Objects:
Owned by the executive, if it is not an outright kernel object
Executive Components - Configuration Manager:
Responsible for implementation and management of Registry database
Executive Components - Advanced Local Procedure Call:
Message passing interface between client and server processes, also used as local transport for RPC calls
Executive Components - I/O Manager:
Provides device-independent I/O and is the interface to layered device driver
Executive Components - Cache Manager:
Retains recently referenced file I/O in memory and manages deferred writing of cache content, cache replacement. Tied closely to the Memory Manager
Executive Components - Process Manager:
Creates and terminates threads and processes, mainly as a layered service on top of the microkernel
Executive Components - Memory Manager:
Implements Virtual Memory Management, including providing virtual address spaces, fie mapping, locking of physical memory and shared memory
Executive Components - Power Manager:
Coordinates power events and generates notifications to device drivers and can put CPU to sleep in idle conditions
Executive Components - Plug & Play:
Determines types of drivers required to support devices and loads installs driver packages. Also assigns resources and must handle system notifications of device addition or removal
Executive Components - System Reference Monitor:
Enforces security policies on the local computer system, performs run-time object protection and auditing, communicates with user-mode components
Executive Components - Kernel-Mode Driver Contains Windows Subsystems - GDI
Abstraction layer for graphics interfaces (2D)
Executive Components - Kernel-Mode Driver Contains Windows Subsystems - DXG:
Provides a wrapper and access interface for other services via a common interface (DDI)
Executive Components - Kernel-Mode Driver Contains Windows Subsystems - USER:
Provides window manager and graphics services including keyboard and mouse, messaging services
Executive Components - Hypervisor Library:
Kernel support for Hyper-V virtualisation and operating in a client partition of a virtual machine environment
Executive Components - Kernel Transaction Manager:
Provides a common 2-phase commit protocol for resource managers including transactional registry and transactional NTFS
Executive Components - Kernel Debugger Library:
Provides access to kernel debuggers using KD protocol layers
Executive Components - Errata Manager:
Contains workarounds for non-standard hardware, known errors, or non-compliant hardware components
The I/O subsystem must meet multiple objectives:
- Insulate shareable resources and provide abstractions
- Dynamic loading and unloading of device drivers
- Providing layered device drivers for extensions and modifications to driver behaviour
- Supporting installable file systems
Microsoft Windows I/O Components - I/O Manager:
Orchestrates I/O processing and connects application and kernel components
Microsoft Windows I/O Components - Device Drivers:
Provides I/O interfaces for a particular device or class of devices in case of layered drivers. May also only provide aspects to other drivers
Microsoft Windows I/O Components - PnP Manager:
Allocates resources, monitors and manages addition and removal devices. This is performed in coordination with the I/O Manager and bus drivers for gives types of interfaces
Microsoft Windows I/O Components - Power Manager:
Handles power-state transitions, individual power states must be realised by device drivers
Microsoft Windows I/O Components - Windows Management Instrumentation (WMI):
The Windows Management Instrumentation (WMI), also referred to as the Windows Driver Model (WDM) support, provides an interface with the user-mode WMI service
Microsoft Windows I/O Components - Registry:
The registry holds a database for basic device data and individual driver configurations
Microsoft Windows I/O Components - Configuration Files:
Driver installation files (.INF files) are scripts describing specific devices
Microsoft Windows I/O Components - HAL:
The HAL provides abstractions for I/O mechanisms and is the bus driver “root” for all devices and interfaces on the mainboard
I/O Request Flow:
User-Mode API > I/O System API > Kernel-Mode Device Drivers > HAL I/O Access Routines > I/O Ports and Registers
User-Mode Device Driver - Virtual Device Drivers:
VDDs are only for 16-bit legacy systems are no longer supported on 64-bit platforms
User-Mode Device Driver - Printer Drivers:
Responsible for translating device-independent graphics commands to device-specific ones. These are typically forwarded to kernel-mode port drivers
User-Mode Device Driver - UMDF:
The User-Mode Driver Framework allows drivers to be hosted in used mode
Kernel-Mode Device Driver - File System Drivers:
This type of layered driver accepts I/O requests for files and translates them into mass-storage or network driver requests, potentially across multiple layers
Kernel-Mode Device Driver - Plug and Play Drivers:
These are aware of PnP and interoperate with the PnP and Power Manager
Kernel-Mode Device Driver - Non-PnP Drivers:
May either be legacy drivers or ones that are not linked to specific hardware such as when extending kernel functionalities
Kernel-Mode Device Driver - Windows Display Driver Model (WDDM):
The Windows Display Driver Model introduced with Vista and changed in each version since
Windows Driver Model - Bus Drivers:
These Manage physical or logical buses and are responsible for handling device additions and removals together with the PnP manager, power setting for the bus and communicating with attached devices
Windows Driver Model - Function Drivers:
These handle the actual devices as presented through the PnP manager and bus driver and provide the operating system with an interface to device functions
Windows Driver Model - Filter Drivers:
These can be logically layered above or below function drivers and modify or extend behaviour of a device or another device driver
Windows Driver Model - Miniport Drivers:
Provide a mapping of generic I/O to a port into requests specific to a device
Simple Layering Example (File Access):
1) User-mode component places call: NtWriteFile(file_handle, buffer)
2) System services translate call into I/O Manager requests
3) I/O Manager instructs file system driver(FSD) to write at specific offset into a file
4) FSD translates file-relative to volume-relative offsets and calls next driver via I/O Manager
5) I/O Manager calls disk driver to write data at specified volume-relative offset
6) Disk driver translates volume-relative offset into disk-relative offset and transfers data
Display drivers have been dealt with as a special case since Windows NT 4.0 resulting in a number of legacy interfaces:
- With increasing graphics processing unit (GPU) power, off-loading of computations and rapid memory access became more important
- The WDDM differs from the regular WDM and has also undergone significant changes, including in to WDDM 2.0 in Windows 10 introducing GPU virtual addressing - previously GPUs were able to access main memory directly, placing a burden on the host to manage virtual memory
- Code on the GUP running in physical rather than virtual address mode may independently read and modify arbitrary memory locations
One design objective for Windows was to consolidate system and user configuration data into a common database format…
This is separated into multiple databases based on usage
Some applications may still use custom configuration file formats…
- These can come in different formats, the legacy .INI format is merely one of them: Unstructured and un-typed key/value pairs
- Others may include separate or proprietary database formats, RDF, plain or customised XML files or relational databases
Registry Database - Keys:
Can be considered similar to directories in file systems and may themselves contain subkeys. Top-level keys are referred to as root keys
Registry Database - Values:
Can be considered comparable to files
Registry Sections and Hives - HKEY_CURRENT_USER:
Data associated with the currently logged-on user. This is stored in a separate file (NTUSER.DAT or USRCLASS.DAT) and can be used in a roaming profile
Registry Sections and Hives - HKEY_CLASSES_ROOT:
File associations and Component Object Model (COM) object registration information. This information is merged from machine- and user-specific data
Registry Sections and Hives - HKEY_LOCAL_MACHINE:
System-related information for the local machine (authentication or SAM, security, software and system keys; hardware-related keys are generated dynamically and are not stored in the database)
Registry Sections and Hives - HKEY_USERS:
Data for all local user accounts
Registry Sections and Hives - HKEY_PERFORMANCE_DATA:
Performance information
Registry Sections and Hives - HKEY_CURRENT_CONFIG:
Volatile information generated at boot time and amended during run-time
In networked Windows environments, user authentication and data as well as access control is often maintained via Active Directory…
This is an extended version of the LDAP protocol. A number of further services (Kerberos authentication, name resolution, network administration) are also supported. Organisation is into domains and forests and can replicate across sites and trust hierarchies
The interacts with local configuration databases and the local authentication and Security Account Manager (SAM) subsystem. Access and changes to a local registry can also be…
Constrained by Group Policy entries among other attributes. This is typically used in larger enterprise environments
