荔园在线

荔园之美,在春之萌芽,在夏之绽放,在秋之收获,在冬之沉淀

[回到开始] [上一篇][下一篇]


发信人: presses (云仔), 信区: WinNT
标  题: 白皮书(3)内存保护技术
发信站: 荔园晨风BBS站 (Sat Aug 14 18:24:41 2004), 站内信件

第 3 部分:内存保护技术

发布日期: 2004年08月02日

发布者 Starr Andersen,技术撰稿人, 和 Vincent Abella,技术编辑

本文是 “ Windows XP Service Pack 2 功能变更” 白皮书的第三部分,详细介

了 Windows?XP Service Pack?2 的内存保护技术。您可以通过 Microsoft 下载中

心获得本白皮书的其余部分:http://go.microsoft.com/fwlink/?LinkId=28022
[
英文]。

本文档为预备性文档,适用于针对 32 位版本的 Windows XP Professional 和
Wi
ndows XP Home Edition 的 Microsoft Windows XP Service Pack 2 (SP2) 的
Be
ta 版本。文档没有介绍本服务包的最终版本将要包括的所有功能。

本页内容

 数据执行保护

数据执行保护

数据执行保护有何功能?

数据执行保护(DEP)将进程中的所有内存位置均标记为不可执行,除非该位置明

包含可执行代码。有一种攻击会试图在不可执行内存位置中插入和执行代码。通过

截取这些代码并产生异常,数据执行保护有助于防范这些攻击。

数据执行保护依靠处理器硬件标记内存,内存会带有一个属性,表明不应该执行此

处的代码。数据执行保护以每个虚拟内存页面为基础发挥作用,大多数情况下,会

修改页面表入口(PTE)中的一个数据位,对内存页加以标记。

具体的 DEP 硬件实现和虚拟内存页面标记根据处理器架构的不同而所有变化。但

,如果从一个带有相应属性集的页面执行了代码,支持数据执行保护的处理器将产

生一个异常。

Intel 和 Advanced Micro Devices(AMD)都已经针对数据执行保护定义和销售了

兼容 Windows 的架构。Windows 支持 AMD 平台以及 Intel Itanium 处理器家族

IPF)上的 DEP。

32 位版本的 Windows(从 Windows XP Service Pack 2 开始)利用了 AMD 定义

不可执行页面保护(NX)处理器特性。为了使用 NX 处理器特性,处理器必须在物

理地址扩展(Physical Address Extension,PAE)模式下运行。64 位版本的
Win
dows 在 64 位扩展上使用了 NX 处理器特性,并且在 IPF 处理器上使用了访问权

限页面表入口(PTE)的特定值。

我们希望未来的 32 位和 64 位处理器能够提供数据执行保护功能。Microsoft 正

在与处理器厂商紧密合作,努力解决与现有应用程序和驱动程序的兼容性问题,推

动 DEP 技术得到采纳和发展。

本特性适用于哪些用户?

应用程序和驱动程序开发人员应该了解数据执行保护以及能够在一个支持平台上运

行的软件应该具备的条件。执行 just-in-time(JIT)代码生成,或者从默认的进

程堆栈或堆执行内存的应用程序应该对 DEP 的要求加以认真对待。

我们鼓励驱动程序开发人员重视支持数据执行保护的平台上的 PAE 模式。
Windows
 XP Service Pack 2 上的 PAE 模式经过修改,以提高驱动程序的兼容性。

XP Service Pack 2 中的本特性增加了哪些新的功能?

32 位版本的 Windows 和应用程序上的数据执行保护

我们预计,运行 Windows 和 Windows 兼容应用程序的许多计算机在未来都将配备

运行 32 位版本的 Windows 的 32 位处理器。但是,新的 64 位扩展处理器(例

 AMD Opteron 和 Athlon 64)同时支持 32 位和 64 位操作模式(分别是旧有和

机)。这些 32 位处理器和 64 位处理器的混合体能够运行在纯粹的旧有环境(
32
 位的操作系统和 32 位的应用程序)下,并且在启用了 PAE 模式之后具有数据执

行保护功能(利用非执行页面保护特性)。

详细说明

尽管存在几点不同之处,Windows 上的数据执行保护的整体行为在 32 位和 64 位

的 Windows 版本中完全相同。为了向应用程序和驱动程序的开发人员提供一致性

内存保护模型(包括数据执行保护)被设计为在 32 位和 64 位版本的 Windows

具有相同的行为。

应用程序的开发人员应该意识到用户模式中的 DEP行为。一个用户模式下的数据执

行保护异常会导致 Windows 系统上的一个 STATUS_ACCESS_VIOLATION(
0xc000000
5)。异常信息的第一个参数(位于 EXCEPTION_RECORD 结构中)包含了所发生的
访
问违例的类型。如果 ExceptionInformation[0] 为 8,说明访问违例是一个执行

例。

在大多数进程中,STATUS_ACCESS_VIOLATION 异常是一个无法处理的异常,会导致

进程的中止。

数据执行保护还适用于内核模式的驱动程序。针对内核模式中的内存区域的 DEP

能有选择地启用或禁用。在 32 位版本的 Windows 中,数据执行保护默认情况下

用于堆栈。这一点与 64 位版本的 Windows 内核模式存在差异,对于 64 位版本

 Windows,堆栈、页面池以及会话池都应用数据执行保护。

在启用 DEP 的时候,不允许设备驱动程序从堆栈中执行代码。内核模式中的
DEP
访问违例会导致一个检测错误(bugcheck) 0xFC:
ATTEMPTED_EXECUTE_OF_NOEXE
CUTE_MEMORY

为什么此项修改很重要,它有助于缓解哪些威胁?

数据执行保护的主要优点在于:它可以防止代码从数据页(例如默认堆、各种堆栈

以及内存池)中被执行。在系统的正常操作中,代码一般不会从默认的堆或堆栈中

执行。DEP 会检查到从这些位置运行的代码,并且在代码被执行时产生一个异常。

如果异常没有得到处理,进程将终止。从受保护位置执行的代码在内核模式中会导

致一个检测错误。

虽然终止进程或者导致系统发生带有检测错误的失败看起来并不是一个理想的办法

,但是这种做法可以防止恶意代码在系统中执行。而防止恶意代码被执行可以阻止

系统受损或者恶意代码肆意传播,这些代码造成的有害影响远远超过因检测错误终

止进程造成的影响。

DEP 有助于缓解某种类型的安全漏洞。特别是,数据执行保护可以防止病毒或者其

他攻击被注入到带有附加代码的进程中,然后试图执行被注入的代码。在支持
DEP
 的系统上,被注入代码的执行会导致一个异常。

DEP 的另外一个优点与好的应用程序和驱动程序设计以及最佳实践有关。在没有明

确地将页标记为可执行的情况下,数据执行保护可以强迫开发人员避免执行页面以

外的代码。

工作方式有何不同吗?

应用程序兼容性

某些应用程序的行为可能和数据执行保护不兼容。执行动态代码生成的应用程序(

例如 Just-In-Time 代码生成)以及不能明确地将生成的代码标记为可执行代码的

程序可能会出现与数据执行保护不兼容的问题。

试图违反 DEP 的应用程序会得到一个异常,状态代码为
STATUS_ACCESS_VIOLATIO
N (0xC0000005)。如果应用程序需要可执行的内存,它必须在虚拟*内存分配函数

内存保护参数中指定 PAGE_EXECUTE、PAGE_EXECUTE_READ、
PAGE_EXECUTE_READWRI
TE 或 PAGE_EXECUTE_WRITECOPY,明确地设置相应内存的属性。使用 malloc() 和

 HeapAlloc() 函数分配的堆是不可执行的。

驱动程序兼容性

驱动程序与数据执行保护的兼容问题大多数集中在由于 PAE 模式而产生的兼容问



对于 DEP 自身,它可能会与执行代码生成工作或者使用其他技术实时生成可执行

码的驱动程序产生兼容性问题。由于 DEP 对于在 64 位版本的 Windows 上加载的

许多驱动程序来说是永远开启的,所以具有上述行为的很多驱动程序都应该进行修

正,但是没有任何承诺保证所有的驱动程序都会得到更新。但是,仅仅有几个驱动

程序应用了这些技术,我们不期望 DEP 自己会引起大量的驱动程序兼容问题。

对驱动程序兼容性的主要担心是在 32 位系统上运行物理地址扩展(Physical
Add
ress Extension,PAE)模式。PAE 模式允许处理器寻址 4GB 以上的内存空间。
PA
E 内存分页和非 PAE 内存分页模式的主要区别在于:额外的分页级别对于 PAE 模

式来说是必需的(3 个级别,而不是 2 个)。

如果启用了 PAE,某些驱动程序可能无法加载,因为设备可能无法执行 64 位寻址

,或者驱动程序可能假定 PAE 模式需要超过 4GB 内存的空间。在处于 PAE 模式

,这样的驱动程序期待总是获得 64 位地址,所以它们(或者它们的设备)无法解

释地址。

其他驱动程序可能可以在 PAE 模式中加载,但是由于直接修改 PTE 会引起系统不

稳定。这些驱动程序希望使用 32 位 PTE,但是在 PAE 模式中得到的是 64 位
PT
E。

最大的驱动程序 PAE 兼容问题设计直接内存访问(DMA)传输和映射寄存器分配。

支持 DMA 的许多设备(通常是 32 位适配器)不能执行 64 位物理寻址。在运行

 32 位模式时,设备可以寻址所有的物理地址空间。在 PAE 模式中,数据的物理

址可能大于 4GB 空间。为了让带有这些限制的设备在这种情况下正常工作。
Windo
ws 2000 Server 产品家族及其后续产品通过提供一个32 位地址(该地址由一个映

射寄存器指出),为 DMA 事务提供了双倍缓冲。设备可以在这个 32 位地址上执

 DMA 事务,然后内核将内存复制到为驱动程序提供的 64 位地址。

如果系统中的 PAE 被禁用,32 位设备的驱动程序永远不会要求它们的映射寄存器

由真实内存返回。这意味着双倍缓冲是不必要的,因为所有的设备和驱动程序都包

含在 32 位地址空间中。根据在配备 64 位处理器的计算机上针对 32 位设备开展

的驱动程序测试,我们预计大多数接受测试和支持 DMA 的客户端驱动程序都期待

得无限的映射寄存器。

为了减少兼容性问题,Windows XP Service Pack 2 包括了对硬件抽象层(HAL)

修改,模仿 32 位 HAL 的 DMA 行为。当系统运行于 PAE 模式中时,经过修改的

HAL 允许无限制的映射寄存器。另外,内核内存管理器会忽略高于 4GB 的所有物

地址。4GB 以上的所有系统内存将是不可寻址的,而且无法在系统中使用。通过将

地址空间限制到 4GB,具有 32 位 DMA 总线控制能力的设备将不会看到高于
4GB
稳定。这些驱动程序希望使用 32 位 PTE,但是在 PAE 模式中得到的是 64 位
PT
E。

最大的驱动程序 PAE 兼容问题设计直接内存访问(DMA)传输和映射寄存器分配。

支持 DMA 的许多设备(通常是 32 位适配器)不能执行 64 位物理寻址。在运行

 32 位模式时,设备可以寻址所有的物理地址空间。在 PAE 模式中,数据的物理

址可能大于 4GB 空间。为了让带有这些限制的设备在这种情况下正常工作。
Windo
ws 2000 Server 产品家族及其后续产品通过提供一个32 位地址(该地址由一个映

射寄存器指出),为 DMA 事务提供了双倍缓冲。设备可以在这个 32 位地址上执

 DMA 事务,然后内核将内存复制到为驱动程序提供的 64 位地址。

如果系统中的 PAE 被禁用,32 位设备的驱动程序永远不会要求它们的映射寄存器

由真实内存返回。这意味着双倍缓冲是不必要的,因为所有的设备和驱动程序都包

含在 32 位地址空间中。根据在配备 64 位处理器的计算机上针对 32 位设备开展

的驱动程序测试,我们预计大多数接受测试和支持 DMA 的客户端驱动程序都期待

得无限的映射寄存器。

为了减少兼容性问题,Windows XP Service Pack 2 包括了对硬件抽象层(HAL)

修改,模仿 32 位 HAL 的 DMA 行为。当系统运行于 PAE 模式中时,经过修改的

HAL 允许无限制的映射寄存器。另外,内核内存管理器会忽略高于 4GB 的所有物

地址。4GB 以上的所有系统内存将是不可寻址的,而且无法在系统中使用。通过将

地址空间限制到 4GB,具有 32 位 DMA 总线控制能力的设备将不会看到高于
4GB
的地址。因为这些修改去除了对事务的双倍缓冲的需要,它们可以避免某些驱动程

序中与正确实现双倍缓冲支持有关的的一类Bug。

由于对 HAL 和内存管理器进行了这些修改,对于支持数据执行保护的 Windows
XP
 Service Pack 2 系统,设备驱动程序兼容性受到的影响预计将降至最低

系统兼容性

最后一个对 DEP 兼容性的担心来自于支持 PAE 模式的系统,即便是它们可能并不

是针对大于 4GB 的物理内存所设计的。 Microsoft 已经在测试中注意到:当处理

器运行于 PAE 模式中时,有些配置了支持 NX 特性的处理器的系统无法顺利启动

或者具有其他稳定性问题。

PAE 模式对于利用处理器的 NX 特性是必需的。所以,系统设计人员和固件工程师

应该意识到,即使系统的芯片组和固件可能没有针对 4GB 以上的物理内存进行设

,但是系统可能也会运行在 PAE 模式下。

需要特别关注的是系统固件会解释页面表项目,确定由操作系统执行的指令。当处

理器运行于 PAE 模式中时,页面表项目的长度可以被扩展到 64 位。我们鼓励系

设计师和固件开发人员与处理器和芯片组厂商联系,获得更多关于如何安全确定由

操作系统执行的指令的信息。

使用 AMD 处理器设计系统的人员可以在 “AMD Athlon 64 和 AMD Opteron 处理

 BIOS 及内核开发指南” 中获得更多信息。为了获得该白皮书,请访问 AMD
Athl
on 64 Web 站点: http://go.microsoft.com/fwlink/?LinkId=28165 [英文] ,

后点击 “ BIOS and Kernel Developer Guide for AMD Athlon 64 and AMD
Opte
ron Processors”。

Intel 没有提供公开发布有关 System Management Mode(SMM)的详细信息。我们

建议使用 Intel 处理器设计系统的人员直接与 Intel 联系以获得更多信息。

有关 Windows 为 PAE 模式提供支持的更多信息,请参阅 Microsoft Web 站点上

 “ 物理地址扩展-PAE- 内存和 Windows” : http://go.microsoft.
com/fwli
nk/?LinkId=28166 [英文].

我应该如何解决该问题?

需要可执行内存区域的应用程序必须在分配内存时使用 PAGE_EXECUTE、,
PAGE_EX
ECUTE_READ, PAGE_EXECUTE_READWRITE、或 PAGE_EXECUTE_WRITECOPY 属性。此外

,应用程序不能从默认的进程堆或堆栈执行代码。执行的操作与数据执行保护不兼

容的大多数应用程序都需要经过升级,以实现兼容。

应用程序可以使用 VirtualAlloc() 应用程序编程接口(API),利用相应的内存

护选项来分配可执行内存。至少,应该使用 PAGE_EXECUTE 内存保护选项。在生成

了可执行代码后,我们建议应用程序设置内存保护,禁用对已分配内存的写访问。

应用程序可以使用 irtualProtect() API,禁止写入已分配的内存。禁止写访问可

以确保最大限度地为进程地址空间的可执行区域提供保护。

如果某个恶意进程试图在可执行区域中插入代码,这种访问将导致一个
STATUS_AC
CESS_VIOLATION 写入异常。应用程序应该尽可能地确定地址空间的可执行区域。

过决定哪些可执行内存能够被注入到进程空间并执行,可以减小攻击表面。

此外,成熟的应用程序可以控制虚拟内存的布局和创建可执行区域。这些应用程序

应该试着在一个比非执行区域更低的内存空间定位可执行区域。在非执行区域以下

定位可执行区域的目的在于避免缓冲区溢出到可执行内存中。

少量的可执行程序和库可能会在图像文件的数据段中包含可执行代码。在部分情况

下,应用程序可以在数据段中放置一般被称为 thunks 的小段代码。然而,数据执

行保护会将加载到内存中的图像文件标记为不可执行,除非在数据段上应用可执行

属性。

因此,数据段中的可执行代码应该被迁移到代码段,否则包含可执行代码的数据段

应该明确被标记为可执行。可执行属性 IMAGE_SCN_MEM_EXECUTE(0x20000000)应

该被添加到包含可执行代码的相应段的头部的 Characteristics 字段中。

Microsoft VisualStudio 产品附带的 Microsoft 链接程序可以使用 /SECTION 链

接器选项将属性添加到段中。 /SECTION 链接器选项具有如下格式:

/SECTION:Name,[E][R][W][S][D][K][L][P][X][,ALIGN=#]

值为 E 表明可执行属性 (0x20000000)。有关 /SECTION 以及其他 Microsoft 链

器选项的更多信息可以在 MSDN Web 站点上找到: http://go.microsoft.
com/fwl
ink/?LinkId=28167 [英文].

此外,Microsoft COFF Binary File Editor (Editbin.exe) 工具可以用来修改现

有映像的段属性。Editbin 工具有一个 /SECTION 选项,格式如下:

/SECTION:Name[=newname][,[[!]{CDEIKOMPRSUW}][A{1248PTSX}]]

E 和 C 值分别指出了代码和可执行属性。有关 Editbin 实用工具和 /SECTION 选

项的更多信息,请参看 MSDN Web 站点的以下地址: http://go.microsoft.
com/f
wlink/?LinkId=28168 [英文].

Microsoft 计划升级 Microsoft .NET Framework v1.0 和 v1.1,以利用
Windows
 XP SP2 中的 DEP具有的诸多好处。 依赖Microsoft .NET Framework 的应用程序

将可以继续正常工作,但是无法从数据执行保护(如果支持此特性)中受益。

Microsoft 鼓励应用程序开发人员再次分发 Microsoft .NET Framework,以升级

Microsoft.NET Framework v1.0 Service Pack 3 和(或)v1.1 Service Pack 1

从而在 DEP 可用之时对其加以利用。这些 .NET Framework 服务包当前仍处于
Be
ta 测试阶段,将于今后几个月正式发布,以便于及时升级。

Windows XP Service Pack 2 增加或修改了哪些设置?

系统级的数据执行保护可以使用新的 boot.ini 开关参数 /NOEXECUTE 和
/EXECUT
E 来启用和禁用。

? /NOEXECUTE 标志启用整个系统的数据执行保护,而且能够针对具体的应用程序

用数据执行保护。



? /EXECUTE 标志禁用整个系统的数据执行保护,无论具体应用程序的数据执行保

被启用还是禁用。



出于兼容性的考虑,可以有选择地禁用 32 位程序的 DEP。Windows XP Service
P
ack 2 提供了名为 DisableNX 的新的应用程序兼容性修补。DisableNX 兼容性修

可以针对它所适用的程序禁用数据执行保护。

可以使用Application Compatibility Toolkit(应用程序兼容性工具包),将
Di
sableNX 兼容性应用于某个应用程序。有关 Windows 程序兼容性的更多信息,请

阅 icrosoft Web 站点上的 “ Windows Application Compatibility ” :
http
://go.microsoft.com/fwlink/?LinkId=23302 [英文].

此外,Windows XP Service Pack 2 还包括了一个控制面板项目,允许用户配置系

统上的 DEP。您可以使用该控制面板项目启用或禁用整台计算机的 DEP,以及有选

择地禁用单个应用程序的数据执行保护。有关使用该特性的详细信息,请参阅
Win
dows XP Service Pack 2 的联机帮助。
--
我好咸湿

※ 来源:·荔园晨风BBS站 bbs.szu.edu.cn·[FROM: 210.21.224.236]


[回到开始] [上一篇][下一篇]

荔园在线首页 友情链接:深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店