Kernel Enhancements For Windows Server Longhorn

1. Kernel Enhancements For Windows Server Longhorn Mike TrickerProgram ManagerWindows Core Platform ArchitectureMicrosoft Corporation

2. Agenda • Kernel enhancements for Windows Server Codename “Longhorn” • Pointers to other relevant sessions and material • Future ideas we’re considering • Call to action

3. Moving To 64-bit OnlyFuture releases of Windows Server • Windows Server Longhorn is planned tobe the last 32-bit release of Windows Server • Except for Service Packs and QFEs of course • Windows Server Longhorn R2 is planned to be 64-bit only • We expect that all Enterprise Server-class processors on sale in 2007/8 will be 64-bit capable • This will affect your drivers and your hardware

4. Kernel Driver Signing • Unsigned 64-bit kernel drivers will not loadon Windows Vista or Windows Server Longhorn • The unsigned driver pop-up is no longer a “get out of jail free” card • From now on they must be signed by a recognized signing authority • See this link for more details • http://www.microsoft.com/whdc/system/platform/64bit/kmsigningFAQ.mspx • For more details please see the slides for the session • Introduction to the WDK: A Comprehensive Driver Development Solution in the Device Driver Fundamentals track

5. PatchGuard • 64-bit on x64 • Targeting root kits and other malware • If critical system structures get changed the system will bugcheck, for example • System service tables • IDT • GDT • Kernel stacks not allocated by the kernel • Patching any part of the kernel • So if you have drivers that modify (or create) such kernel structures they will cause the system to bugcheck • Together with Windows Defender it’s increasing Windows robustness

6. The HAL • No more uni-processor (UP) HALs • And thus no UP kernel either • Single threaded (versus single processor) server systems are becoming increasingly rare • No support for non-ACPI HALs • ACPI has been required for logo since 1998 • Now Windows Vista and Windows Server Longhorn will fail to install on a non-ACPI BIOS • No HAL kit • Relatively low impact

7. The New Boot EnvironmentIncluding UEFI support • Say goodbye to boot.ini, ARC paths and using Notepad to make boot option changes! • 64-bit x64 Windows Server Longhorn will support booting via UEFI 2.0 • IA-64 supports both EFI 1.1 and UEFI 2.0 • For more details please see the slides for the session: • Inside the Windows Pre-Boot and Boot Environment in the System Fundamentals – Core Platform Architecture and Security track

8. Native PCI Express Support • Windows Vista and Windows Server Longhorn have native support for • MSI and MSI-X • Extended configuration space • Segments • Custom properties • Advanced error reporting • Native hot plug • Active state power management • Native power management events • For more details please see the slides for the session • PCI Express in Depth for Windows Vista and Beyond in the System Fundamentals – Core Platform Architecture and Security track

9. Dynamic PartitioningReliability, Availability, Serviceability • Support for Hot Add of processors • Continued support for Hot Add memory • And the planned addition of Hot Add I/O APIC support • Hot Add Processor is available for test today • Support for Hot Replace of processors and memory • Available in a later Beta of Windows Server Longhorn • No support for Hot Remove of processors or memory in Windows Server Longhorn • Native hot plug of PCI Express devices

10. … … … … Memory Memory Core Core Core Core Core Core Core Core Cache Cache Cache Cache Memory Memory Service Processor . . . . . . IO Bridge IO Bridge . . . . . . IO Bridge IO Bridge Partition Manager PCI Express Dynamic Partitioning Windows Server Longhorn dynamic hardware partitioning features are focused on improving server RAS Future Hardware Partitionable Server 1. Partition Manager provides the UI for partition creation and management 2. Service Processor controls the inter processor and IO connections 3. Platforms partitionable to the socket level; virtualization used for sub socket partitioning 4. Support for dynamic partitioning and socket replacement

11. Dynamic PartitioningImpact on drivers • Per-processor data structures • Memory high-water mark usage • ISR and DPC routing • User mode IOCTL coordination between applications and their associated drivers • Supporting S4 transitions • Registering for Hot Add notifications • Affinity Mask manipulation • Supporting dynamic rebalance • NUMA behaviors

12. Memory ManagerEnhancements • Initial non-paged pool now NUMA aware, with separate VA ranges for each node • Per-node look-asides for full pages • Page table allocation for system PTEs, the system cache, etc., distributed across nodes • More even locality • Avoids exhausting free pages from the boot node • NUMA-related APIs for device drivers • MmAllocateContiguousMemorySpecifyCacheNode • MmAllocatePagesForMdlEx • Default if no node is specified has been changed • From current processor to the thread’s ideal processor

13. Memory Manager Enhancements • Win32 APIs that specify nodes for allocations and mapped views on per VAD and per section basis • VirtualAllocExNuma • CreateFileMappingExNuma • MapViewOfFileExNuma • Scalable query • QueryWorkingSetEx • Higher performance for very physically sparse machines • Example: very large IA-64 systems • 1TB gaps between chunks of physical memory • PFN database and initial non-paged pool always mapped with large pages regardless of physical memory sparseness

14. Memory ManagerEnhancements • Much faster large page allocations in kernel and user • Support for cache-aligned pool allocation directives • Data structures describing non-paged pool free list converted from linked list to bitmap • Significantly reduced lock contention • Bitmaps can be searched opportunistically lock-free • Costly combining of adjacent allocations on free no longer necessary

15. Transactional Registry • Needed for “all or none” semantics when changing a group of settings • Adds ACID semantics to a group of registry operations • Integrates with TxF and any other resource manager which participates in KTM transactions • A transaction can span across file system and Registry operations • Provides easier way for applications to clean up on error path

16. Registry Virtualization • Enable legacy applications to run as non-admin • Applications that want to write to keys that require admin privileges • Redirect globally impactful registry write to a per-user virtual key • Only keys under HKLM\Software are virtualized • Redirection is transparent to callers • Applications use the user’s virtual key while running • Is not platform support for sandboxing • Should be treated as an assistance technology

17. Registry VirtualizationWhat is not virtualized? • Application is identified as an “admin application” • Key is not changeable by admins • Key is Windows Resource Protected • Caller is kernel mode • Caller is using Impersonation • Any 64-bit application • Keys marked as ‘Do Not Virtualize’ • HKLM\Software\Classes

18. Registry Filtering • Certain classes of applications have the need for filtering registry calls • Anti-virus, Management applications etc. • Kernel mode callback model to allow for filtering registry operations • Allows monitoring and blocking of registry operations • Multiple drivers can register callbacks • Limitations • No support for modifying parameters or redirecting calls • No concept of altitudes

19. Windows Vista Enhanced Registry Filtering • Also applies to Windows Server Longhorn • Introduces a layered model with altitudes for callback registration • Consistent with the file system mini-filter model • Altitudes have to be registered with Microsoft • Ability to modify parameters and re-direct calls • Supports three modes of operation – Monitor, Block and Modify • Compatible with existing registry callbacks • Legacy callbacks will be registered at a default altitude • First come first served registration semantics retained for these legacy callbacks

20. Windows Service Hardening • Motivation • Services are attractive targets for malware • Running on a large number of systems • Services typically are higher privileged than users • Worms target services; e.g., Sasser, Code Red, etc. • Goals • Run with least privilege necessary • Use only resources needed by the service • Reduce the damage potential and number of critical vulnerabilities in services • Extend existing security model for more granular control

21. Windows Service HardeningRunning with least privilege • Privilege stripping • Enables a service to run with least privilege • Use only required privileges • Express required privileges during service configuration • SeBackupPrivilege, SeRestorePrivilege, etc. • ChangeServiceConfig2 API (sc.exe can be used as well) • SCM computes union of all hosted service required privileges • Permanently removes unnecessary privileges from process token when service process starts • No privileges are added • Target account must support required privileges; e.g., a service in LocalService account cannot get SeTCBPrivilege

22. Windows Service HardeningService isolation • Service-specific SID • 1:1 mapping between service name and SID • Use to ACL objects the service needs to allow access only to service-specific SID • Use ChangeServiceConfig2, sc.exe to control service SID • Set ServiceSidType to SERVICE_SID_TYPE_UNRESTRICTED • Service-specific SID assigned at start time • When service process starts • SCM adds service SIDs to process token • S-1-5-80-XXXXX-YYYYY • SID enabled/disabled when service starts/stops • Service SIDs are local to the machine

23. Windows Service HardeningReducing damage potential • Restricted services • Uses service SIDs and restricted tokens • Write-restricted service process • Allows service process write access only to objects allowing WRITE for service SIDs • Reduces the scope of resources accessed on the system • When service process starts • SCM adds service SID to both normal and restricted SID list in process token • SID enabled/disabled when service starts/stops • All services in a process must be restricted

24. Hardware WatchdogVersion 2.0 • The watchdog driver resets the count-down timer periodically or else performs a hard restart • Initial implementation made certain hardware assumptions • If your hardware didn’t comply it didn’t work • Version 2.0 increases flexibility • You can define how your hardware is organized • Or still use the original model • Automatically disabled when necessary • E.g., when writing out a crashdump • Available on both client and server if you have hardware to support that requirement • We do not support IPMI timers natively in Windows Server Longhorn

25. Other Technologies • Setup • All new and fully graphical • No text-mode component any more • Simplified user experience, and faster via use of WIM files installing via RAMDisk • WDS replaces RIS for remote network installation • OPK/WAIK • OEM and Enterprise Administrator custom configuration kits • WDK • KMDF for kernel drivers – v1.1 shipped • UMDF for user mode drivers • BitLocker™ and Full Volume Encryption • Use of TPM v1.2 in Branch Office Server scenarios

26. Future Technologies

27. ISR And DPC Redirection • There are performance benefits from running ISRs and DPCs on the thread that initiated an I/O operation • Directing Interrupt/ISR • Directing DPC • I/O buffer memory allocation • Requires the device driver performing I/O to have knowledge of where the I/O was initiated • Prototyping using MSI-X messages to attempt to route the request to the initiating processor, so the I/O happens on the initiating thread • We’re working with a number of OEMs and storage device vendors to develop support

28. Mem Y I/O X Node X ISR And DPC Redirection Hypothetical NUMA system I/O Z Mem Z Mem X I/O Y Node Y Node Z Y Y* Z Z* Y* Y* Z* Z*

29. ISR And DPC Redirection • Interrupt redirection choices (in order) • ISR comes back to core that initiated I/O • ISR comes back to processor that initiated I/O • ISR comes back to NUMA node that initiated I/O • ISR comes to node containing the HBA • DPC redirection • ISR must know the core/processor/node that initiated the I/O • Requires multiple DPCs per adapter (one per core/processor/node) • Memory redirection – where to allocate I/O buffers • Initiator’s node • ISR node • DPC node • Consumer’s node (for incoming data)

30. 64 Logical Threads • Multiple cores per processor will make the 64 logical thread limit very restrictive • E.g., cores and hyperthreads • Prototyping support for more than 64 logical threads • Proposed mechanism isn’t restricted to a specific number • There are many compatibility issues to be resolved before this can be released • Both applications and device drivers • The affinity mask is currently limited and we can’t “just” grow it • Need to measure scalability beyond 64 threads • This isn’t just a case of changing a #define !

31. Call To Action • Prepare for 64-bit-only Server in future releases • Ensure that your 64-bit kernel drivers are signed • Ensure that your drivers don’t change kernel data structures, or Windows will bugcheck • Learn about the many new features available in Windows Server Longhorn and Windows Vista • And how they may benefit or impact your drivers and hardware • Please talk to us if you have questions about the potential impact of these changes on your products

32. Additional Resources • Web resources • Dynamic Partitioning homepage • http://www.microsoft.com/whdc/system/platform/server/dhp.mspx • Whitepapers • http://www.microsoft.com/whdc/system/vista/kernel-en.mspx • Kernel patching FAQ • http://www.microsoft.com/whdc/driver/kernel/64bitpatch_FAQ.mspx  • Related sessions • Introduction to the WDK: A Comprehensive Driver Development Solution • Inside the Windows Pre-Boot Environment • PCI Express In Depth For Windows Vista and Beyond • Microsoft BitLocker™ Drive Encryption Hardware Enhanced Data Protection

33. © 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.