1.0Introduction
2.0Thread and Priority Scheduling
2.1CPU Scheduling
From Windows NT to Windows Vista (and still included in Vista) an interval timer interrupt routine executes every 10 or 15 milliseconds depending on hardware platform. This program examines which thread it interrupted and updates that thread's CPU usage statistics as if the thread had run for the entire allotted interval. However, the thread might have started executing just before the end of the interval. Also the thread might have been assigned to the CPU but never had a chance to run due to hardware and software interrupt routines executing. This clock based time accounting can result in unfair CPU allocation where by default on client versions of Windows threads are permitted to run up to 2 clock ticks, 6 if they are in the foreground. This means that the thread may get almost no time on the CPU for up to 6 clock ticks, 18 if in the foreground depending on several factors such as thread behaviour and system activity.
See figure 1.0 (Russinovich, 1997) which illustrates this problem where two threads have the same priority and are ready to run at the same time. Thread A runs until the next time slice expiration where the scheduler assumes it has run for the entire interval and marks Thread A's turn as finished. Thread A then gets unfairly charged for the interrupt occurring during its turn. At the next interval the scheduler picks Thread B where it runs for a full interval.
FIGURE 2.0 (Russinovich, 2007)
The Vista scheduler use uses a cycle counter register to track how many CPU cycles a thread executes, by estimating how many cycles the CPU can execute in a clock interval turns can be more fairly allocated. Additionally the Vista scheduler does not count interrup execution against a thread's turn which results in the thread at least always getting a turn on the CPU and never more than an extra clock interval of executing ultimately reulting in more fairness and deterministic application behaviour. See figure 1.1 on how in the same scenario as above, Vista gives both threads at least one time slice of execution (Russinovich, 2007).
FIGURE 2.1 (Russinovich, 2007)
2.2Multimedia Class Scheduler Service (MMCSS)
Vista uses the new Multimedia Class Scheduler (MMCSS) to provide for a better and more seamless playback of multimedia applications. Often CPU demand by other running applications causes stuttering and hiccupping behaviour in multimedia playback, thus the MMCSS is introduced to manage priority of multimedia threads differently. Multimedia applications register themselves with MMCSS and thread preferences are set for different multimedia types via a registry key which outlines task settings. MMCSS itself runs a Service Host process at a high priority thread (priority 27 of the Windows range 0 to 31), see figure 1.2. This results in the threads of registered multimedia applications having their threads boosted in priority where in Windows systems thread priorities over 16 are treated as real-time priority. However to ensure that MMCSS allows other applications to run, it reserves a percentage of CPU tie for other activity defined in the registry as System Responsiveness which is at default 20%. This results in multimedia threads not being assigned greater priority when other threads are contesting the CPU.
FIGURE 2.2 (Russinovich, 2007)
Although the MMCSS provides better playback, it has also unfortunately resulting in a throttling effect when Windows Media Player is launched and tries to copy files at gigabit speeds. This has been identified as a bug in that hard coding of network performance rate limiters did not make any allowances for the fact that the CPUs are now much faster and have multiple cores. Thus the Vista networking team and MMCSS team was working on a fix that allows for not so dramatically penalize network traffic while still providing smooth playback (Ou, 2007). The reason for the bug is that network performance was hard coded to cap at 10,000 packets per second if any MMCSS enabled application was running and demanded CPU priority, this rate limit results in network performance around 15 MB/sec which is not an issue for most high speed networks. However the throttling effect becomes apparent when users transfer files from gigabit-capable computers connected by gigabit Ethernet switches. See figure 1.3 for an illustration of this throttling effect.
FIGURE 2.3 (Ou, 2007)
3.0I/O Operations
3.1Symbolic File Link
A past criticism of Windows NTFS is that it was missing the functionality of the UNIX soft link (or symbolic file link), which now exists in Vista. Although Windows 2000 NTFS had symbolic directory links called junctions that allowed the creation of a directory that pointed to another directory but this is still considered a hard link. What differentiates the two is where processing takes place when Windows resolves symbolic links and directory junctions. Symbolic links are processed on the local system even if they reference a location on a remote file server where directory junctions that reference a remote file server are processed on the server itself. Thus symbolic links on a server can refer to locations that are only accessible from a client such as other client volumes and directory junctions can't. Now with Vista the symbolic link is supported for both files and directories. This results in files system commands being updated to understand symbolic link, thus the Delete command does not delete the target but only the link. Due to applications not being updated to handle symbolic links correctly, the ability to create a symbolic link is administrative by default. See figure 2.0 for an example of creating a symbolic file link in Vista.
FIGURE 3.0 (Buike, 2006)
Although the aim for Vista was to create symbolic links that function exactly like UNIX soft links, the implementation still has a number of restrictions compared to UNIX systems. They include the following: 1) Vista users must manually indicate when create a symbolic link whether it is a file or directory (MSDN, 2008); 2) Vista users can only create symbolic links as an administrator by default (Russinovich, 2007); 3) Vista only allows 31 symbolic links in a path; 4) Relative symbolic links cannot cross volumes.
3.2I/O Completion and Cancellation Processes
Prior to Vista when an I/O operation completed, the thread that issued the I/O request would execute I/O completion work causing a context switch to the process the thread belongs to and an interrupt to other running processes. Completion port status would then be updated resulting in waking up a thread that was waiting for it to complete. On Vista the completion processing is not always done by the same thread that issued the I/O request but instead by the thread that is waiting for the completion port in order to start. This is a small change but avoids unnecessary thread scheduling and context switches that impact application and system performance. Additionally, a server can retrieve the results of multiple I/O operation from a completion port in one request avoiding a switch to kernel mode (MSDN 2008).
Also new with Vista is the ability to cancel synchronous I/O operations. For instance prior to XP when trying to do an activity like accessing a share to an off-line remote system, this would cause the system to hang and the inability to cancel the request. Thus the application had to wait until the operation failed as a result of an error such as a network timeout because there was no way for the operation to tell the device driver executing I/O that it no longer wants to continue. At Vista most I/O operations can be cancelled including open file I/O. For instance, file save and open dialogs now enable the cancel button while attempting to display folder contents. In Vista device drivers also register for notification of process terminations so that when an I/O process does fail there are no longer lingering processes hanging around that did not terminate because there was no way of them responding to a cancel I/O request (Dorman, 2006).
3.3I/O Prioritization
Windows has like most systems always supported CPU prioritization but this has not included I/O priority. The results of I/O not being prioritized can be seen in background activities such as search indexing, virus scanning and disk defragmenting impacting the responsiveness of foreground processes. These applications then experience delays when these background processes are running as they wait for disk access. Vista has two types of I/O prioritization: 1) priority on individual I/O operations; 2) priority on individual I/O operations and I/O bandwidth reservations. Vista currently supports five I/O priorities even though only four priorities are currently used as future versions may support High.
I/O Priority Usage
Critical Memory manager
High Unused
Normal Default priority
Low Default task priority
Very low Background activity
The Memory manager uses Critical priority when dirty memory data is written to disk under low memory situation to make room in RAM for other data and code. The Window Task Scheduler sets I/O priority for tasks that have Normal to low priority and Vista background processing application have very low priority. All Vista background operations such as indexing use very low priority.
Since Windows NT the Memory manager and the I/O system have limited the amount of data processed by an individual storage I/O request to 64KB. Even if an application issues a large request, it is broken down into individual requests of a maximum size of 64KB. Thus each segment incurs overhead for kernel mode transition and initializing an I/O transfer. At Vista this cap in size no longer exists eliminating this overhead.
4.0Memory Management
4.1Dynamic System Address Space
In Windows systems, the kernel is constrained to 2GB by default or half the total 32-bit virtual address space with the other half being used for processes where their thread is currently running in the CPU. Thus in the kernel half of the address space, the kernel must map itself, device drivers, file system cache, kernel stacks pre-session code structures, non-paged and paged buffers used by device drivers. Before Vista the Memory manager determined at boot how much address space to assign to the above purposes which led to inflexibility and regions becoming full. In 32-boit Vista virtual memory is assigned as needed which permits larger paged, non paged and session pools which support larger terminal servers and desktop heaps. However, components still cannot exceed 2GB. Vista improves virtual address space usage by having kernel page tables allocated on demand instead of at boot. The kernel stack usage has been reduced and allows more users on a terminal server system; the desktop heap can also expand without requiring reboot (Dorman, 2006). 64-bit Windows Vista address space regions are configured at their maximum for all memory sizes.
4.2Memory Prioritization
As with the addition of I/O prioritization, memory is now also prioritized in Vista. On versions of Windows prior to Vista, when a physical page owned by a process was reclaimed by the system the Memory manager placed the page at the end of the Standby list. A process that wanted to access the page again would then have the Memory manager take the page form the standby list and reassign it to the process. A process wanting a new page of physical memory where no free memory was available was given a page from the front of the Standby list. Thus all pages on the Standby list were treated as equal priority. New on Vista is that every page of memory is assigned a priority of 0 to 7, resulting in the Memory manager dividing the Standby List into 8 lists that store pages of a given priority. The Memory manager then takes pages from low priority lists first where a page's priority is determined from the thread that causes its allocation where shared pages reflect the highest memory priorities. A thread inherits page priority from its parent process. Memory page priority benefits are seen when relative priorities are used by SuperFetch (discussed below).
This radical change in the way memory is used that was introduced at Vista has created a lot of questions and criticism along the lines of “Why does Vista use all my Memory”. For instance consider Figure 3.0 and 3.1 which show memory on a Vista machine and XP machine respectively:
FIGURE 4.0 (Atwood, 2006)
FIGURE 4.1 (Atwood, 2006)
Here it can be seen that when running a similar amount of processes, Vista is using much more memory. This is often viewed negatively when memory is viewed as a system resource that is being consumed. However memory should be viewed as a high speed cache that sits between the computer and disk drive. Under this theory an empty cache is memory that is wasted as it is not being used. A cache that is populating itself as quickly as possible with data that is going to be needed will deliver a much higher hit rate and thus better performance. Vista attempts to pre-emptively populate system memory with what it believes might be needed next. This describes the concept of SuperFetch described next.
4.3SuperFetch
Prior to Vista the Standby list management by the Memory manager relied only on past behaviour with no anticipation of future requirements. Data used for prioritization was limited to the list of pates owned by a process at any point in time. This resulted in sluggish performance after running memory intensive applications that would force the code and data that active applications had cached to be overwritten. SuperFetch runs inside a Service Host process and relies on support from the Memory manager in order to retrieve page usage histories and direct the Memory manager to preload data and code from disk or a paging file into the Standby List and assign priorities to pages. Using knowledge of memory usage, SuperFetch can preload data and code when physical memory becomes available. Essentially SuperFetch analyzes behaviour over multiple sessions (after several reboots and application launches) to preload data. For example, if every morning over several days a user always launches their mail reader, SuperFetch will load these applications into memory as soon at the PC is started. Whenever memory becomes free when an application exists or releases memory, SuperFetch asks the Memory manager to fetch data an code previously evicted as the rate of a few pages per second with very low priority I/Os so that preloading does not impact other active applications.
However, loading more data into the faster RAM from the slower disk drive results in better performance but also requires free RAM to be effective. Thus Vista requires more RAM to effectively use SuperFetch. The tests were done on SuperFetch by Tom's Hardware (www.tomshardware.com) and performance time is illustrated in Figure 3.2.
FIGURE 4.2 (Chen, 2007)
4.4ReadyBoost
Because of increasing speed of CPUs and memory, performance bottlenecks are now being seen from hard disks where random disk I/O is expensive due to disk head seek times relative to processor and memory speed. Increasing RAM is an expensive option where other options such as Flash memory are relatively cheap while offering reads up to 10 times faster than an average disk. Vista takes advantage of this by including ReadyBoost which takes advantage of Flash memory storage devices by creating an intermediate caching layer that sits between memory and disks. ReadyBoost runs in a Service Host process that detects when a Flash drive has been attached to the system and asks if the user would like to dedicate some of the Flash memory for disk caching. If the user agrees a caching file is created in the root of the device and SuperFetch pre-populates the cache in the background.
Tom's Hardware (www.tomshardware.com) tested ReadyBoost and found dramatically decreased application launch times on low RAM systems when partnered with SuperFetch as indicated in Figure 3.3.
FIGURE 4.3 (Chen, 2007)
4.5ReadyBoot
If a system has less than 512MB of memory then boot-time pre-fetching is the same on Windows XP as Vista. However with more than 700MB of RAM, Vista uses an in-RAM cache to optimize the computer boot where size of the cache depends on total RAM available. After every boot the ReadyBoost service uses idle CPU time to calculate a boot time caching plan for next boot by analyzing files trace information previous boots and identifying which files were accessed. The cache is implemented by the same device driver implementing ReadyBoost caching.
4.6ReadyDrive
ReadyDrive uses new hybrid hard disk drives called H-HDDs which is a disk embedded with non-volatile Flash memory (NVRAM). Vista uses ATA-8 commands to define the disk data held in Flash memory. Saving boot data to the cache allows for faster restarting, Vista can also use Flash as disk write cache which avoids spinning up the disk when the system is running on battery power.
Although the combination of ReadyBoot and ReadyDrive promises several advantages such as fast boot times and better power savings, there are some criticisms with these technologies. It has been criticized that a USB thumb drive is not the ideal option as they stick out of notebook computers and can easily be knocked off resulting in the notebook locking up while looking for the drive when a better option would have been a PC Card format. Secondly, Flash memory unlike reliable hard disk memory can wear out after a certain number of writes as certain cells become exhausted and unreliable. This is often addressed by wear levelling algorithms by the manufacturers. The question then becomes whether data can be trusted on Flash.
5.0Start up and Shutdown
5.1Boot Configuration
At Vista instead of the usual Boot.ini file, there is a new Boot Configuration Database (BCD) for storing system and OS startup configuration. The reason for switching to the BCD is that it unifies the two current boot architectures support by Windows: 1) Mater Boot Record (MBR); and 2) Extensible Firmware Interface (EFI). MBR is used by x86 and x64 desktop system where EFI is used by Itanium systems, thus the BCD abstracts firmware. BCD also has support for Unicode strings and alternate pre-boot executables. The interfaces for manipulating the BCD are available through scripts and custom editors like Windows Management Instrumentation (WMI). The BCD divides platform wide boot settings from OS specific setting. See figure 4.0 for an example of he command line Bcdedit command which displays platform setting in the Windows Boot Manager section followed by OS specific setting in the Windows Boot Loader Section.
FIGURE 5.0 (Fooshen, 2006)
In contrast to previous versions of Windows NT which when booted loaded the BIOS then the MBR of the boot disk followed by the boot sector of the drive or partition which then loads the rest of the boot blocks, in Vista the boot sector loads the Windows Boot Manager which accesses the BCD store and uses information to load the Operating System. See figure 4.1 for an illustration of this sequence.
FIGURE 5.1 (Soumyasch, 2007)
5.2Startup
There were several issues surrounding previous versions of Windows startup procedures. Windows used a namespace container called Session to isolate processes running in different logon session. However when the user logged into the console they shared Session 0 the same session used by system processes which created several security issues. Thus many system processes were re-architected for Vista. Session Manager is the first user mode process created during boot but in Vista the Session Manager launches a second instance of itself to configure Session 0 which is dedicated to system processes only. When a user logs into the system the initial Session Manager creates a new instance of itself to configure the new session, thus having a primary Session Manager create copies of itself for new sessions greatly speeding up logon times for terminal servers. Also system processes including Windows services are isolated in Session 0, where if a service attempts to display a user interface (which is a way malware used techniques like shatter attacks in previous versions of Windows) the Interactive Services Detection service notifies the administrator.
5.3Autostart Services
Normally after starting Windows there is a delay as the Service Control Manager is starting Windows services with automatic start, some which may perform I/O and CPU intensive activities which cause a delay in logon activities. Vista has a new service started called delayed automatic start which services can use if they don't have to be immediately active after boot. The SCM starts services configured for delayed automatic after other automatic services have started and sets priority of their internal threads to very low I/O, after they have initialized threads are then set back to normal. See figure 4.2 for the new delayed Autostart option.
FIGURE 5.2 (Hitney, 2007)
5.4Shutdown
Prior to Vista, Windows services had by default a maximum of twenty seconds to perform cleanup on shutdown, this resulted in buggy services holding up shutdown and thus cleanup by processes not being completed. Some services that require operations to save data to disk might require more time. Now when Vista shuts down the Service Control Manager notifies those services requesting pre-shutdown notification. The SCM will wait for these services to exit, if they contain a bug and don't respond the SCM moves on after three minutes. Once all services have exited or the timeout has expired, then the system reverts back to the old method of shutting down services. Additionally, although Windows services have always been able to specify startup dependencies, they now can specify shutdown dependencies at Vista.
6.0Power Management
Since Windows NT, buggy power management in drivers and applications have caused erratic sleep and hibernate behaviour in laptops such as closing a lid and expecting the system to hibernate and it does not resulting in dead batteries and lost data. This is due to the fact that Windows asks device drivers and applications for consent to change power state, thus an unresponsive driver will prevent power state transition. In Vista the kernel's Power Manager still informs drivers and applications of power state changes in order for them to prepare but no longer asks for permission. The Power Manager waits at most 20 seconds for applications to respond to change notifications.
7.0Error Handling and Recovery
7.1Kernel Transaction Manager
Prior to Vista, applications had to perform several actions to recover from errors during modification of files and registry keys. Vista implements a transaction manager called the Kernel Transaction Manager (KTM) which makes sure that changes are committed only when the associated transaction is completed and commits. The KTM is extensible through third party resource manager and coordinates between the transaction clients (applications) and resource managers. The registry and file system have been enhanced to support transactions across all operations and is used by Windows Update services and System Protection services.
When an application intends to make a number of related changes it can either create a Distributed Transaction Coordinator (DTC) transaction and KTM transaction handle or create a KTM handle directly and associate the modifications of files and registry keys with the transaction. Successful changes are committed and unsuccessful changes can be rolled back to any point in the application. Thus an application using KTM for changes will never leave the application in an inconsistent state.
In Vista, NTFS uses an extension to support transactions called TxF. The registry uses a similar extension called TxR. Both of these extensions define a new set of file system and registry API's similar to existing ones with the addition of a transaction parameter. These extensions rely on system logging functionality of the Common Log File System or CLFS introduced in Windows Server 2003 to store transactional state changes before committing a transaction. Figure 5.0 illustrates the log files used to track transaction changes to the system's registry.
FIGURE 7.0 (Russinovich, 2007)
7.2Crash Handling
Kernel mode errors that result from bad device drivers, faulty hardware and operating system problems attempt to prevent data on disk corruption by halting the system which often resulted in the notorious “blue screen” and writing contents of physical memory to a crash dump file which could later be used by Microsoft Online Crash Analysis (OCA) to determine root cause. The issue with versions before vista was that crash dump files could not be enabled until the Session Manager finished initializing page files. Thus critical errors before this point caused system halt with no dump files, since driver initialization happens during this time, driver problems would cause this issue and be difficult to diagnose due to lack of dump file. At Vista the dump file is now initialized after booting and before drivers are initialized which allows the system to capture a crash dump during a time where previous versions were unable to do so. The dump file also is now saved in 64KB blocks versus previous version using 4KB blocks resulting in dump files being written 10 times faster.
On application crash previous versions executed an unhandled exception handler which launched the familiar display dialog asking whether the user wished to send an error report to Microsoft but this would occur only if the stack of the process's main thread was not corrupted during the crash in which case the program would be terminated by the kernel without the error dialog. At Vista error handling is moved into a new service, Windows Error Reporting (WER) which runs inside the Service Hosting process. When an application crashes an unhandled exception handler still executes but sends a message to WER which launches the Fault Reporting Process to display an error dialog. The Windows Error Reporting Service (Werfault.exe) replaces Doctor Watson (Dwwin.exe) and permits WER to be invoked for threads that are too corrupted to invoke their unhandled exception handling. See figure 5.1 and 5.2 for the error reporting dialog in XP versus Vista respectively.
FIGURE 7.1 (Russinovich, 2007)
FIGURE 7.2 (Russinovich, 2007)
7.3Volume Snapshots
Vista introduces Volume Shadow Copy for System Restore and Previous Versions. This creates a point in time copy on write snapshot of lives volumes and addresses the problem of open files not being backed up. Pervious Versions tab was originally introduced as Windows Server 2003 “Shadow Copies for Shared Folders”. Volume Shadow Copy now used the Kernel Transaction Manager (KTM) for consistent cross volume snapshots, generally snapshots are taken once per day and when system restore points are taken. Note that snapshots are not actually full copies of volumes but rather views of a volume from an earlier point that comprise live volume data overlaid with copies of volume sectors that have changed since the last snapshot.
8.0Security
8.1BitLocker
A new security feature of Vista is BitLocker Drive Encryption technology. BitLocker was designed to prevent information loss by theft or accident as information loss and intellectual property theft are becoming more serious and prevalent. BitLocker improves data protection by preventing another operating system or hacking tool to break file and system protections by preventing offline viewing of user data and OS files through enhanced data protection and boot validation using Trusted Platform Module (TPM). TPM is a piece of hardware that is part of the motherboard that performs the following functions (See Figure 6.0 for an overview):
FIGURE 8.0 (Dorman, 2006)
TPM is a hardware implementation of a Root-of-Trust which can be certified to be tamper resistant, when combined with software is can protect root secrets better than software alone. A TMP can also ensure that keys and secrets are only available for use when the environment is appropriate. However, BitLocker only encrypts the Windows partition and a dual-boot with another OS on the same partition is prohibited where different partitions are not. Any attempt to modify the protected Windows partition will render it unbootable (See figure 6.1).
FIGURE 8.1 (Dorman, 2006)
To completely protect all data on the computer a combination of BitLocker on the Windows partition and Encrypted File System (EFS) on other partitions is recommended. EFS was introduced at Windows 2000 but has been improved at Vista to support encrypting the paging file and storage of user EFS Keys on Smart Cards but cannot protect access to sensitive areas such as registry hive files. Unlike EFS which is implemented by the NTFS files system driver and operates at the file level, BitLocker encrypts at the volume level using the Full Volume Encryption (FVE) driver (See Figure 6.2).
FIGURE 8.2 (Russinovich, 2006)
FVE is a filter driver that automatically sees all I/O requests that the NTFS sends to the volume encrypting blocks as they are written and decrypting them as they are read using the Full Volume Encryption Key (FVEK) assigned to the volume when it is initially configured. Because encryption and decryption happen beneath NTFS in the I/O system the volume appears to NTFS as if it is encrypted and NTFS does not need to be aware that BitLocker is enabled.
Although BitLocker seems like a giant leap forward in data protection and uses a form of theoretically unbreakable encryption, it important to note that there are things that BitLocker cannot defend against and include: 1) Hardware debuggers; 2) Online attacks; 3) Post logon attacks; 4) Sabotage by administrators; 5) Poor security maintenance; 6) and BIOS re-flashing. Additionally, BitLocker has received some criticism and controversy such as Microsoft's apparent silence on the performance hit that BitLocker based systems incur. Also machines that use BitLocker without TPM can technically succumb to brute force attacks although Microsoft claims that this would be unfeasible. However the greatest criticism comes from the possibility of human error. Data protected with BitLocker is literally unrecoverable in the event that the user forgot their recovery password or lost the recovery key. Unrecoverable and un-crackable data also has implications for law enforcement and cyber crime.
8.2Kernel Mode Code Signing
Malware and rootkits are often implemented as kernel-mode devices drivers running at the same privilege level as the kernel making them difficult to identify and remove. Vista introduces code integrity for kernel mode code called kernel mode code signing (KMCS) which only allows device drivers to load if they are published and digitally signed and vetted by selected certificate authorities. KMCS is enforced by default on 64-bit system. KMCS also provides contact information for the Windows Online Crash Analysis team when a driver is suspected to have a bug crashing systems.
When a driver attempts to load, Windows decrypts the hash included with the code using the public key stored in the certificate and then verifies that the hash matches the one included with the code. The authenticity of the certificate is checked in the same way but using the certificate authority's public key included with Windows. Windows also checks the associated certificate chains up to one of the root authorities embedded in the Windows Boot loader and operating system kernel. 64-bit Vista silently writes an event to the Code Integrity application event log when it blocks loading of an unsigned driver (Figure 6.3). 32-bit Vista also checks driver signatures but allows unsigned drivers to load as blocking them would break upgraded XP systems, however it also writes events to the Code Integrity event logs when loading an unsigned driver. For developers there is a test signing mode where unsigned drivers will load using a test certificate by an in-house authority.
FIGURE 8.3 (Russinovich, 2006)
8.3Protected Processes
Protected processes are based on the standard Windows process construct that encapsulates a running executable image but prevent certain types of access. Protected processes restrict access to a limited set of informational and process management interfaces that include querying the process's image name and terminating or suspending the process. The kernel makes diagnostic information for protected processes available through general process query functions that return data regarding all the processes on a system and don't require direct access to the process. Additionally, to prevent compromise from within all executable code loaded into a protected process must be either signed by Microsoft with a Protected Environment (PE) flag. Because kernel mode code can gain full access to any process, included protected processes, the kernel provides and API for protected processes to query the cleanliness of the kernel mode environment and use the result to unlock content only if no unsigned code is loaded.
8.4Address Space Load Randomization
Address Space Load Randomization (ASLR) causes system code to load into different locations in memory on system boot. This addresses several buffer overrun exploits and defeat attacks such as “return-to-libc” where exploit code attempts to call a system function such as the socket() function in wsock32.dll to open a socket or LoadLibrary in kernel32.dll to load wsock32.dll. Thus ASLR removes these function entry points around in memory to unpredictable locations.
Early in the boot process the Memory manager picks a random DLL image load bias from one of 256 64KB aligned addressed in the 16MB region at the top of the user mode address space. The Memory manger packs DLLs that have the new dynamic relocation flag in their header starting at the image load bias address and works its way down. If a DLL or executable loads again after being unloaded by all processes using it, the Memory manager reselects a random location at which point to load it. See figure 6.4 which shows address space for a 32 bit Vista system including areas from which the ASLR picks the image load bias and executable load address. Additionally, ASLR's relocation strategy results in more tightly packed address spaces creating larger regions of free memory which reduces the number of page table the Memory manager allocates to keep track of address-space layout and minimizing Translation Lookaside Buffer (TLB) misses.
FIGURE 8.4 (Russinovich, 2006)
8.5Service SID
Vista now restricts service privileges further than previous version by reducing access to files, registry keys and firewall ports. In Vista there is a new group account called service Security Identifier (SID) unique to each service. The service can set permissions on resources based on its SID thus preventing other services from compromising them. A services SID can by viewed using the command line sc showsid followed by the service name (Figure 6.5).
FIGURE 8.5 (Russinovich, 2006)
When the Service Control Manager starts a process that hosts one or more Windows services a security token is created which is the kernel object that lists a process user account, group membership and security privilege. That process includes only the privileges required by the services in the process, if a service specifies a privilege that is not available to its account if fails to start. Therefore if a service process is compromised by malware, that code cannot take advantage of privileges that are not requested by the services running the process. The sc qprivs command reports on what privileges a service has requested.
