Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Windows Vista and “Longhorn” Server: Under the Hood of the Operating System Internals and Your Application Richard B. WardKarthik Thirumalai FUN417Program.

Similar presentations

Presentation on theme: "1 Windows Vista and “Longhorn” Server: Under the Hood of the Operating System Internals and Your Application Richard B. WardKarthik Thirumalai FUN417Program."— Presentation transcript:

1 1 Windows Vista and “Longhorn” Server: Under the Hood of the Operating System Internals and Your Application Richard B. WardKarthik Thirumalai FUN417Program Manager Architect

2 2 Simplified Windows Core Memory Manager I/O Manager Security Scheduler Object Manager Inter-processCommunication Hardware Abstraction Layer User Mode Kernel Mode NTDLL advapi32kernel32 Registry PowerManagement Plug and Play...

3 3 Simplified Windows Core Memory Manager I/O Manager Security Scheduler Object Manager Inter-processCommunication Hardware Abstraction Layer User Mode Kernel Mode NTDLL advapi32kernel32 Registry PowerManagement Plug and Play...

4 4 Core Changes New Boot environment Platform and Firmware independent and highly portable Supports 32 and 64 bit systems via PC/AT BIOS or EFI Fully localized, supporting many languages Hot Add/Replace of processor and memory Enhanced power management with Hybrid Sleep Combines Standby and Hibernate Suspend to RAM and disk at the same time

5 5 Core Changes Memory manager Dynamic system address space System virtual address (VA) space kernel page tables allocated on-demand NUMA and large page support Paging video memory

6 6 Core Changes User Mode Driver Framework Infrastructure to run a device driver in user-mode Implementation of the WDF Driver Model Supports core WDF objects User-Mode Drivers are isolated from other drivers Kernel is isolated from User-Mode drivers System can recover after a driver crash – no blue screen Enhanced multimedia support Multimedia Class Scheduler Service Support for soft real-time memory allocations Scheduled File I/O

7 7 Security Enhancements Kernel mode malware on the rise Presents new categories of problems Malicious code running with the highest privileges Device drivers can monitor and affect almost anything on the system

8 8 Security Enhancements Kernel mode code must be digitally signed Enforced at install and load time x64 only for Vista User mode code Critical system processes will require signed code

9 9 Windows Services Architecture overview Changes to the services model Security Session 0 isolation, Service hardening Performance Delayed Start, State change notifications Reliability Failure action on non-crash failures

10 10 Services Model Overview SCM API clients Control Service Control Manager HKLM\System\CCS\Services Svchost.exe OwnProc.exe LRPC RPC/TCP (Vista+) RPC/NP (legacy) Service process communication channel Start, stop, controls Hosts a configurable number of services

11 11 Service Start Types Automatic Started during boot by SCM Auto-start services have a significant performance effect Lots of I/O requests and contention over global resources Can have a significant effect on boot time Manual Started on demand by a client Reduces impact on boot performance

12 12 Start Types – Delayed Start Delayed Auto Start – new in Windows Vista Many services are auto start simply because they want “unattended” start, but do not need to be running immediately after boot Delayed start services are started in low priority CPU & IO threads shortly after boot Client code must tolerate service’s unavailability SERVICE_DELAYED_AUTO_START_INFO sdaInfo; sdaInfo.fDelayedAutoStart = TRUE; ChangeServiceConfig2(hService, SERVICE_CONFIG_DELAYED_AUTO_START_INFO, &sdaInfo); &sdaInfo);

13 13 Service Security Model Built-in accounts for easy management No password management requirements LocalSystem Very powerful and has most privileges – use cautiously LocalService and NetworkService Greatly reduced privilege set NetworkService uses machine account for remote authentication Session-0 Isolation – new in Windows Vista Services are isolated from interactive sessions Helps mitigate UI attacks

14 14 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

15 15 Running 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

16 16 Service 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

17 17 Reducing 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

18 18 Service Management Service State Changes Clients used QueryServiceStatus polling loop to discover state changes Many bugs found in such loops Performance hit due to lots of threads looping at boot New notification API NotifyServiceStatusChange Notification of service state changes & Create/Delete Works both locally and remotely Callback based Uses cross-process APC mechanism locally Uses async RPC remotely

19 19 Service Management SCM supported automatic recovery on service crashes Enabled by specifying the FailureAction settings for a service. Recovery usually invoked only on service process crash Support for recovery on non-crash – new in Windows Vista Service can fail in other ways than crashing Leaks, System load etc. Enabled by specifying FailureActionOnNonCrashFailures flag in addition to the FailureAction settings Invoked on service stop with dwWin32ExitCode != ERROR_SUCCESS

20 20 Windows Registry Architecture overview Changes in Windows Vista Transactional registry Registry virtualization Enhanced registry filtering

21 21 Windows Registry Most widely used configuration store One of the first OS sub-systems to be started Used by the kernel, drivers, apps and anything else that needs to store or share state information Simple programming model Hierarchical layout to provide structured access to data Abstracts the complex data management schemes Reg* APIs in user mode, Zw APIs in kernel mode Data is stored in Registry hives Implemented as files Logically, registry is a “FS in a file”

22 22 Architecture Overview User KERNEL CM (registry) NTFSCC Cache Manager Disk ADVAPI32.DLL Win32 Registry APIs svchost.exe regsvc.dll NT APIs PRIMARY file (CC PRIVATE_WRITE streams).LOG file (NO_INTERMEDIATE_BUFFERING) MM Memory Manager Volatile Storage

23 23 Windows Vista - Transactional Registry Needed for “all or none” semantics when changing a group of settings Adds ACID semantics to group of registry operations Integrates with TxF and any other Resource Manager which participates in KTM transactions A transaction can span across FS and Registry operations Provides easier way for apps to clean up on error path More information on Transactional technologies in Vista – FUN320

24 24 Windows Vista – 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

25 25 Virtualization – How It Works Write HKLM\Sofware\Key1 HKLM\Sofware\Key1V1V2 V3 -> RegSetValueEx(…) ACCESS_DENIED => HKU\{SID}_Classes\VirtualStore\Machine\Software\K1 V3 V3 Opening key for WRITE_ACCESS returns MAX_ALLOWED

26 26 What 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

27 27 Virtualization Configuration Globally controlled by the caller’s token Can be turned on/off on individual keys in the Software hive New FLAGS option in reg.exe for key level virtualization control Allows recursive enable/disable of virtualization Allows control of “open access right policy” Changing ACLs on specific keys

28 28 Virtualization Gotchas’ Using the registry for IPC Service and user apps will have different views of the key Impersonating callers Will not be virtualized Audit for possible elevation paths Virtualization is at the value level Default for the Software hive is enable recursive virtualization

29 29 Registry Filtering Certain class of applications have the need for filtering registry calls Anti Virus, Management apps, 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 to modify parameters or redirect calls No concept of altitudes

30 30 Windows Vista Enhanced Registry Filtering 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 serve registration semantics retained for these legacy callbacks

31 31 What Is WoW64? 32-bit Windows emulation layer on 64-bit Windows Binary compatibility with 32-bit Windows applications 32-bit code executes as if it is running on a native x86 processor

32 32 WoW64 Architecture 64-bit ntdll.dll WoW64.dllWoW64win.dll WoW64cpu.dll Win32k.sys NT Executive Kernel Mode User Mode 32-bit ntdll.dll 32-bit modules Reserved Address Space 0x00000000`7FFEFFFF or 0x00000000`FFFEFFFF 32-bit kernel32.dll 32-bit user32.dll

33 33 WoW64 Architecture Address space is limited to 2GB (or 4GB if the application is marked Large-Address-Aware in the header) WoW64 processes can NOT load 64-bit DLLs except for the core one! Likewise, native 64-bit processes can NOT load 32-bit DLLs LoadLibrary() will fail No 16-bit support on 64-bit Windows 32-bit kernel drivers won’t run on 64-bit Windows Needs to be ported and support WoW64 Target 64-bit platform may not support specific features GetNativeSystemInfo() retrieves info about the native system

34 34 WoW64 Registry Two views of the registry exist on 64-bit Windows Native and WoW64 Native 64-bit Windows application sees the native registry view WoW64 application sees the WoW64 view Why different WoW64 registry views? Compatibility Separates 32-bit application state from 64-bit state Not supported features stored in the registry Provides a safe execution environment for both 32-bit and 64-bit applications A registry value hosting a DLL path

35 35 Registry Redirection Certain parts of the system registry are separated HKEY_LOCAL_MACHINE\SoftwareHKEY_CLASSES_ROOT When a WoW64 process opens/creates a key WoW64 redirects the path of the key if it is one of the above by inserting ‘WoW6432Node’ to the above path Transparent for Win32 applications RegConnectRegistry selects server view based on the caller bitness Only on new clients (Windows XP 64 and beyond)

36 36 Registry Reflection Enables 64-bit and 32-bit application Inter-Op through COM Mirrors certain registry keys and values between the 32-bit and 64-bit registry views Ownership-based reflection Helps intelligent reflection of COM servers Rules for HKEY_CLASSES_ROOT\CLSID reflection InProcServer32 and InProcHandler32 are not reflected LocalServer32 is reflected Delete reflected keys only if written by WoW64 reflector

37 37 32/64 Inter-Op Issues Pointer data type storage is 64-bit (8 bytes) on 64-bit Windows systems while it is 32-bits (4 bytes) on 32-bit Windows systems Alignment is different as well Client/Server applications communicating using shared memory Client is 32-bit running on 64-bit Windows and server is 64-bit or vice versa Shared structures are pointer-dependent Two solutions 32-bit Client writes compatible 64-bit structures 64-bit Server doesn’t need to be WoW64 aware 64-bit Server reads 32-bit and 64-bit structures 64-bit Server is WoW64 aware 32-bit Client may need to change if source request is not known to the 64-bit server

38 38 32/64 Inter-Op Issues 32-bit Windows- Compiled data type 64-bit Windows compiled data type representing 32-bit Windows-Compiled data type How to convert? HANDLELONG LongToHandle (handle_value32) Process and thread handle are signed-extended PVOIDULONG UlongToPtr (pvoid_value32) Addresses should never be sign-extended ULONGULONG No conversion is needed HWNDLONG (HWND)LongToHandle (hwnd32) Window handles are sign- extended Don’t pass addresses above 2GB (or 4GB) to a WoW64 application How to convert data types?

39 39 Community Resources At PDC For more information, go see FUN Track lounge Labs: FUNHOL19; FUNHOL13 Related sessions FUN320 – Transactional NTFS and Registry FUN210; FUN406 – Security and UAP PNL07 – Future Directions for Windows Internals

40 40 Community Resources After PDC Kernel Changes in Windows Vista – UMDF - Registry filter driver registration - WoW64 - us/win64/win64/running_32_bit_applications.asp us/win64/win64/running_32_bit_applications.asp us/win64/win64/running_32_bit_applications.asp

41 41 Questions?

42 42 © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Download ppt "1 Windows Vista and “Longhorn” Server: Under the Hood of the Operating System Internals and Your Application Richard B. WardKarthik Thirumalai FUN417Program."

Similar presentations

Ads by Google