Hardware-enforced DEP
To provide consistency for application and driver developers, the memory protection model (including DEP) is designed to be the same for both 32-bit and 64-bit versions of Windows.
Application developers should be aware of DEP behavior in user mode. A user-mode DEP exception results in a STATUS_ACCESS_VIOLATION (0xc0000005) on Windows systems. The first parameter of ExceptionInformation that is located inside the EXCEPTION_RECORD structure contains the type of access violation that occurred. A value of 8 for ExceptionInformation[0] indicates the access violation was an execution violation.
In most processes, the STATUS_ACCESS_VIOLATION exception will be an unhandled exception and result in termination of the process.
DEP is also applied to drivers in kernel mode. DEP for memory regions in kernel mode cannot be selectively enabled or disabled. On 32-bit versions of Windows, DEP is applied to the stack by default. This differs from kernel-mode DEP on 64-bit versions of Windows, where the stack, paged pool, and session pool have DEP applied.
Device drivers are not permitted to execute code from the stack when DEP is enabled. A DEP access violation in kernel mode will result in an error 0xFC: ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY.
Software-enforced DEP
Software-enforced DEP performs additional checks on exception handling mechanisms in Windows. If the program’s image files are built with Safe Structured Exception Handling (SafeSEH), software-enforced DEP ensures that before an exception is dispatched, the exception handler is registered in the function table located within the image file.
If the program’s image files are not built with SafeSEH, software-enforced DEP ensures that before an exception is dispatched, the exception handler is located within a memory region marked as executable.
DEP application close behavior
The majority of applications will not encounter a problem with DEP. However, when an application does encounter a problem with DEP, a Data Execution Prevention message is presented to the user, alerting them to the problem.
The Data Execution Prevention message indicates that a DEP problem occurred with the application and provides the ability for the user to learn more about DEP and optionally disable DEP for the application that was closed.
.gif) Important |
|
If a DEP problem occurs with an application, Microsoft recommends contacting the application vendor for an update. The security implications of disabling DEP for an application should be thoroughly considered before disabling DEP for an application.
The ability to change DEP settings for a closed application using the Change Settings button on the Data Execution Prevention message window depends on the system-wide DEP configuration. Changes to DEP protection for an application can be made only if the system-wide DEP configuration is set to the OptOut mode. |
The Data Execution Prevention message is presented immediately before a Windows Error Reporting window, which provides the opportunity to submit a report about the DEP problem to Microsoft.
On Windows Server 2003 with Service Pack 1, the Data Execution Prevention message will be presented the next time an Administrator logs onto the system interactively. The behavior is changed on Windows Server 2003 with Service Pack 1 from Windows XP with Service Pack 2 because Windows Error Reporting is configured in queued mode by default. Queued mode causes error reporting messages to be queued until the next time an administrator interactively logs onto the system.
To learn more about Windows Error Reporting, or to configure Windows Error Reporting such that DEP and Windows Error Reporting messages are displayed immediately following an application problem, see the "Using Windows Server 2003 in a Managed Environment: Windows Error Reporting" article on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=38443.
Windows Error Reporting generates an error signature when an application is closed due to DEP. The error signature can be viewed by following the "click here" link on the Windows Error Reporting dialog. The error signature for a DEP problem has the following attributes:
|
Parameter
|
Example Value
|
Description
|
|
EventType
|
BEX
|
Indicates a buffer overflow (/GS) or DEP exception (BEX64 indicates a buffer overflow (/GS) or DEP exception on 64-bit versions of Windows)
|
|
P1
|
DEPDemo.exe
|
Name of the application executable that encountered the problem
|
|
P2
|
5.1.2600.2180
|
Version of the application executable that encountered the problem
|
|
P3
|
416725f2
|
Faulting application stamp
|
|
P4
|
DEPDemo.exe
|
Faulting module name
|
|
P5
|
5.1.2600.2180
|
Faulting module version
|
|
P6
|
416725f2
|
Faulting module stamp
|
|
P7
|
00002060
|
Fault offset (Instruction address if a module is not loaded at the faulting address)
|
|
P8
|
C0000005
|
Indicates a STATUS_ACCESS_VIOLATION exception (If this parameter is c0000409, the problem is a /GS-related fault)
|
|
P9
|
00000008
|
Indicates an execution STATUS_ACCESS_VIOLATION (00000002 indicates an execution STATUS_ACCESS_VIOLATION on 64-bit versions of Windows for the Intel Itanium architecture)
|
Finally, the Data Execution Prevention message might not be shown for some applications when they encounter a problem with DEP, regardless of the Windows Error Reporting configuration. These applications handle the STATUS_ACCESS_VIOLATION exception raised by DEP, or they install an unhandled exception filter (UEF), which overrides the default Win32 UEF. The default Win32 UEF is responsible for triggering both the Data Execution Prevention and Windows Error Reporting messages. The Data Execution Prevention message may also not be shown if an application has called the SetErrorMode() function with the SEM_NOGPFAULTERRORBOX flag.
The primary benefit of DEP is that it helps to prevent code execution from data pages such as the default heap, various stacks, and memory pools. In normal operations of the system, code is not typically executed from the default heap and stack. Hardware-enforced DEP detects code that is running from these locations and raises an exception when execution occurs. If the exception is unhandled, the process will be terminated. Execution of code from protected memory in kernel mode results in an error.
Although terminating a process or causing the system to fail with an error do not appear to be ideal experiences, this helps prevent malicious code from executing. Preventing malicious code from executing on the system may prevent damage to the system or propagation of malicious code whose harmful effects could easily exceed those of a terminated process or system error.
DEP can help prevent some exploits in which a virus or other attack has injected a process with executable code and then attempts to execute the injected code. On a system with DEP, execution of the injected code should result in an exception. Software-enforced DEP can help mitigate exploits of exception handling mechanisms within Windows.
A secondary benefit of DEP relates to good engineering and best practices for application and driver developers. DEP forces developers to avoid executing code out of data pages without explicitly marking the pages as executable.
Application Compatibility
Some application behaviors are expected to be incompatible with DEP. Applications that perform dynamic code generation (such as just-in-time code generation) and that do not explicitly mark generated code with Execute permission might have compatibility problems with DEP. Applications that are not built with SafeSEH must have their exception handlers located in executable memory regions.
Applications that attempt to violate DEP will receive an exception with status code STATUS_ACCESS_VIOLATION (0xC0000005). If an application requires executable memory, it must explicitly set this attribute on the appropriate memory by specifying PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE or PAGE_EXECUTE_WRITECOPY in the memory protection argument of the Virtual* memory allocation functions. Heap allocations using the malloc() and HeapAlloc() functions are non-executable.
Driver compatibility
Driver compatibility issues with DEP mostly center on PAE mode-induced compatibility issues.
.gif) Note |
|
PAE is required only on systems running 32-bit versions of Windows with processors that support hardware-enforced DEP. |
On its own, DEP might create compatibility problems with drivers that perform code generation or use other techniques to generate executable code in real time. Although many drivers with such behavior would have been fixed — as DEP is "always on" for drivers loaded on 64-bit versions of Windows — there is no guarantee that all drivers have been updated. However, there are few drivers that employ these techniques, and it is not expected that DEP alone will cause a large quantity of driver compatibility problems.
The primary driver compatibility concern is running Physical Address Extension (PAE) mode on 32-bit systems. PAE mode enables processors to address greater than 4 gigabytes (GB) of memory. The primary difference between PAE memory paging and non-PAE memory paging schemes is the extra level of paging that is required in PAE mode (three levels instead of two).
Some drivers might fail to load if PAE is enabled, because the device might be unable to perform 64-bit addressing or the drivers might assume that PAE mode requires more than 4 GB of random access memory (RAM). Such drivers expect that they will always receive 64-bit addresses when in PAE mode and that they or their device are incapable of interpreting the address.
Other drivers might load in PAE mode but cause system instability by directly modifying system page table entries (PTEs). These drivers expect 32-bit PTEs, but receive 64-bit PTEs in PAE mode instead.
The largest driver PAE compatibility issue involves direct memory access (DMA) transfers and map register allocation. Many devices that support DMA, usually 32-bit adapters, are not capable of performing 64-bit physical addressing. When run in 32-bit mode, the device can address all physical address space. In PAE mode, it is possible that data would be present at a physical address greater than 4 GB. To allow devices with these constraints to function in this scenario, Windows 2000 Server and later operating systems provide double-buffering for the DMA transaction by providing a 32-bit address that is indicated by a map register. The device can perform the DMA transaction to the 32-bit address and the kernel copies the memory to the 64-bit address that is provided to the driver.
When the system runs with PAE disabled, drivers for 32-bit devices never require their map registers to be backed by real memory. This means that double-buffering is not necessary, since all devices and drivers are contained within the 32-bit address space. Based on testing of drivers for 32-bit devices on 64-bit processor–based computers, it is expected that most client-tested, DMA-capable drivers expect unlimited map registers.
To constrain compatibility issues, Windows Server 2003, Standard Edition with Service Pack 1, includes hardware abstraction layer (HAL) changes that mimic the 32-bit HAL DMA behavior. The altered HAL grants unlimited map registers when the system is running in PAE mode. In addition, the kernel memory manager ignores any physical address above 4 GB. Any system RAM beyond the 4 GB barrier would be made unaddressable by Windows and be unusable in the system. By limiting the address space to 4 GB, devices with 32-bit DMA bus master capability will not see a transaction with an address above the 4 GB barrier. Because these changes remove the need to double-buffer the transactions, they avoid a class of bugs in some drivers related to proper implementation of double buffering support.
Note that the PAE behavior of Windows Server 2003, Enterprise Edition with Service Pack 1, and Windows Server 2003, Datacenter Edition with Service Pack 1, is unchanged from the versions without the service pack.
As a result of these changes to the HAL and memory manager, the impact to device driver compatibility is expected to be minimal on systems running Windows Server 2003 with Service Pack 1 with DEP enabled.
System compatibility
A final DEP compatibility concern derives from systems with PAE mode enabled, even though they may not be designed for more than 4 GB of physical RAM. During internal testing Microsoft has noticed that some systems with processors that support hardware-enforced DEP fail to start up or have other stability issues when the processor is running in PAE mode.
PAE mode is a requirement for leveraging the NX processor feature. Therefore, system designers and firmware engineers should be aware that even though the system’s chipset and firmware may not have been designed to support more than 4 GB of physical RAM, the system may be running in PAE mode.
Of particular concern is system firmware that interprets page table entries to determine instructions executed by the operating system. Page table entries are extended to 64 bits in length when the processor is running in PAE mode. System designers and firmware developers are encouraged to contact their processor and chipset vendors for more information about how to safely determine instructions executed by the operating system.
System designers working with AMD processors can obtain more information in the "BIOS and Kernel Developer’s Guide for AMD Athlon 64 and AMD Opteron Processors." To obtain this paper, go to the AMD Athlon 64 Web site at http://go.microsoft.com/fwlink/?LinkId=28165 and click "BIOS and Kernel Developer’s Guide for AMD Athlon 64 and AMD Opteron Processors."
Intel does not make detailed information about System Management Mode (SMM) available publicly. System designers working with Intel processors are encouraged to contact Intel directly for more information.
For more information regarding Windows support for PAE mode, see "Physical Address Extension - PAE Memory and Windows" on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=45912.
Applications that require executable regions of memory must use the PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE, or PAGE_EXECUTE_WRITECOPY attributes when allocating memory. Additionally, applications cannot execute from the default process heap or the stack. Most applications that perform actions incompatible with DEP will need to be updated to be compatible. Applications must also be built with SafeSEH or ensure their exception handlers are located in memory explicitly marked as executable.
An application can use the VirtualAlloc() application programming interface (API) function to allocate executable memory with the appropriate memory protection options. At a minimum, the PAGE_EXECUTE memory protection option should be used. After the executable code has been generated, it is recommended that the application set memory protections to disallow write access to the allocated memory. Applications can disallow write access to allocated memory using the VirtualProtect() API function. Disallowing write access ensures maximum protection for executable regions of process address space.
If a malicious process attempts to insert code into an executable region, the access would result in a STATUS_ACCESS_VIOLATION write exception. The application should attempt to make the executable regions of its address space as small as possible. This would result in a smaller attack surface through which executable memory could be injected into the process address space and be executed.
Additionally, sophisticated applications can control the layout of their virtual memory and create executable regions. These applications should attempt to locate executable regions in a lower memory space than non-executable regions. The purpose of locating executable regions below non-executable regions is to protect a buffer overflow from overflowing into executable memory.
A small number of executables and libraries may contain executable code in a data section of the image file. In some cases, applications may place small segments of code (commonly referred to as thunks) in the data sections. However, DEP will mark sections of the image file loaded in memory as non-executable unless the section has the executable attribute applied.
Therefore, executable code in data sections should be moved to a code section, or the data section containing the executable code should be explicitly marked as executable. The executable attribute, IMAGE_SCN_MEM_EXECUTE (0x20000000), should be added to the Characteristics field of the corresponding section header for sections that contain executable code.
The Microsoft linker that is distributed with Microsoft Visual Studio products can add the executable attribute to a section using the /SECTION linker option. The /SECTION linker option has the following format:
/SECTION:
Name
,[E][R][W][S][D][K][L][P][X][,ALIGN=#]
The E value indicates the executable attribute (0x20000000). More information about /SECTION and other Microsoft linker options is available on the MSDN Web site at http://go.microsoft.com/fwlink/?LinkId=28167.
Additionally, the Microsoft COFF Binary File Editor (Editbin.exe) utility can be used to change the section attributes of an existing image. The Editbin utility has a /SECTION option with the following format:
/SECTION:
Name
[=
newname
][,[[!]{CDEIKOMPRSUW}][A{1248PTSX}]]
The C and E values indicate code and executable attributes respectively. For more information about the Editbin utility and the /SECTION option, see the MSDN Web site at http://go.microsoft.com/fwlink/?LinkId=28168.
Microsoft has provided service packs for Microsoft .NET Framework version 1.0 and version 1.1 to take advantage of DEP in Windows Server 2003 with Service Pack 1. Applications that use the Microsoft .NET Framework will continue to function normally, but will not benefit from DEP if it is enabled unless the appropriate Microsoft .NET Framework Service Pack has been installed.
Microsoft encourages application developers who redistribute the Microsoft .NET Framework to update to Microsoft .NET Framework version 1.0 Service Pack 3 or version 1.1 Service Pack 1, which take advantage of DEP.