SSD in Windows Vista

ReadyBoost技术是和微软的另一个新技术Superfetch（超级预读取）技术紧密相关的。Superfetch技术简单的说就是系统监视程序运行习惯、周期等情况，并自动将应用程序存放在硬盘中的交换文件预先读取到内存页面中去，使用户经常使用的程序在启动时比以往更快，超级预读取技术对于加速程序运行有很多的好处，正是这项新技术增加了物理内存的需求，这就是Vista为什么耗费内存资源的原因。如果物理内存的容量不足就会直接影响了该技术发挥作用，但是这项技术却是很有用的，尤其是在运行大型软件的时候就更明显了。
ReadyBoost技术实际上就是针对超级预读取技术的一种补充完善方案，为了在内存容量较小时也能发挥超级预读取技术的特性，Vista在内存和硬盘之间独立设置了一个闪存缓冲区，来替代内存作为缓存，存放应用程序需要读取的交换文件。所以在ReadyBoost技术中，U盘等闪存盘是用于存放中转的交换文件的，而不是用于存放程序随机调用的文件的，这和内存的角色有本质上的区别。
正是ReadyBoost技术的这个特点，他只是解决内存容量不够的临时措施，并不能从根本上解决问题，如果你的物理内存只有512M或以下，采用ReadyBoost技术可以明显提升应用程序在读取大型文件时的速度，但是不会给系统本身性能带来明显的变化，你的内存如果是1G以上就大可不必了。而且ReadyBoost技术对闪存盘的要求很高，他要求闪存在随机读取4KB文件时最低速度不能低于2.5MB/s，随机写入512KB文件时最低速度不能低于1.75MB/s但是要想更好地发挥ReadyBoost技术的优势，这两项指标应达到5MB/s和3MB/s。现在在市面上的U盘，只有标注了ReadyBoost标志的产品才能保证启用ReadyBoost加速功能。
首先要明白一个问题 这项被称为是readyboost的技术并不是把闪存当内存用,只不过是一项加快硬盘读取的技术而已,众所周知硬盘在大容量存储方面和传输速度方面性能优越,但是在随机读取方面却不如闪盘,而这项技术不过是把一些原来保存在硬盘上的存取较多的东西放在闪盘上,读取时优先查找闪盘里的东西,如果没有在去硬盘里找 以此来打到提速目的,但是他的效果相对硬盘有很大提升 现对内存还是很慢的
这项技术对闪存有技术要求的 并非所有的闪盘都支持 不过目前主流的闪盘应该差不多都支持. 切记 不要用mp3mp4等用在这个技术 或者用来装虚拟光驱等的闪盘也不要用 有冲突的
USB2.0的传输速度也不过480Mpbs，理论上传输速度最大值为60M/s，跟内存差老远呢！
ReadyBoost是Windows Vista提供的一个相当引人注目的功能：即通过具有USB 2.0接口的USB闪存或U盘来加速Windows Vista的性能，具寤票闶鞘褂肬SB存储器上的存储究竟来扩充系统内存，可以帮助内存不足的PC以相当简便的方式提高系统的整体性能。
不过，对于能够应用ReadyBoost的U盘(USB存储器)，微软给出了似乎有些苛刻的规格：
1、4K随机读取时不低于2.5MB/s或512K随机写入时不低于1.75MB/s 的传输率；
2、64 MB 到 8 GB 空闲空间；
3、U盘总容量不低于256 MB。
当然，这样的规格要求还是必需的，毕竟，如果USB存储器的读写速度过慢的话，贸然应用ReadyBoost恐怕不仅不会提高系统性能，甚至可能会在一定程度上拖慢整个系统的速度。
但是，U盘是否能够满足所谓的“4K随机读取时不低于2.5MB/s或512K随机写入时不低于1.75MB/s 的传输率”只能通过相应的测试软件才能看到结果，而在用户购买U盘时是不会在U盘的说明书中看到相应规格的。
细心的朋友在看过Windows Vista使用教程后可能已经发现，大家使用的测试系统配置相当低，事实上，用的是一台闲置的PC，内存只有384MB，连最基本的Windows Vista Capable要求都没有达到——呵呵，只是测试嘛——而对于这样的系统，如果能通过ReadyBoost来改善内存不足的窘境无疑是极有意义的。
不幸的是，大家测试了数款U盘，容量从512MB到2GB，其中不乏所谓的名厂产品，但均不能应用ReadyBoost，不知道是大家运气不好还是U盘太滥了。说老实话，考虑到国内混乱的U盘市场，大家怀疑其中的绝大多数恐怕与ReadyBoost无缘。
Windows下更多的内存意味着更多的应用程序可以被运行，而无需在硬盘上创建慢速的交换文件，毕竟RAM要比我们的磁盘快得多。随着USB 接口的记忆棒（以及其他类型的便携式存储器）变得日益流行和便宜，Microsoft已经决定在Vista中加载这类存储器的选项以便加快用户的PC。如果与SuperFetch相结合，ReadyBoost这项技术会使得加载应用程序的速度得到极大的提高。那么至于ReadyBoost的更深入信息大家又知道多少呢？
下面请看微软副总裁im Allchin为您带来的精彩讲述：
如果存在什么东西可以真正帮助Windows Vista上的程序运行得更快的话，那就是内存。当在一台1GB内存的计算机上比较Windows XP和Windows Vista性能的时候，Windows Vista通常将比Windows XP更快（至少相当）。然而，大家都知道这样一个事实，在一台512内存的计算机上，Windows XP平台的程序将可能更加迅速。为什么呢？这主要是因为Windows Vista中的许多功能占用了太多的内存，如数据索引、AERO用户界面等等。机器上的内存越少，操作系统随机访问磁盘的频率将越高。如果在Windows XP平台上，你的内存刚好能够满足程序的话，那么在Vista中这些内存是远远不够的，这一切，将使系统性能大打折扣。
我们对Windows Vista中的内存管理器进行了重新设计。因此，如果你给予系统的内存越多，系统将通过一个叫做SuperFetch的技术来更加有效地利用内存。SuperFetch技术是Windows Vista的智能启发式内存管理系统的一部分。在一台1GB甚至更多内存的机器上，Windows Vista的性能将远优于Windows XP－－尤其是当你使用该机器一段时间之后－－因为Windows Vista将自动熟悉你最经常使用的部分，并对其做出优化。
我知道许多现存电脑内存至少为512MB，但我还是非常希望PC制造商们能够推出更大内存的电脑。虽然现在内存的价格已经有所降低，但是我知道，许多人还是不情愿打开他们的电脑，安装更多的内存。但是，在有了Windows ReadyBoost之后，如果你拥有一个闪存盘（比如一个U盘或者一张SD卡），那么你可以利用这些来加速你的Vista。而你所需要做的，仅仅是简单地插入一个闪存盘，然后，Windows Vista将使用Windows ReadyBoost去利用闪存提高性能。
虽然闪存盘中有一些存储空间，但是Windows Vista并不是真正的使用这些存储空间来增加计算机中的主要系统内存的。相反，ReadyBoost使用闪存来存储内存管理器所使用的信息。如果你在一个内存有限的系统上运行许多程序的话，Windows ReadyBoost将使用闪存盘来创建一个虚拟内存的拷贝。虚拟内存的使用频率并没有内存那么高，但其存取速度比硬盘要快得多。这里，非常酷的一点就是，存储在闪存中的内存同样也存储在硬盘上，因此如果你移除该闪存盘，内存管理器接受到该变化之后将自动转移至硬盘。在从ReadyBoost中获得性能的同时，你将不如丢失任何数据，且不会出现任何中断。同时，因为Windows Boost缓存在闪存盘中的数据是经过AES-128加密过的，所以即使闪存盘丢失或者被盗，你也不必担心敏感数据的泄漏。另外，内存管理器在将虚拟内存数据写入闪存中之前，对其进行压缩，这样可以存储更多数据。
那么，如果你想使你电脑上的Windows Vista运行更快－－相当简单－－通过任何USB 2.0或者PCI接口接上你的闪存盘，当自动运行界面出现时，选择“使用ReadyBoost加速我的系统”。你的闪存盘至少需要230MB以上空闲空间，并且一些闪存盘的速度不是很快，不能支持Windows ReadyBoost。
参考资料：http://www.cpcw.com/disp.php?aid=14198&cid=73
闪盘当内存? Vista ReadyBoost再解析CNET中国·PChome.net·转载  作者: 走进中关村   时间:2007-03-24
ReadyBoost的再审视
前言：只有512MB内存的笔记本采用Vista Home Premium系统，在使用中可能会因为内存容量刚刚满足微软程序员们设置的Vsita最低安装需求而显得运行缓慢。加装内存的确是一项不错的计划，可是又有多少人真的会不辞劳苦的去购买并安装呢？前一段时间，Vista系统中一项名为ReadyBoost的功能号称可以将闪存盘变成内存使用，引起了不少的争议。当时intozgc也做了类似的测试，并得出了ReadyBoost功能并无所作为的结论。 最近又有部分用户在评测后，对此功能对系统的提升有一定的称赞。那么到底这个ReadyBoost对系统有甚么影响呢？让我们再度来审视这个充满了神奇色彩的Vista新功能吧。
关键词：SuperFetch  ReadyBoost  ReadyBoot  闪存盘
虽然微软 一直力推新系统Vista，可是直到目前为止，依然有相当多在IT产品卖场选购笔记本电脑类产品的用户，看到产品预装了Vista系统直接就PASS掉了。四毛走访卖场的时候，听到了 不少用户对此的解释是：现在笔记本电脑的配置完全跟不上Vista的要求，我才不要装呢！可见得，微软的公关们还要继续努力！
当然了，笔记本电脑运行速度慢一方面是硬件方面的历史问题。笔记本电脑先天的构架原因就决定其无法达到同时代台式机的强劲性能。而另外一方面则是软件载入速度。很多用户对电脑运行速度最 敏感的就是程序的载入速度。如果程序从点击使用到可以正常使用之间的时间差比较小，则大部分用户就会认同这台电脑的运行速度很快，性能比较强劲。而微软新操作系统Vista内的 这项新功能 ReadyBoost 就是为了迅速提升一些配置不够强大的整机运行速度而出现的。

当然了，性能与速度之间的关系属于非充分必要关系（两者之间有联系，但并非成比例递增）。我们之前曾对对内置1GB内存的笔记本做过 相关的测试，发现ReadyBoost对整机运行没有明显的作用，而且完全对性能没有任何提升。可是对照外国一些评测人员报告说ReadyBoost有一些电脑运行速度的促进能力，我们对此有了一丝疑惑。
本着没有调查就没有发言权的态度，我们再度针对ReadyBoost作出了相关的测试，检验其是否真如国外评测人员所言。
ReadyBoost对系统的影响：原理篇一
在评测之前，我们还是先了解一点ReadyBoost的原理。之前测试的时候，我们在微软网站上查阅相关ReadyBoost的文献，发现其对此项功能的介绍也非常少。今天重新查找到了一些相关的文献了，给大家介绍一下。
如今，由于CPU和内存的速度越来越快，而硬盘却一直没有明显的变化，渐渐成为整台系统性能的瓶颈。

始终不变的机械式硬盘依然是最广大消费者忠实的伙伴
首先是磁盘的磁头寻道时间一般约为10毫秒，现今的高频处理器只能等待其慢慢的读取写入数据，有些漫长。尽管内存是用于缓存数据的理想选择，但它的成本还是比较高的。而常见的闪存较为便宜，而且随机读取的速度最高可比常规硬盘快10倍。因此，Windows Vista 中加入了一个名为ReadyBoost的功能来利用闪存存储数据，方法是在这些设备上创建一个逻辑上介于内存和磁盘之间的中间缓存层。
ReadyBoost 由一个在 %SystemRoot%System32Emdmgmt.dll 中实现的运行于主机进程中的服务和一个卷过滤器驱动程序 (%SystemRoot%System32DriversEcache.sys) 组成。（Emd 是“外部内存设备”的简称，也是 ReadyBoost 在开发期间所使用的名称。）当您将 USB类或者SD卡之类的闪存设备插入系统中后，ReadyBoost 服务会查看该设备以确定其性能特征并将测试结果存储在 HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentversionEmdmgmt 中

如果您使用设备进行缓存处理，并且新设备大小介于 256MB 和 32GB 之间、对于 4KB 随机读取的传输率为 2.5MB/s 或更高、对于 512KB 随机写入的传输率为 1.75MB/s 或更高，则 ReadyBoost 将询问您是否想要将部分存储空间用于进行磁盘缓存。（尽管 ReadyBoost 可以使用 NTFS，它还是会将最大缓存大小限制在 4GB，以适应 FAT32 限制。）如果您同意，该服务便会在该设备的根目录下创建一个名为 ReadyBoost.sfcache 的缓存文件，并要求 SuperFetch 在后台预先填充缓存。

设置readyboost缓存大小
在 ReadyBoost 服务对缓存进行初始化之后，Ecache.sys 设备驱动程序会将所有读写数据截取到本地硬盘卷（例如 C:），并将要写入的所有数据复制到该服务创建的缓存文件中。Ecache.sys 会将数据压缩，压缩比通常达到 2:1，这样，4GB 的缓存文件通常将包含 8GB 数据。驱动程序会联合使用高级加密标准 (AES) 和一个随机生成的每引导会话密钥对其写入的每个块进行加密，以在将设备从系统移除的情况下保证缓存中数据的保密性。
当 ReadyBoost 确定可从闪盘介质内的缓存比硬盘内的缓存更能满足随机读取需求时，它便会从闪盘介质内随机读取数据。当然了，硬盘的有序读取访问要明显胜过闪存，因此，当ReadyBoost侦测到有系统正在使用有序访问数据的时候，将直接从磁盘读取，即使该数据同样位于闪盘介质内的缓存中。
上面的解释就是为什么 ReadyBoost 可以加速系统运行速度的原因。而在文献中还提到了一项功能 SuperFetch ，同时另外一项 ReadyBoot 功能也是依靠 ReadyBoost 提供的服务来提升速度的。
ReadyBoost对系统的影响：原理篇二
SuperFetch
在Windows XP 中对物理内存的管理采用了预读取管理，该功能基于应用程序启动时执行的大量磁盘读写的需求，向物理内存预加载可能用到的数据，从而提升应用程序启动性能。而在Windows Vista 中，则时凭借 SuperFetch 来实现分析历史信息和前瞻性内存管理来增强“least-recently accessed”（最近最少访问的）方法的来管理内存，显得更加智能，高效。
SuperFetch 作为在服务主机进程 (%SystemRoot%System32Svchost.exe) 内运行的 Windows 服务在 %SystemRoot%System32Sysmain.dll 中实现。该方案依赖于内存管理器提供的支持，因此它可以检索页面使用历史，以及引导内存管理器将来自磁盘文件或分页文件的数据和代码预加载到“待机列表”中，并为各页面指定优先级。SuperFetch 服务基本上是将页面跟踪扩展到曾经存储在内存中但已被内存管理器重新使用以为新数据和代码让出空间的数据和代码。该服务会将这一信息存储在 %SystemRoot%Prefetch 目录中扩展名为 .db 的场景文件中（位于用于优化应用程序启动的标准预取文件旁边）。在对内存使用情况的这种深入了解基础上，SuperFetch 可在物理内存变为可用时预加载数据和代码。
只要内存变为可用（例如，当某应用程序退出或释放内存时），SuperFetch 便会要求内存管理器提取最近被释放的数据和代码。这个过程的速度缓慢而且硬盘读写的优先级为“非常低”，以便预加载操作不会影响用户或其他活动应用程序。因此，如果您离开计算机去享用午餐，并且某个内存密集型的后台任务导致活动应用程序的代码和数据在您离开期间被释放，则 SuperFetch 通常会在您回来之前将所有或大多数代码和数据返回到内存中。SuperFetch 还包含了对休眠、待机、快速用户切换 (FUS) 和应用程序启动的特定场景支持。例如，当系统处于休眠状态时，SuperFetch 会将数据和代码存储在它预期（基于以前的休眠）将在后续恢复期间被访问的休眠文件中。相比之下，当您恢复 Windows XP 时，先前缓存的数据在被引用时必须从磁盘重新读取。
ReadyBoot
如果系统的内存不足 512MB，则 Windows Vista 会使用与 Windows XP 一样的引导时预读取。但如果系统的内存超过为 700MB 或以上，它便会使用 RAM 内缓存来优化引导进程。缓存的大小取决于可用 RAM 总量，但这足以创建适当的缓存，并还可以为系统留出要顺利引导所需的内存。
在每一次引导后，ReadyBoost 服务会使用空闲 CPU 时间来为下一次引导计算引导时缓存计划。它会分析来自前五次引导的文件跟踪信息，并标识出访问了哪些文件以及这些文件在磁盘上的位置。该服务将已处理的跟踪信息以 .fx 文件形式存储在 %SystemRoot%PrefetchReadyboot 中，并将缓存计划保存在 HKLMSystemCurrentControlSetServicesEcacheParameters 下的 REG_BINARY 值（这些值针对它们所引用的内部磁盘卷而命名）中。
缓存由实现 ReadyBoost 缓存处理的同一设备驱动程序 (Ecache.sys) 实现，但缓存的填充则是由 ReadyBoost 服务在系统引导时带领完成。尽管引导缓存像 ReadyBoost 缓存一样进行压缩，但 ReadyBoost 和 ReadyBoot 缓存管理之间的另一个区别是，在 ReadyBoot 模式下，除了 ReadyBoost 服务的更新之外，缓存不会变为反映在引导期间读取或写入的数据。ReadyBoost 服务会在引导开始后 90 秒时（或者在其他内存需求批准它的情况下）将缓存删除，并将缓存的统计信息记录在 HKLMSystemCurrentControlSetServicesEcacheParametersReadyBootStats 中。Microsoft 性能测试表明，与旧有 Windows XP 预取器相比，ReadyBoot 使性能提高了约 20%。
ReadyBoost对系统的影响测试平台
本次作为测试的平台 分别为2004年产的惠普商务笔记本NC6000，评测的Vista版本为大部分家用笔记本内置的Home Premium版本。

安装好Vista Home Premium的NC6000

首先是配置得分以及系统版本的截图

我们看到内存得分的确不高，而硬盘得分还算不错。

担任本次测试主角的台电晶彩4GB闪盘，支持 ReadyBoost 功能

由于笔记本自身的内存仅512MB，所以我们将缓存设置为内存容量2～2.5倍之间，以期其能获得更加的性能。
所有的测试分别在使用Readyboost功能与不使用readyboost功能两种状态下分别进行。每次测试都在系统重新启动并稳定后进行。
软件开启运行速度
在内存少于512MB压根就不让安装Vista的条件下，NC6000的配置对于运行Vista仅仅是勉强而已。下图是重启时的物理内存消耗截图：

开机后任务管理器的检测结果，可用物理内存仅为4MB
我们可以注意到可用物理内存几乎为0，如果此时在运行一点程序，电脑的运行速度肯定会大打折扣。我们在vista系统中安装了一般用户最常用的办公软件OFFICE 2007 PLUS套装以及作图软件PHOTOSHOP CS2两款。

我们选取这两款软件主要是因为他们一个是最常用的办公软件，另外一个则是比较消耗内存资源的图形编辑软件。

在word 2007的测试中，我们在两种条件下分别进行了5次重复，并加以对照。结果是readyboost的使用与否对其影响不大，速度基本相同。

在outlook 2007的测试中，我们在两种条件下分别进行了5次重复，并加以对照。结果是readyboost在使用后，略微加快了一点速度，大约在1～2秒之间。

在PHOTOSHOP CS2的测试中，我们在两种条件下分别进行了5次重复，并加以对照。结果是readyboost在使用后，反而减慢了开启程序的速度。开启readyboost后测试，开始时为10秒左右，后期变为13秒左右。而非开启状态下测试，开始时为12秒，到了后期大约为7秒左右。
面对上面的测试结果，我们有点不知道如何是好。使用readyboost后，对内存读取、磁盘缓存要求较高的PHOTOSHOP CS2居然会出现性能下降的情况。而对于普通程序运行，虽然略有作用但是依然不是很明显。
而在资源监视器上面，我们可以注意到开启readyboost后的一些变化。

在第一次启动Outlook后,系统以6MB/s的速度向ReadyBoost缓存里写入文件.在随后几次的Outlook启动中,写入的操作几乎没有了,取而代之的是1.5MB/s的读取操作。

这是否就是readyboost加速的真正内涵呢？
readyboost对整机性能的影响
虽然readyboost在上面的测试中，表现得不是很好，但我们依然对它还保留一点希望。也许在专业测试中会获得更好的效果，下面就是pcmark06的测试结果：

未开启readyboost的测试

开启readyboost后的测试
测试结果与上次我们的评测文章的结果类似。有小的提升但是不明显，而且怀疑是测试误差导致的结果。
在软件对比测试的时候，我们还注意到另外一个问题。在资源监视器上，我们注意到开启readyboost后，系统开始往readyboost缓存那大量的写入数据。当系统稳定以后，让我们来看看readyboost对系统的影响。

开启readyboost后，磁盘i/o读写变少

未开启ready，磁盘读写很多
大家请注意，采用readyboost缓存后的系统I/O明显要比未采用的时候占用资源少。这从另外一个方面说明，readyboost可以减少系统进程对硬盘的读写，可能有减少硬盘的耗电量，延长使用时间的功能。
ReadyBoost对系统的影响：睡眠状态
虽然XP下的休眠用起来还不错，但是休眠需要的时间以及硬盘缓存文件都比较多。在vista下，微软设计了一项叫做快速开关机的功能READYBoot，在关机菜单里面此项功能被命名为“睡眠”。主要的目的就是方便那些随时需要办公的用户迅速的铺展、收拾完其工作用机。这项功能的实现同样也离不开Readyboost！
为了方便测试，我们将在vista系统下开启多个应用程序，并在其都稳定运行的情况下，让机器进入睡眠状态。

所有的应用程序包括有资源管理器、任务管理器、WMP11、Word2007、outlook2007、excel2007、PSCS2、HyperSnap。

看状态指示灯就知道笔记本的运行状况
在点击睡眠按钮后，我们就会看到硬盘等一阵狂闪，几秒以后整个系统就处于类似关闭的状态了。您再度点击电源按钮，vista系统就会迅速从睡眠状态恢复正常，整个时间不到10s。
经过我们的测试：
开启readyboost功能后，系统进入睡眠状态大约为5秒。点击睡眠状态按钮后，系统迅速关闭屏幕，只看见硬盘灯狂闪3秒就关闭系统了。再点电源钮系统在2秒内又会恢复原样。
未开启readyboost功能，系统进入睡眠状态大约为12秒。点击睡眠状态按钮后，系统迅速关闭屏幕，只看见硬盘灯狂闪大约10秒才关闭系统。再点电源钮系统在5秒以后才能恢复原样。
从这个测试项目看来，readyboost对系统的睡眠状态支持良好，可以给用户节省出不少的时间。而且由于反应迅速，可以给用户一个不错的印象。
结论：512MB笔记本用户没事还是插个1G SD卡吧！
从上面3段测试来看，想靠 ReadyBoost 来大幅提升程序开启的速度不是很现实的事情。如果您正在打算为了获得ReadyBoost功能，并为此去市场购置1个1GB的闪存盘似乎不是很值得。因为您花费的钱无法在运行系统的时候给带来明显加快的速度。
而花费闪存盘3倍左右的价格购置一条1GB内存可以让您的电脑运行得更快一些。从Vista的测试得分来看，512MB内存仅得到了2.9分，相比5400转硬盘的4.3分还有明显的差距。
使用readyboost功能，在整机的性能上不会给你太多的惊喜。毕竟它只是让你的电脑看上去更快了一些。使用Readyboost功能以后，您在使用中的确可以获得更快的电脑反应速度，而且不必每次都等着vista系统超过半分钟的关闭等待时间。插上支持readyboost功能的U盘，您就可以享受5秒钟关闭系统的愉悦感受。

四毛手里淘汰下来的1GB SD卡售价仅70元
由于ReadyBoost 具有缓存那些经常读取小文件，并借此减少硬盘 IO 频率，提升程序开启速度的效果。因此若您不想购置内存条，那么如果手边有不常使用的 U盘或者SD卡，不妨就将它插上主机，还是能够为系统整体性能贡献一点微薄之力的！
深入底层 评估Vista内核模式的安全性
作者: 独自等待, 　出处:IT专家网,　责任编辑: 张帅,　2008-01-17 10:23
Windows Vista与之前的MS Windows版本(包括Windows XP SP2)相比增加了很多的安全性。Vista新安全性的特征表现在什么地方?这些特性又是如何工作的呢?本文将详细介绍……
【IT专家网独家】介绍
Windows Vista与之前的MS Windows版本(包括Windows XP SP2)相比增加了很多的安全性。Vista新安全性的特征可以包括以下几个方面：
驱动签名
路径保护
内核模式代码完整性检查
可选择支持使用TPM芯片的安全启动
限制用户模式访问\Device\PhysicalMemory
上述的这些功能使得Vista64位版本与Linux或MacOS相比更具备安全性。该文档的主要贡献在：通过拟向工程较全面的分析内核模式的安全组件以及评估可能存在的内核模式攻击。
该文档检查新的安全特性，通过这些安全特性来阻止恶意代码危及内核。由于这些特性都仅存在于64位的Windows Vista系统内，因此该文档的关注点在Vista64位版本。
该文档没有分析PatchGuard的执行，针对PatchGuard的分析在前期已经有Skape和Skywing[6]进行了较全面的分析，值得注意的是PatchGuard发展到目前已经有所改变(在skape与skywing分析完后)。仅当下面章节对PatchGuard进行攻击评估时才会讨论这些问题。针对Vista用户模式的安全性评估在前面已经有所讨论[7]。
由于无法访问Windows Vista的源代码，我们通过debugger(调试器)、disassembler(反编译)、hex editor(16进制编辑器，例如UE)学习了Windows Vista Community Technical Preview (CTP) Build 5365版本。如果读者不熟悉X86体系架构和汇编语言的知识，推荐大家一本不错的关于X86汇编语言的在线图书[8]。另外，在看该文档前你需要熟悉一些Windows系统架构的知识，推荐大家阅读[9]，该书讲解了Windows系统架构的知识，同时这本书的一些知识同样可以应用到Vista系统上。在该文档公布时Vista系统还在测试阶段，但Vista在后来版本的安全性方面又做了一些改动。我们希望Vista在最终的发布版本上有更多的改变，同时我们也计划继续对未来的Vista版本的内核改动进行研究。
Vista引导过程
Windows Vista支持从PC/AT BIOS和Intel新的EFI(可扩展固件接口)启动。我们的分析过程忽略了EFI部分。在本章节的最后部分，引用了bootmgr入口点的开始指令(DllMail为EFI的入口点指令，offset 0为PC/AT的入口点指令)这个过程从Vista启动管理器开始，定位%SystemDrive%\bootmgr 文件 (for PC/AT legacy BIOS)或%SystemDrive%\Boot\EFI\bootmgr.efi (for EFI BIOS)。Vista Boot Manager是启动Vista的必须环节，但也适用于启动Windows Vista之前的Windows版本。
Vista Boot Manager首先调用InitializeLibrary，然后依次调用BlpArchInitialize (GDT, IDT, etc.), BlMmInitialize (memory management), BlpFwInitialize (firmware=固件?), BlpTpmInitialize (TPM), BlpIoInitialize (file systems), BlpPltInitialize (PCI configuration), BlBdInitialize (debugging), BlDisplayInitialize, BlpResourceInitialize (finds its own .rsrc section), and BlNetInitialize。
在Vista系统内，Windows传统的boot.ini配置文件已经被启动配置数据文件(BCD)所代替，Vista下该文件位于%SystemDrive%\Boot\BCD，该文件也是注册表的值(在Vista下被挂载在HKEY_LOCAL_MACHINE\BCD00000000下)。可以使用bcdedit.exe来查看该文件的内容。
一个典型的Boot Manager的BCD配置文件如下：
Windows Boot Manager
Identifier: {bootmgr}
Type: 10100002
Device: partition=C:
Description: Windows Boot Manager
Locale: en-US
Inherit options: {globalsettings}
Boot debugger: No
Pre-boot EMS Enabled: No
Default: {current}
Resume application: {3ced334e-a0a5-11da-8c2b-cbb6baaeea6d}
Display order: {current}
Timeout: 30
如果只有一个启动入口在BCD文件内，启动管理器会直接从该入口启动。如果多于一个启动入口，Boot Manager会给用户一个可选择的列表，并提示用户选择启动那个OS。如果启动阶段激活了日志记录，启动管理器会把状态信息写入%SystemDrive%\Boot\bootstat.dat文件内(通过BmpInitializeBootStatusDataLog)。紧接着启动管理器会使用BlResourceFindHtml把bootmgr.xsl定位在资源节点，而后把它传给BlXmiInitialize。bootmgr.xsl文件控制启动菜单和位于启动菜单的选项。
如果启动列表的某个条目被选择，跟随BmpTransferExecution之后，将使用BmpLaunchBootEntry对该条目进行加载。BmpTransferExecution将重新找回启动选项(通过BlGetBootOptionString)并把他们交给BlImgLoadBootApplication。如果FVE(Full Volume Encryption)被激活，BlFveSecureBootUnlockBootDevice和 BlFveSecureBootCheckpointBootApp将被调用。由于Windows分区被加密，必须在把控制权交给Vista OS Loader前对分区进行解密。
最后，Boot Manager调用BlImgStartBootApplication把控制权交给Vista OS Loader。
Windows Vista操作系统加载
bootmgr调用了位于%SystemRoot%\System32\WINLOAD.EXE下的Vista OS Loader。WINLOAD.EXE替换了NTLDR(Windows NT OS Loader)，该小节的最后部分，会引用WINLOAD.EXE在开始入口点(OslMain)的指令。
一个典型的Vista OS载入的BCD入口配置文件如下：
Windows Boot Loader
Identifier: {current}
Type: 10200003
Device: partition=C:
SYMANTEC ADVANCED THREAT RESEARCH 3
Path: \Windows\system32\WINLOAD.EXE
Description: Microsoft Windows
Locale: en-US
Inherit options: {bootloadersettings}
Boot debugger: No
Pre-boot EMS Enabled: No
Advanced options: No
Options editor: No
Windows device: partition=C:
Windows root: \Windows
Resume application: {3ced334e-a0a5-11da-8c2b-cbb6baaeea6d}
No Execute policy: OptIn
Detect HAL: No
No integrity checks: No
Disable boot display: No
Boot processor only: No
Firmware PCI settings: No
Log initialization: No
OS boot information: No
Kernel debugger: No
HAL breakpoint: No
EMS enabled in OS: No
执行从OslMain开始。它重用了与bootmgr阶段相同的代码，因此InitializeLibrary在bootmgr内的工作原理与在WINLOAD.EXE内的工作原理相似。在InitializeLibrary之后，控制权交给OslMain。
如果启动状态日志记录被激活，WINLOAD.EXE将会把结果写入%SystemDrive%\Boot\bootstat.dat (通过 OslpInitializeBootStatusDataLog和OslpSetBootStatusData)。接下来WINLOAD.EXE调用OslDisplayInitialize，并使用BlResourceFindHtml定位osloader.xsl所在的资源节点。控制权转交给BlXmiInitialize。在系统启动过程中osloader.xsl控制着高级启动选项。在操作完高级启动选项(使用OslDisplayAdvancedOptionsProcess)，WINLOAD.EXE现在就准备开始启动。启动阶段首先会使用BlDeviceOpen打开启动设备。根据设备类型，BlDeviceOpen会使用不同的设备函数集来打开设备。
全盘加密(_FvebDeviceFunctionTable) 如下：
dd 0 ; FVE has no EnumerateDeviceClass callback
dd offset _FvebOpen@8 ; FvebOpen(x,x)
dd offset _FvebClose@4 ; FvebClose(x)
dd offset _FvebRead@16 ; FvebRead(x,x,x,x)
dd offset _FvebWrite@16 ; FvebWrite(x,x,x,x)
dd offset _FvebGetInformation@8 ; FvebGetInformation(x,x)
dd offset _FvebSetInformation@8 ; FvebSetInformation(x,x)
dd offset _FvebReset@4 ; FvebReset(x)
For block I/O (_BlockIoDeviceFunctionTable) these are:
dd offset _BlockIoEnumerateDeviceClass@12 ; BlockIoEnumerateDeviceClass(x,x,x)
dd offset _BlockIoOpen@8 ; BlockIoOpen(x, x)
dd offset _BlockIoClose@4 ; BlockIoClose(x)
dd offset _BlockIoReadUsingCache@16 ; BlockIoReadUsingCache(x,x,x,x)
dd offset _BlockIoWrite@16 ; BlockIoWrite(x,x,x,x)
dd offset _BlockIoGetInformation@8 ; BlockIoGetInformation(x,x)
dd offset _BlockIoSetInformation@8 ; BlockIoSetInformation(x,x)
dd offset ?handleInputChar@OsxmlMeter@@UAEHG@Z ; OsxmlMeter::handleInputChar(ushort)
dd offset _BlockIoCreate@12 ; BlockIoCreate(x,x,x)
For console (_ConsoleDeviceFunctionTable) these are:
dd offset _UdpEnumerateDeviceClass@12 ; UdpEnumerateDeviceClass(x,x,x)
dd offset _ConsoleOpen@8 ; ConsoleOpen(x,x)
dd offset _ConsoleClose@4 ; ConsoleClose(x)
dd offset _ConsoleRead@16 ; ConsoleRead(x,x,x,x)
dd offset _ConsoleWrite@16 ; ConsoleWrite(x,x,x,x)
dd offset _ConsoleGetInformation@8 ; ConsoleGetInformation(x,x)
dd offset _ConsoleSetInformation@8 ; ConsoleSetInformation(x,x)
dd offset _ConsoleReset@4 ; ConsoleReset(x)
For serial port (_SerialPortFunctionTable) these are:
dd offset _UdpEnumerateDeviceClass@12 ; UdpEnumerateDeviceClass(x,x,x)
dd offset _SpClose@4 ; SpClose(x)
dd offset _SpRead@16 ; SpRead(x,x,x,x)
dd offset _SpWrite@16 ; SpWrite(x,x,x,x)
dd offset _SpGetInformation@8 ; SpGetInformation(x,x)
dd offset _SpSetInformation@8 ; SpSetInformation(x,x)
dd offset _SpReset@4 ; SpReset(x)
For PXE (_UdpFunctionTable):
dd offset _UdpEnumerateDeviceClass@12 ; UdpEnumerateDeviceClass(x,x,x)
dd offset _UdpOpen@8 ; UdpOpen(x,x)
dd offset _SpClose@4 ; SpClose(x)
dd offset _UdpRead@16 ; UdpRead(x,x,x,x)
dd offset _UdpWrite@16 ; UdpWrite(x,x,x,x)
dd offset _UdpGetInformation@8 ; UdpGetInformation(x,x)
dd offset _UdpSetInformation@8 ; UdpSetInformation(x,x)
dd offset _UdpReset@4 ; UdpReset(x)
你可能注意到有些函数的返回在不同类别之间会存在共享(例如：serial port和PXE)。
接着LOADER_PARAMETER_BLOCK结构通过OslInitializeLoaderBlock进行初始化，LOADER_PARAMETER_BLOCK包含了一些系统状态信息，如：启动设备、ACPI、SMBIOS表等。下面为LOADER_PARAMETER_BLOCK在Vista64位版本的结构：
+0x000 LoadOrderListHead : struct _LIST_ENTRY
+0x010 MemoryDescriptorListHead : struct _LIST_ENTRY
+0x020 BootDriverListHead : struct _LIST_ENTRY
+0x030 KernelStack : Uint8B
+0x038 Prcb : Uint8B
+0x040 Process : Uint8B
+0x048 Thread : Uint8B
+0x050 RegistryLength : Uint4B
+0x058 RegistryBase : Ptr64 to Void
+0x060 ConfigurationRoot : Ptr64 to struct _CONFIGURATION_COMPONENT_DATA
+0x068 ArcBootDeviceName : Ptr64 to Char
+0x070 ArcHalDeviceName : Ptr64 to Char
+0x078 NtBootPathName : Ptr64 to Char
+0x080 NtHalPathName : Ptr64 to Char
+0x088 LoadOptions : Ptr64 to Char
+0x090 NlsData : Ptr64 to struct _NLS_DATA_BLOCK
+0x098 ArcDiskInformation : Ptr64 to struct _ARC_DISK_INFORMATION
+0x0a0 OemFontFile : Ptr64 to Void
+0x0a8 SetupLoaderBlock : Ptr64 to struct _SETUP_LOADER_BLOCK
+0x0b0 Extension : Ptr64 to struct _LOADER_PARAMETER_EXTENSION
+0x000 Size : Uint4B
+0x004 Profile : struct _PROFILE_PARAMETER_BLOCK
+0x014 MajorVersion : Uint4B
+0x018 MinorVersion : Uint4B
+0x020 EmInfFileImage : Ptr64 to Void
+0x028 EmInfFileSize : Uint4B
+0x030 TriageDumpBlock : Ptr64 to Void
+0x038 LoaderPagesSpanned : Uint4B
+0x040 HeadlessLoaderBlock : Ptr64 to struct _HEADLESS_LOADER_BLOCK
+0x048 SMBiosEPSHeader : Ptr64 to struct _SMBIOS_TABLE_HEADER
+0x050 DrvDBImage : Ptr64 to Void
+0x058 DrvDBSize : Uint4B
+0x060 NetworkLoaderBlock : Ptr64 to struct _NETWORK_LOADER_BLOCK bytes
+0x068 FirmwareDescriptorListHead : struct _LIST_ENTRY
+0x078 AcpiTable : Ptr64 to Void
+0x080 AcpiTableSize : Uint4B
+0x084 BootViaWinload : Bitfield Pos 0, 1 Bit
+0x084 BootViaEFI : Bitfield Pos 1, 1 Bit
+0x084 Reserved : Bitfield Pos 2, 30 Bits
+0x088 LoaderPerformanceData : Ptr64 to struct _LOADER_PERFORMANCE_DATA
+0x090 BootApplicationPersistentData : struct _LIST_ENTRY
+0x0a0 WmdTestResult : Ptr64 to Void
+0x0a8 BootIdentifier : struct _GUID
+0x0b8 u : union
+0x000 I386 : struct _I386_LOADER_BLOCK
+0x000 CommonDataArea : Ptr64 to Void
+0x008 MachineType : Uint4B
+0x00c VirtualBias : Uint4B
下面会寻找系统磁盘(通过OslEnumerateDisks)和加载系统注册表项HKEY_LOCAL_MACHINE(通过OslpLoadSystemHive)。当系统注册表项加载后，我们遇到了Vista在启动阶段的第一次代码完整性(通过OslInitializeCodeIntegrity)。在该处首先会调用MincrypL_SelfTest，MincrypL_SelfTest验证SHA1散列值，并使PKCS1的签名验证开始工作(using a pre-defined test case=通过预定义的测试样例?)。如果预先定义的测试样例失败了，会返回错误代码到0xC0000428。然后，检查调试器是否开启(通过BlBdDebuggerEnabled)。如果在这里检测到调试器在开启状态，会调用KnownAnswerTest。如果没有检测到调试器处在开启状态，会直接跳过该处。
接下来通过BlImgRegisterCodeIntegrityCatalogs从%SystemRoot%\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\nt5.cat加载OS的编目录(在内部调用了API函数MinCrypL_AddCatalog)。
当OS 编目录 nt5.cat被加载后，WINLOAD.EXE通过SelfIntegrityCheck对其自身进行完整性检查，这里的检查做了两个事情：
1. 计算PE映像(image)的SHA1哈希值，然后与PE证书表内的SHA1哈希值进行对比，这里的对比必须是匹配的，如果不匹配就会返回一个错误信息。
2. 另外，他也调用ImgpValidateImageHash来验证映象(image)哈希值是否与nt5.cat内的相匹配。ImgpValidateImageHash会调用API函数MinCrypL_CheckSignedFile来验证证书，调用MinCrypL_CheckImageHash来寻找nt5.cat上的映象(image)匹配哈希值。在下面的章节III会讨论通过MinCrypL_CheckSignedFile和 MinCrypL_CheckImageHash进行驱动签名验证。
如果上述的签名过程不匹配，但是调试器在开启状态(BlBdDebuggerEnabled returns TRUE)，那么在这里会打印处如下的调试信息：
*** Windows is unable to verify the signature of the file %s.
It will be allowed to load because the boot debugger is enabled.
Use g to continue!!
如果调试器是存在的，那么可以通过调用DbgBreakPoint来进行激活;另外，在这里通过调用ReportCodeIntegrityFailure替换了系统提示致命错误的错误形式。
当所有的完整性检查结束后(unless all integrity checks have been disabled)，OslInitializeCodeIntegrity会返回成功状态，然后会继续从OslMain开始执行。接着，OslpLoadAllModules被调用并开始加载系统模块。首先，会调用OslLoadImage来加载NTOSKRNL.EXE和HAL.DLL，在这里仅仅是加载，此时没有解决Imports;第二，如果内核调试被开启，调试驱动会依靠启动调试选项的情况被加载(kdcom.dll for serial port, kd1394.dll for IEEE1394, or kdusb.dll for USB)。第三，NTOSKRNL.EXE的Imports被加载和初始化(使用LoadImports和BindImportRefences函数)。
OslLoadImage calls GetImageValidationFlags to check the filename against a pre-defined list of boot drivers in LoadBootImagesTable. If integrity checks are enabled, then boot drivers must be signed by a trusted root authority and all the image hashes must match the signed catalog file unless a debugger is enabled. If a debugger is enabled, WINLOAD.EXE does not enforce this requirement. Instead it will print an error message to the debugger, but will otherwise ignore the code integrity check failure. However, the following boot drivers (also listed in Appendix A) must pass the code integrity checks even if a debugger is enabled (otherwise WINLOAD.EXE will refuse to boot Windows Vista):
OslLoadImage调用GetImageValidationFlags来检查在LoadBootImagesTable中预先定义好的boot drivers文件名。如果启用了完整性检查，除非在这里调试器被开启，否则boot drivers必须进行可信任的root签名，并且所有的映象哈希值(image hashes)要与编目录签名相匹配。如果调试器处于开启状态，WINLOAD.EXE不会强制这些要求。安全后WINLOAD.EXE会打印一个错误信息给调试器，但是却忽略了代码完整性检查的失败。无论如何，接下来的boot drivers必须通过代码完整性检查，即使调试器在开启状态也必须检查。(如果没有进行检查，vista不会被启动起来)：
\Windows\system32\bootvid.dll
\Windows\system32\ci.dll
\Windows\system32\clfs.sys
\Windows\system32\hal.dll
\Windows\system32\kdcom.dll (or kd1394.sys or kdusb.dll, depending on boot options)
\Windows\system32\ntoskrnl.exe
\Windows\system32\pshed.dll
\Windows\system32\WINLOAD.EXE
\Windows\system32\drivers\ksecdd.sys
\Windows\system32\drivers\spldr.sys
\Windows\system32\drivers\tpm.sys
加载映象和验证代码完整性都在BlImgLoadPEImageEx内，都使用了SelfIntegrityCheck(在前面章节有描述)函数。所有的映象(image)都通过代码完整性校验后，NTOSKRNL.EXE和它所有的Imports此时会被加载。列表(版本:Build 5363)如下：
\Windows\system32\NTOSKRNL.exe
\Windows\system32\HAL.dll
\Windows\system32\PSHED.dll
\Windows\system32\BOOTVID.dll
\Windows\system32\CLFS.SYS
\Windows\system32\CI.dll
接下来使用OslHiveFindDrivers查找所有的boot drivers，并且根据组(which is ordered according to HKEY_LOCAL_MACHINE\CurrentControlSet\Control\GroupOrderList)和标记(an integer which determines each driver’s order within its respective group)对他们进行分类。这个分类好的boot drivers列表通过OslLoadDrivers进行加载。OslLoadDrivers为列表中的每个驱动调用LoadImageEx。LoadImageEx将会加载每个驱动及相关信息。
此时，剩余的boot drivers也被加载和初始化。列表如下(按照年月日排列,64位Vista)：
1. \Windows\system32\drivers\Wdf01000.sys
2. \Windows\system32\drivers\WDFLDR.SYS
3. \Windows\system32\drivers\acpi.sys
4. \Windows\system32\drivers\WMILIB.SYS
5. \Windows\system32\drivers\msisadrv.sys
6. \Windows\system32\drivers\pci.sys
7. \Windows\system32\drivers\volmgr.sys
8. \Windows\system32\drivers\isapnp.sys
9. \Windows\system32\drivers\mpio.sys
10. \Windows\system32\drivers\compbatt.sys
11. \Windows\system32\drivers\BATTC.SYS
12. \Windows\System32\drivers\mountmgr.sys
13. \Windows\system32\drivers\intelide.sys
14. \Windows\system32\drivers\PCIIDEX.SYS
15. \Windows\system32\drivers\pcmcia.sys
16. \Windows\system32\drivers\aliide.sys
17. \Windows\system32\drivers\amdide.sys
18. \Windows\system32\drivers\cmdide.sys
19. \Windows\system32\drivers\msdsm.sys
20. \Windows\system32\drivers\pciide.sys
21. \Windows\system32\drivers\viaide.sys
22. \Windows\System32\drivers\volmgrx.sys
23. \Windows\system32\drivers\atapi.sys
24. \Windows\system32\drivers\ataport.SYS
25. \Windows\system32\drivers\hpcisss.sys
26. \Windows\system32\drivers\storport.sys
27. \Windows\system32\drivers\adp94xx.sys
28. \Windows\system32\drivers\adpu160m.sys
29. \Windows\system32\drivers\SCSIPORT.SYS
30. \Windows\system32\drivers\adpu320.sys
31. \Windows\system32\drivers\djsvs.sys
32. \Windows\system32\drivers\arc.sys
33. \Windows\system32\drivers\arcsas.sys
34. \Windows\system32\drivers\elxstor.sys
35. \Windows\system32\drivers\i2omp.sys
36. \Windows\system32\drivers\iirsp.sys
37. \Windows\system32\drivers\iteraid.sys
38. \Windows\system32\drivers\lsi_fc.sys
39. \Windows\system32\drivers\lsi_sas.sys
40. \Windows\system32\drivers\lsi_scsi.sys
41. \Windows\system32\drivers\megasas.sys
42. \Windows\system32\drivers\mraid35x.sys
43. \Windows\system32\drivers\msahci.sys
44. \Windows\system32\drivers\nfrd960.sys
45. \Windows\system32\drivers\ql2300.sys
46. \Windows\system32\drivers\ql40xx.sys
47. \Windows\system32\drivers\sisraid2.sys
48. \Windows\system32\drivers\sisraid4.sys
49. \Windows\system32\drivers\symc8xx.sys
50. \Windows\system32\drivers\sym_hi.sys
51. \Windows\system32\drivers\sym_u3.sys
52. \Windows\system32\drivers\vsmraid.sys
53. \Windows\system32\drivers\fltmgr.sys
54. \Windows\system32\drivers\fileinfo.sys
55. \Windows\system32\drivers\ndis.sys
56. \Windows\system32\drivers\msrpc.sys
57. \Windows\system32\drivers\NETIO.SYS
58. \Windows\System32\Drivers\Ntfs.sys
此时，所有的boot drivers被加载。接下来，调用OslpLoadNlsData从注册表项HKEY_LOCAL_MACHINE\CurrentControlSet\Control\NLS加载操作系统的语言版本。最后调用OslpLoadAllModules做了下面的几个事情：
1. 显示Vista启动过程中的进度条。
2. 加载%SystemRoot%\AppPatch\drvmain.sdb(the application compatability database)
3. 加载%SystemRoot%\System32\acpitabl.dat
4. 加载HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Errata\InfName注册表项的INF文件。
在OslpLoadAllModules结束后，OslMain保存启动日志(OslpLogSaveInformation)，如果FVE(Full Volume Encryption)选项开启，结束FVE的加载(BlFveSecureBootRestrictToOne and BlTpmShutdown)。最后，调用OslArchTransferToKernel把控制权转交给NTOSKRNL.EXE。
Vista Windows系统内核
Vista使用了与先前版本一样的惯例。64位Vista会在%SystemRoot%\System32\ntoskrnl.exe查找NTOSKRNL.EXE，在本章节的剩余部分，会引用ntoskrnl.exe在开始入口点的操作指令(KiSystemStartup)。
执行首先从KiSystemStartup开始。Vista下的NTOSKRNL.EXE内的一些重要部分与Windows 2003 SP1版相比，并没有太多的改变，因此我们的重点为分析Vista下改变的特殊部分。在Vista下，NTOSKRNL.EXE添加了一个新函数SepInitializeCodeIntegrity，但该函数仅仅是把CL.DLL内的CiInitialize(关于CiInitialize会在后面的章节VI进行讨论)进行了另外的包装而已。如果代码完整性检查开启，SepInitializeCodeIntegrity会调用CiInitialize，除此之外，它没有做任何其它的事情。
WINLOAD.EXE还负责检查boot drivers签名的完整性。与WINLOAD.EXE相比，NTOSKRNL.EXE负责查证system drivers(在boot driver加载后)和运行时加载的drivers(即：当一个设备被插进系统)。当完整性检查开启，会使用SeValidateImageHeader(在CI.DLL内CiValidateImageHeader函数的包装)和SeValidateImageData(在CI.DLL内CiValidateImageData函数的包装)对加载的映象(image)进行代码完整性检查。只要一个执行映射进kernel memeory都会调用SeValidateImageHeader(通过MmCreateSection)。当一个内核模块加载时，都会调用SeValidateImageData对kernel drivers的代码段进行校验。运行时检查(例如：不断的检查kernel drivers的代码段是否被修改)由PatchGuard和CI.DLL进行处理。
Inside the Windows Vista Kernel: Part 1
Mark Russinovich
At a Glance:
Thread priority and scheduling File-based symbolic links Canceling I/O operations
This is the first part of a series on what‘s new in the Windows Vista kernel. In this issue, I‘ll look at changes in the areas of processes and threads, and in I/O. Future installments will cover memory management, startup and shutdown, reliability and recovery, and security.
The scope of this article comprises changes to the Windows Vista™ kernel only, specifically Ntoskrnl.exe and its closely associated components. Please remember that there are many other significant changes in Windows Vista that fall outside the kernel proper and therefore won‘t be covered. This includes improvements to the shell (such as integrated desktop search), networking (like the new IPv6 stack and two-way firewall), and the next-generation graphics model (such as Aero™ Glass, Windows® Presentation Foundation, the Desktop Window Manager, and the new graphics driver model). Also not covered are the new Windows User-Mode and Kernel-Mode Driver Frameworks (UMDF and KMDF) since these are back-level installable on earlier versions of Windows.
CPU Cycle Counting
Windows Vista includes a number of enhancements in the area of processes and threads that include use of the CPU cycle counter for fairer CPU allocation and the new Multimedia Class Scheduler Service (MMCSS) that helps media applications deliver glitch-free playback.
All versions of Windows NT® up to and including Windows Vista program an interval-timer interrupt routine to execute approximately every 10 or 15 ms (milliseconds), depending on the hardware platform. The routine looks at what thread it interrupted and updates the thread‘s CPU usage statistics as if that thread had run for the entire interval, while in reality the thread might have started executing just before the interval‘s end. Further, the thread might have been technically assigned the CPU, but didn‘t get a chance to run because hardware and software interrupt routines executed instead.
While clock-based time accounting might be OK for diagnostic tools that report thread and process CPU usage, use of that method by the thread scheduler can cause unfair CPU allocation. By default, on client versions of Windows threads are permitted to run up to 2 clock ticks (6 if in the foreground). However, the thread might get virtually no time on the CPU or up to 6 ticks (18 if in the foreground), depending on its behavior and other activity on the system.
Figure 1 shows the unfairness that can occur when two threads that have the same priority become ready to run at the same time. Thread A runs until the next time-slice interval expiration when the scheduler assumes it has run for the entire interval and so decides that Thread A‘s turn is finished. Furthermore, Thread A gets unfairly charged for the interrupt that occurred during its turn. At the next interval, the scheduler picks Thread B to take over and it runs for a full interval.
Figure 1 Unfair Thread Scheduling
In Windows Vista, the scheduler uses the cycle counter register of modern processors to track precisely how many CPU cycles a thread executes. By estimating how many cycles the CPU can execute in a clock interval, it can more accurately dole out turns on the CPU. In addition, the Windows Vista scheduler does not count interrupt execution against a thread‘s turn. This means that on Windows Vista a thread will always get at least its turn on the CPU and never more than an extra clock interval of execution, resulting in greater fairness and more deterministic app behavior. Figure 2 shows how Windows Vista responds to the scenario shown in Figure 1 by giving both threads at least one time slice interval of execution.
Figure 2 Windows Vista Cycle-Based Scheduling (Click the image for a larger view)
The "Watching Process CPU Usage" sidebar illustrates how you can monitor process CPU cycle usage for yourself by using the Process Explorer utility.
Multimedia Class Scheduler Service
Users expect multimedia applications, including music and video players, to offer a seamless playback experience. However, demand for the CPU by other concurrently running applications, like antivirus, content indexing, or even the mail client, can result in unpleasant hiccups. To provide a better playback experience, Windows Vista introduces MMCSS to manage the CPU priorities of multimedia threads.
A multimedia app like Windows Media® Player 11 registers with MMCSS using new APIs that indicate its multimedia characteristics, which must match one of those listed by name under the following registry key:
Copy Code
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\Tasks
The various task keys specify how much preference threads associated with different multimedia types get for CPU and graphics processor resources (though graphics processor resource management is not implemented in Windows Vista). Figure 3 shows the contents of one of the task registry keys after a clean Windows Vista installation, though third-party developers can add their own task definitions.
Watching Process CPU Usage
You can see the inaccuracy of the Windows standard clock-based time accounting using theProcess Explorer utility from Sysinternals. Run Process Explorer on a Windows Vista system and add the Cycles Delta column to the process view. Cycles Delta shows the number of cycles the threads of each process execute between Process Explorer updates. Because CPU time accounting is still based on the interval timer, if you also add the CPU Time column, then you‘ll see many processes that have threads consuming millions of CPU cycles and yet don‘t have their CPU time updated and don‘t show up in the CPU usage column.
Figure A Viewing CPU Time and Cycles Delta in Process Explorer (Click the image for a larger view)
Figure 3 Multimedia Class Scheduler Audio Task Definition (Click the image for a larger view)
MMCSS, which is implemented in %SystemRoot%\System32\Mmcss.dll and runs in a Service Host (Svchost.exe) process, has a priority-management thread that runs at priority 27. (Thread priorities in Windows range from 0 to 31.) This thread boosts the priority of registered multimedia threads into the range associated with the Scheduling Category value of their task‘s registry key as listed in Figure 4. In Windows, thread priorities 16 and higher are in the real-time priority range and higher than all other threads on a system (with the exception of the kernel‘s Memory Manager worker threads, which run at priorities 28 and 29). Only administrative accounts, like the Local System account in which MMCSS executes, have the Increase Priority privilege that‘s required to set real-time thread priorities.
 Figure 4 MMCSS Thread Priorities
Scheduling Category Boosted Thread Priority
High 23-26
Medium 16-23
When you play an audio file, Windows Media Player registers Audio task threads, and when you play a video, it registers Playback task threads. The MMCSS service boosts all threads that have indicated that they are delivering a stream at the same time when they are running in the process that owns the foreground window and when they have the BackgroundOnly value set to True in their task‘s definition key.
But while MMCSS wants to help multimedia threads get the CPU time they need, it also wants to ensure that other threads get at least some CPU time so that the system and other applications remain responsive. MMCSS therefore reserves a percentage of CPU time for other activity, specified in the following registry value:
Copy Code
HKLM\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\SystemResponsiveness
By default, this is 20 percent; MMCSS monitors CPU usage to ensure that multimedia threads aren‘t boosted for more than 8 ms over a 10 ms period if other threads want the CPU. To get the multimedia threads out of the way for the remaining 2 ms, the scheduler drops their priorities into the 1-7 range.
You can see how MMCSS boosts thread priority by reading the "Watching MMCSS Priority Boosting" sidebar.
File-Based Symbolic Links
The Windows Vista I/O-related changes include file-based symbolic links, more efficient I/O completion processing, comprehensive support for I/O cancellation, and prioritized I/O.
A file system feature many have considered missing from NTFS, the symbolic file link (or as it‘s called in UNIX, the soft link) finally arrives in Windows Vista. The Windows 2000 version of NTFS introduced symbolic directory links, called directory junctions, which allow you to create a directory that points at a different directory, but until the Windows Vista version, NTFS has only supported hard links for files.
A major difference in the way Windows resolves symbolic links and directory junctions is where the processing takes place. Windows processes symbolic links on the local system, even when they reference a location on a remote file server. Windows processes directory junctions that reference a remote file server on the server itself. Symbolic links on a server can therefore refer to locations that are only accessible from a client, like other client volumes, whereas directory junctions cannot. To address this, Windows Vista supports the new symbolic link type for both files and directories.
Many file system commands have been updated to understand the implications of symbolic links. For example, the Delete command knows not to follow links, which would result in deletion of the target, but to delete the link instead. However, because not all applications may handle symbolic links correctly, creating a symbolic link requires the new Create Symbolic Link privilege that only administrators have by default.
You can create a symbolic link from a command prompt with the Mklink command. The command prompt‘s built-in directory command identifies a symbolic link by flagging it with and showing you the target in brackets, as shown in Figure 5. Windows Explorer is also symbolic-link-aware and shows them with the short-cut arrow. You can see the target of a link in Explorer by adding the Link Target column to the browsing window.
Watching MMCSS Priority Boosting
You can witness the thread boosting that the MMCSS service applies to Windows Media Player threads by playing a video or audio clip, running the Performance Monitor, setting the graph scale to 31 (the highest Windows thread priority), and adding the Priority Current counter for all instances of the Windows Media Player (Wmplayer.exe) thread objects to the display. One or more threads will run at priority 21.
Figure B Thread Priority Boosting for Windows Media Player (Click the image for a larger view)
Figure 5 Using Mklink to Create a Symbolic Link (Click the image for a larger view)
I/O Completion and Cancellation
There are a number of under-the-hood changes to the I/O system that can improve the performance of server applications. These applications commonly use a synchronization object called a completion port to wait for the completion of asynchronous I/O requests. Prior to Windows Vista, when such an I/O completed, the thread that issued the I/O would execute I/O completion work, causing a switch to the process the thread belongs to and interrupting whatever else was going on. Then the I/O system would update the completion port status to wake up a thread waiting for it to change.
On Windows Vista, the I/O completion processing is performed not necessarily by the thread that issued the I/O, but instead by the one that is waiting for the completion port to wake it up. This relatively minor change avoids needless thread scheduling and context switches that can degrade the application‘s and the system‘s overall performance. To improve performance further, a server can retrieve the results of multiple I/O operations from a completion in one request, avoiding transitions to kernel mode.
Probably the most visible change in the I/O system from an end-user perspective is Windows Vista support for canceling synchronous I/O operations. If you‘ve ever performed a net view command or attempted to access a share to an off-line remote system using Windows XP or Windows Server® 2003, you‘ve experienced the problems with I/O operations that can‘t be canceled: the command or file browser won‘t respond until a network timeout expires. An application has no choice but to wait until the operation fails because there‘s no way for it to tell the device driver executing the I/O that it doesn‘t care about the I/O anymore.
In Windows Vista most I/O operations can be canceled, including the open file I/O that Net View and Explorer use. Applications have to be updated to respond to end-user requests to cancel I/O, however, and many of the Windows Vista utilities that interact with devices that have timeouts have the necessary support. The file open and save dialogs that are used by virtually every Windows application, including third-party applications, for example, now enable their Cancel button while trying to display the contents of a folder. The Net command also cancels its synchronous I/O when you press Ctrl+C.
You can see the benefits of I/O cancellation by opening a command prompt on Windows Vista and typing:
Copy Code
net view \\nonexistentmachine
The command will hang while Windows tries to contact the nonexistent system, but you can type Ctrl+C to terminate it. In Windows XP, Ctrl+C has no effect and the command doesn‘t return until the network operation times out.
Another type of I/O that has caused users problems in past versions of Windows are those that device drivers didn‘t cancel properly because there was no easy way for them to know that they should. If you‘ve ever terminated a process, but subsequently saw it lingering in process-viewing tools, then you‘ve witnessed a device driver failing to respond to a process termination and canceling I/O issued by the process that hadn‘t completed. Windows can‘t perform final process cleanup until all the process‘ I/O has either finished or been canceled. In Windows Vista, device drivers easily register for notification of process terminations and so most of the un-killable process problems are gone.
I/O Priority
While Windows has always supported prioritization of CPU usage, it hasn‘t included the concept of I/O priority. Without I/O priority, background activities like search indexing, virus scanning, and disk defragmenting can severely impact the responsiveness of foreground operations. A user launching an app or opening a document while another process is performing disk I/O, for example, experiences delays as the foreground task waits for disk access. The same interference also affects the streaming playback of multimedia content like songs from a hard disk.
Windows Vista introduces two new types of I/O prioritization in order to help make foreground I/O operations get preference: priority on individual I/O operations and I/O bandwidth reservations. The Windows Vista I/O system internally includes support for five I/O priorities as shown in Figure 6, but only four of the priorities are used (future versions of Windows may support High).
 Figure 6 Windows Vista I/O Priorities
I/O Priority Usage
Critical Memory manager
High Unused
Normal Default priority
Low Default task priority
Very low Background activity
I/O has a default priority of Medium and the Memory Manager uses Critical when it wants to write dirty memory data out to disk under low memory situations to make room in RAM for other data and code. The Windows Task Scheduler sets the I/O priority for tasks that have the default task priority to Low, and the priority specified by applications written for Windows Vista that perform background processing is Very Low. All of the Windows Vista background operations, including Windows Defender scanning and desktop search indexing, use Very Low I/O priority.
Seeing Very Low I/O Priority
Process Monitor, a real-time file system and Registry monitoring utility from Sysinternals, collects detailed information for read and write file system operations, including their I/O priorities on Windows Vista. The highlighted line shows an example of a very low-priority I/O that was issued by SuperFetch, (which I‘ll discuss in my next installment).
Figure C Viewing Very Low I/O Priority in Proces Monitor (Click the image for a larger view)
The system storage class device driver (%SystemRoot%\System32\Classpnp.sys) enforces I/O priorities and so they automatically apply to I/O directed at most storage devices. The class and other storage drivers insert Medium I/Os ahead of those that are Low and Very Low in their queues, but issue at least one waiting Low or Very Low I/O every second so that background processes can make forward progress. Data read using Very Low I/O also causes the Cache Manager to immediately write modifications to disk instead of doing it later, and to bypass its read-ahead logic for read operations that would otherwise preemptively read from the file being accessed. Take a look at the sidebar "Seeing Very Low I/O Priority" for an example of Very Low I/O priority using the Process Monitor utility.
The Windows Vista bandwidth reservation support is useful for media player applications and Windows Media Player uses it, along with MMCSS priority boosts, to deliver nearly glitch-free playback of local content. A media player application asks the I/O system to guarantee it the ability to read data at a specified rate and, if the device can deliver data at the requested rate and existing reservations allow it, it gives the app guidance as to how fast it should issue I/Os and how large the I/Os should be. The I/O system won‘t service other I/Os unless it can satisfy the requirements of apps that have made reservations on the target storage device.
One final change in the I/O system worth mentioning relates to the size of I/O operations. Since the first version of 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. Thus, even if an application issues a much larger I/O request, it‘s broken into individual requests having a maximum size of 64KB. Each I/O incurs an overhead for transitions to kernel-mode and initiating an I/O transfer on the storage device, so in Windows Vista storage I/O request sizes are no longer capped. Several Windows Vista user-mode components have been modified to take advantage of the support for larger I/Os, including Explorer‘s copy functionality and the command prompt‘s Copy command, which now issue 1MB I/Os.
Next Up
Now you‘ve seen two areas in which the Windows Vista kernel has been enhanced. You can expect additional in-depth information in the next edition of my book, Windows Internals (coauthored with David Solomon), planned for release at the same time as the next version of Windows Server, code-named "Longhorn." In my next installment, I‘ll continue introducing you to the new kernel by discussing memory management along with system start up and shutdown.
Mark Russinovich is a Technical Fellow at Microsoft in the Platform and Services Division. He is a coauthor of Microsoft Windows Internals (Microsoft Press, 2004) and a frequent speaker at IT and developer conferences. He joined Microsoft with the recent acquisition of the company he cofounded, Winternals Software. He also created Sysinternals, where he published the Process Explorer, Filemon, and Regmon utilities.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.
Inside the Windows Vista Kernel: Part 2
Mark Russinovich
At a Glance:
Memory management Startup and shutdown Power management
Last month, in the first installment of this three-part series, I looked at Windows Vista kernel enhancements in the areas of processes and I/O.
This time I‘ll cover advances in the way Windows Vista manages memory, as well as major improvements to system startup, shutdown, and power management (Part One).
Every release of Windows® improves scalability and performance, and Windows Vista™ is no different. The Windows Vista Memory Manager includes numerous enhancements, like more extensive use of lock-free synchronization techniques, finer-grained locking, tighter data-structure packing, larger paging I/Os, support for modern GPU memory architectures, and more efficient use of the hardware Translation Lookaside Buffer. Plus, Windows Vista memory management now offers dynamic address space allocation for the requirements of different workloads.
Four performance-enhancing features that use new technologies make their operating system debut on Windows Vista: SuperFetch, ReadyBoost, ReadyBoot, and ReadyDrive. I‘ll discuss them in detail later in this article.
Dynamic Kernel Address Space
Windows and the applications that run on it have bumped their heads on the address space limits of 32-bit processors. The Windows kernel is constrained by default to 2GB, or half the total 32-bit virtual address space, with the other half reserved for use by the process whose thread is currently running on the CPU. Inside its half, the kernel has to map itself, device drivers, the file system cache, kernel stacks, per-session code data structures, and both non-paged (locked-in physical memory) and paged buffers allocated by device drivers. Prior to Windows Vista, the Memory Manager determined at boot time how much of the address space to assign to these different purposes, but this inflexibility sometimes led to situations where one of the regions became full while others still had plenty of available space. The exhaustion of an area can lead to application failures and prevent device drivers from completing I/O operations.
In 32-bit Windows Vista, the Memory Manager dynamically manages the kernel‘s address space, allocating and deallocating space to various uses as the demands of the workload require. Thus, the amount of virtual memory used to store paged buffers can grow when device drivers ask for more, and it can shrink when the drivers release it. Windows Vista will therefore be able to handle a wider variety of workloads and likewise the 32-bit version of the forthcoming Windows Server® code-named "Longhorn," will scale to handle more concurrent Terminal Server users.
Of course, on 64-bit Windows Vista systems, address space constraints are not currently a practical limitation and therefore require no special treatment as they are configured to their maximums.
Memory Priorities
Just as Windows Vista adds I/O priorities (as I discussed in the last installment), it also implements memory priorities. Understanding how Windows uses memory priorities requires grasping how the Memory Manager implements its memory cache, called the Standby List. On all versions of Windows prior to Windows Vista, when a physical page (which is typically 4KB in size) that‘s owned by a process was reclaimed by the system, the Memory Manager typically placed the page at the end of the Standby List. If the process wanted to access the page again, the Memory Manager took the page from the Standby List and reassigned it to the process. When a process wanted to use a new page of physical memory and no free memory was available, the Memory Manager gave it the page at the front the Standby List. This scheme treated all pages on the standby essentially as equals, using only the time they were placed on the list to sort them.
On Windows Vista, every page of memory has a priority in the range of 0 to 7, and so the Memory Manager divides the Standby List into eight lists that each store pages of a particular priority. When the Memory Manager wants to take a page from the Standby List, it takes pages from low-priority lists first. A page‘s priority usually reflects that of the thread that first causes its allocation. (If the page is shared, it reflects the highest of memory priorities of the sharing threads.) A thread inherits its page-priority value from the process to which it belongs. The Memory Manager uses low priorities for pages it reads from disk speculatively when anticipating a process‘s memory accesses.
By default, processes have a page-priority value of 5, but functions allow applications and the system to change process and thread page-priority values. The real power of memory priorities is realized only when the relative priorities of pages are understood at a macro-level, which is the role of SuperFetch.
SuperFetch
A significant change to the Memory Manager is in the way that it manages physical memory. The Standby List management used by previous versions of Windows has two limitations. First, the prioritization of pages relies only on the recent past behavior of processes and does not anticipate their future memory requirements. Second, the data used for prioritization is limited to the list of pages owned by a process at any given point in time. These shortcomings can result in scenarios like the "after lunch syndrome," where you leave your computer for a while and a memory-intensive system application runs (such as an antivirus scan or disk defragmentation). This application forces the code and data that your active applications had cached in memory to be overwritten by the memory-intensive activities. When you return, you experience sluggish performance as applications have to request their data and code from disk.
Windows XP introduced prefetching support that improved boot and application startup performance by performing large disk I/Os to preload memory with code and file system data that it expected, based on previous boots and application launches. Windows Vista goes a big step further with SuperFetch, a memory management scheme that enhances the least-recently accessed approach with historical information and proactive memory management.
SuperFetch is implemented in %SystemRoot%\System32\Sysmain.dll as a Windows service that runs inside a Service Host process (%SystemRoot%\System32\Svchost.exe). The scheme relies on support from the Memory Manager so that it can retrieve page usage histories as well as direct the Memory Manager to preload data and code from files on disk or from a paging file into the Standby List and assign priorities to pages. The SuperFetch service essentially extends page-tracking to data and code that was once in memory, but that the Memory Manager has reused to make room for new data and code. It stores this information in scenario files with a .db extension in the %SystemRoot%\Prefetch directory alongside standard prefetch files used to optimize application launch. Using this deep knowledge of memory usage, SuperFetch can preload data and code when physical memory becomes available.
Whenever memory becomes free-for example, when an application exits or releases memory-SuperFetch asks the Memory Manager to fetch data and code that was recently evicted. This is done at a rate of a few pages per second with Very Low priority I/Os so that the preloading does not impact the user or other active applications. Therefore, if you leave your computer to go to lunch and a memory-intensive background task causes the code and data from your active applications to be evicted from memory while you‘re gone, SuperFetch can often bring all or most of it back into memory before you return. SuperFetch also includes specific scenario support for hibernation, standby, Fast User Switching (FUS), and application launch. When the system hibernates, for example, SuperFetch stores data and code in the hibernation file that it expects (based on previous hibernations) will be accessed during the subsequent resume. In contrast, when you resume Windows XP, previously cached data must be reread from the disk when it is referenced.
See the sidebar "Watching SuperFetch" for a glimpse of how SuperFetch impacts available memory.
Watching SuperFetch
After you’ve used a Windows Vista system a while, you’ll see a low number for the Free Physical Memory counter on Task Manager’s Performance page. That’s because SuperFetch and standard Windows caching make use of all available physical memory to cache disk data. For example, when you first boot, if you immediately run Task Manager you should notice the Free Memory value decreasing as Cached Memory number rises. Or, if you run a memory-hungry program and then exit it (any of the freeware “RAM optimizers” that allocate large amounts of memory and then release the memory will work), or just copy a very large file, the Free number will rise and the Physical Memory Usage graph will drop as the system reclaims the deallocated memory. Over time, however, SuperFetch repopulates the cache with the data that was forced out of memory, so the Cached number will rise and the Free number will decline.
Watching memory(Click the image for a larger view)
ReadyBoost
The speed of CPUs and memory are fast outpacing that of hard disks, so disks are a common system performance bottleneck. Random disk I/O is especially expensive because disk head seek times are on the order of 10 milliseconds-an eternity for today‘s 3GHz processors. While RAM is ideal for caching disk data, it is relatively expensive. Flash memory, however, is generally cheaper and can service random reads up to 10 times faster than a typical hard disk. Windows Vista, therefore, includes a feature called ReadyBoost to take advantage of flash memory storage devices by creating an intermediate caching layer on them that logically sits between memory and disks.
ReadyBoost consists of a service implemented in %SystemRoot%\System32\Emdmgmt.dll that runs in a Service Host process, and a volume filter driver, %SystemRoot%\System32\Drivers\Ecache.sys. (Emd is short for External Memory Device, the working name for ReadyBoost during its development.) When you insert a flash device like a USB key into a system, the ReadyBoost service looks at the device to determine its performance characteristics and stores the results of its test in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Emdmgmt, seen in Figure 1.
Figure 1 ReadyBoost device test results in the registry (Click the image for a larger view)
If you aren‘t already using a device for caching, and the new device is between 256MB and 32GB in size, has a transfer rate of 2.5MB/s or higher for random 4KB reads, and has a transfer rate of 1.75MB/s or higher for random 512KB writes, then ReadyBoost will ask if you‘d like to dedicate up to 4GB of the storage for disk caching. (Although ReadyBoost can use NTFS, it limits the maximum cache size to 4GB to accommodate FAT32 limitations.) If you agree, then the service creates a caching file named ReadyBoost.sfcache in the root of the device and asks SuperFetch to prepopulate the cache in the background.
After the ReadyBoost service initializes caching, the Ecache.sys device driver intercepts all reads and writes to local hard disk volumes (C:\, for example), and copies any data being written into the caching file that the service created. Ecache.sys compresses data and typically achieves a 2:1 compression ratio so a 4GB cache file will usually contain 8GB of data. The driver encrypts each block it writes using Advanced Encryption Standard (AES) encryption with a randomly generated per-boot session key in order to guarantee the privacy of the data in the cache if the device is removed from the system.
When ReadyBoost sees random reads that can be satisfied from the cache, it services them from there, but because hard disks have better sequential read access than flash memory, it lets reads that are part of sequential access patterns go directly to the disk even if the data is in the cache.
ReadyBoot
Windows Vista uses the same boot-time prefetching as Windows XP did if the system has less than 512MB of memory, but if the system has 700MB or more of RAM, it uses an in-RAM cache to optimize the boot process. The size of the cache depends on the total RAM available, but is large enough to create a reasonable cache and yet allow the system the memory it needs to boot smoothly.
After every boot, the ReadyBoost service (the same service that implements the ReadyBoost feature just described) uses idle CPU time to calculate a boot-time caching plan for the next boot. It analyzes file trace information from the five previous boots and identifies which files were accessed and where they are located on disk. It stores the processed traces in %SystemRoot%\Prefetch\Readyboot as .fx files and saves the caching plan under HKLM\System\CurrentControlSet\Services\Ecache\Parameters in REG_BINARY values named for internal disk volumes they refer to.
The cache is implemented by the same device driver that implements ReadyBoost caching (Ecache.sys), but the cache‘s population is guided by the ReadyBoost service as the system boots. While the boot cache is compressed like the ReadyBoost cache, another difference between ReadyBoost and ReadyBoot cache management is that while in ReadyBoot mode, other than the ReadyBoost service‘s updates, the cache doesn‘t change to reflect data that‘s read or written during the boot. The ReadyBoost service deletes the cache 90 seconds after the start of the boot, or if other memory demands warrant it, and records the cache‘s statistics in HKLM\System\CurrentControlSet\Services\Ecache\Parameters\ReadyBootStats, as shown in Figure 2. Microsoft performance tests show that ReadyBoot provides performance improvements of about 20 percent over the legacy Windows XP prefetcher.
Figure 2 ReadyBoot Performance statistics (Click the image for a larger view)
ReadyDrive
ReadyDrive is a Windows Vista feature that takes advantage of new hybrid hard disk drives called H-HDDs. An H-HDD is a disk with embedded nonvolatile flash memory (also known as NVRAM). Typical H-HDDs include between 50MB and 512MB of cache, but the Windows Vista cache limit is 2TB.
Windows Vista uses ATA-8 commands to define the disk data to be held in the flash memory. For example, Windows Vista will save boot data to the cache when the system shuts down, allowing for faster restarting. It also stores portions of hibernation file data in the cache when the system hibernates so that the subsequent resume is faster. Because the cache is enabled even when the disk is spun down, Windows can use the flash memory as a disk-write cache, which avoids spinning up the disk when the system is running on battery power. Keeping the disk spindle turned off can save much of the power consumed by the disk drive under normal usage.
Boot Configuration Database
Windows Vista has enhanced several aspects of startup and shutdown. Startup has improved with the introduction of the Boot Configuration Database (BCD) for storing system and OS startup configuration, a new flow and organization of system startup processes, new logon architecture, and support for delayed-autostart services. Windows Vista shutdown changes include pre-shutdown notification for Windows services, Windows services shutdown ordering, and a significant change to the way the OS manages power state transitions.
One of the most visible changes to the startup process is the absence of Boot.ini from the root of the system volume. That‘s because the boot configuration, which on previous versions of Windows was stored in the Boot.ini text file, is now stored in the BCD. One of the reasons Windows Vista uses the BCD is that it unifies the two current boot architectures supported by Windows: Master Boot Record (MBR) and Extensible Firmware Interface (EFI). MBR is generally used by x86 and x64 desktop systems, while EFI is used by Itanium-based systems (though desktop PCs are likely to ship with EFI support in the near future). The BCD abstracts the firmware and has other advantages over Boot.ini, like its support for Unicode strings and alternate pre-boot executables.
The BCD is actually stored on disk in a registry hive that loads into the Windows registry for access via registry APIs. On PCs, Windows stores it in \Boot\Bcd on the system volume. On EFI systems, it‘s on the EFI system partition. When the hive is loaded, it appears under HKLM\Bcd00000000, but its internal format is undocumented so editing it requires the use of a tool like %SystemRoot%\System32\Bcdedit.exe. Interfaces for manipulating the BCD are also made available for scripts and custom editors through Windows Management Instrumentation (WMI) and you can use the Windows System Configuration Utility (%SystemRoot%\System32\Msconfig.exe) to edit or add basic parameters, like kernel debugging options.
The BCD divides platform-wide boot settings, like the default OS selection and the boot menu timeout, from OS-specific settings such as OS boot options and the path to the OS boot loader. For example, Figure 3 shows that when you run Bcdedit with no command-line options, it displays platform settings in the Windows Boot Manager section at the top of the output, followed by OS-specific settings in the Windows Boot Loader section.
Figure 3 Settings displayed in BCDEdit (Click the image for a larger view)
When you boot a Windows Vista installation, this new scheme divides the tasks that were handled by the operating system loader (Ntldr) on previous versions of Windows into two different executables: \BootMgr and %SystemRoot%\System32\Winload.exe. Bootmgr reads the BCD and displays the OS boot menu, while Winload.exe handles operating-system loading. If you‘re performing a clean boot, Winload.exe loads boot-start device drivers and core operating system files, including Ntoskrnl.exe, and transfers control to the operating system; if the system is resuming from hibernation, then it executes %SystemRoot%\System32\Winresume.exe to load the hibernation data into memory and resume the OS.
Bootmgr also includes support for additional pre-boot executables. Windows Vista comes with the Windows Memory Diagnostic (\Boot\Memtest.exe) pre-configured as an option for checking the health of RAM, but third parties can add their own pre-boot executables as options that will display in Bootmgr‘s boot menu.
Startup Processes
In previous versions of Windows, the relationship between various system processes was unintuitive. For example, as the system boots, the interactive logon manager (%SystemRoot%\System32\Winlogon.exe) launches the Local Security Authority Subsystem Service (Lsass.exe) and the Service Control Manager (Services.exe). Further, Windows uses a namespace container called a Session to isolate processes running in different logon sessions. But prior to Windows Vista, the user logged into the console shared Session 0, the session used by system processes, which created potential security issues. One such issue was introduced, for example, when a poorly written Windows service running in Session 0 displayed a user interface on the interactive console, allowing malware to attack the window through techniques like shatter attacks and possibly gain administrative privileges.
To address these problems, several system processes were re-architected for Windows Vista. Session Manager (Smss.exe) is the first user-mode process created during the boot as in previous versions of Windows, but on Windows Vista the Session Manager launches a second instance of itself to configure Session 0, which is dedicated solely to system processes. The Session Manager process for Session 0 launches the Windows Startup Application (Wininit.exe), a Windows subsystem process (Csrss.exe) for Session 0, and then it exits. The Windows Startup Application continues by starting the Service Control Manager, the Local Security Authority Subsystem, and a new process, Local Session Manager (Lsm.exe), which manages terminal server connections for the machine.
When a user logs onto the system, the initial Session Manager creates a new instance of itself to configure the new session. The new Smss.exe process starts a Windows subsystem process and Winlogon process for the new session. Having the primary Session Manager use copies of itself to initialize new sessions doesn‘t offer any advantages on a client system, but on Windows Server "Longhorn" systems acting as terminal servers, multiple copies can run concurrently to allow for faster logon of multiple users.
With this new architecture, system processes, including Windows services, are isolated in Session 0. If a Windows service, which runs in Session 0, displays a user interface, the Interactive Services Detection service (%SystemRoot%\System32\UI0Detect.exe) notifies any logged-on administrator by launching an instance of itself in the user‘s security context and displaying the message shown in Figure 4. If the user selects the "Show me the message" button, the service switches the desktop to the Windows service desktop, where the user can interact with the service‘s user interface and then switch back to their own desktop. For more on what happens at startup, see the sidebar "Viewing Startup Process Relationships."
Figure 4 Service has displayed a window (Click the image for a larger view)
Viewing Startup Process Relationships
You can use Process Explorer from Sysinternals (microsoft.com/technet/sysinternals) to see the process startup tree of Windows Vista.
The screenshot includes the Session column, which you can add through Process Explorer’s column dialog. The highlighted process is the initial Smss.exe. Below it is the Session 0 Csrss.exe and Wininit.exe, which are left-justified because their parent process, the instance of Smss.exe that configured Session 0, has exited. Wininit’s three children are Services.exe, Lsass.exe, and Lsm.exe.
Process Explorer identifies a set of processes as running in Session 1 and that’s the session I’m logged into through a Remote Desktop connection. Process Explorer displays processes running in the same account as itself with a blue highlight color. Finally, Session 2 was initialized to prepare for a user logging into the console and creating a new logon session. It’s in that session that Winlogon is running and using LogonUI to ask a new console user to “Press Ctrl+Alt+DELETE to Log on”, and in which Logonui.exe will ask the user for his credentials.
Startup process and session information(Click the image for a larger view)
Credential Providers
Even the logon architecture is changed on Windows Vista. On previous versions of Windows, the Winlogon process loaded the Graphical Identification and Authentication (GINA) DLL specified in the registry to display a logon UI that asked users for their credentials. Unfortunately, the GINA model suffers from several limitations, including the fact that only one GINA can be configured, writing a complete GINA is difficult for third parties, and custom GINAs that have non-standard user interfaces change the Windows user experience.
Instead of a GINA, Windows Vista uses the new Credential Provider architecture. Winlogon launches a separate process, the Logon User Interface Host (Logonui.exe), that loads credential providers that are configured in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Authentication\Credential Providers. Logonui can host multiple credential providers concurrently; in fact, Windows Vista ships with interactive (Authui.dll) and smartcard (Smart-cardcredentialprovider.dll) providers. To ensure a uniform user experience, LogonUI manages the user interface that is displayed to end users, but it also allows credential providers to specify custom elements like text, icons, and edit controls.
Delayed-Autostart Services
If you‘ve ever logged onto a Windows system immediately after it starts, you‘ve probably experienced delays before your desktop is fully configured and you can interact with the shell and any applications you launch. While you‘re logging on, the Service Control Manager is starting the many Windows services that are configured as automatic start services and therefore activate at boot time. Many services perform CPU and disk-intensive initializations that compete with your logon activities. To accommodate this, Windows Vista introduces a new service start type called delayed automatic start, which services can use if they don‘t have to be active immediately after Windows boots.
The Service Control Manager starts services configured for delayed automatic start after the automatic-start services have finished starting and it sets the priority of their initial thread to THREAD_PRIORITY_LOWEST. This priority level causes all the disk I/O the thread performs to be Very Low I/O priority. After a service finishes initializing, the Service Control Manager sets its priority to normal. The combination of the delayed start, low CPU and memory priority, and background disk priority greatly reduce interference with a user‘s logon. Many Windows services, including Background Intelligent Transfer, Windows Update Client, and Windows Media® Center, use the new start type to help improve the performance of logons after a boot.
Shutdown
A problem that‘s plagued Windows service writers is that during a Windows shutdown they have, by default, a maximum of twenty seconds to perform cleanup. Versions of Windows prior to Windows Vista haven‘t supported a clean shutdown that waits for all services to exit because a buggy service can hold up a shutdown indefinitely. Some services, like those that have network-related shutdown operations or have to save large amounts of data to disk, might require more time and so Windows Vista allows a service to request pre-shutdown notification.
When Windows Vista shuts down, the Service Control Manager first notifies those services asking for pre-shutdown notification. It will wait indefinitely for these services to exit, but if they have a bug and don‘t respond to queries, the Service Control Manager gives up and moves on after three minutes. Once all those services have exited or the timeout has expired, the Service Control Manager proceeds with legacy-style services shutdown for the rest of the services. The Group Policy and Windows Update services register pre-shutdown notification in a fresh Windows Vista installation.
The Group Policy and Windows Update services also use another Windows Vista services feature: shutdown ordering. Services have always been able to specify startup dependencies that the Service Control Manager honors to start services in an order that satisfies them, but until Windows Vista they have been unable to specify shutdown dependencies. Now services that register for pre-shutdown notification can also insert themselves into the list stored at HKLM\System\CurrentControlSet\Control\PreshutdownOrder and the Service Control Manager will shut them down according to their order. See the sidebar "Identifying a Delayed-Autostart and Pre-Shutdown Service" for more on these services.
Power Management
Sleep and hibernate are other forms of shutdown, and buggy power management in drivers and applications has been the curse of road warriors since Windows 2000 introduced power management to the Windows NT®-based line of Windows operating systems. Many users have expected their laptop system to suspend or hibernate when they closed the lid before embarking on a trip, only to arrive at their destination with a hot carrying case, a dead battery, and lost data. That‘s because Windows has always asked device drivers and applications for their consent to change power state and a single unresponsive driver or application could prevent a transition.
In Windows Vista, the kernel‘s Power Manager still informs drivers and applications of power-state changes so that they can prepare for them, but it no longer asks for permission. In addition, the Power Manager waits, at most, 20 seconds for applications to respond to change notifications, rather than the two minutes it waited on previous versions of Windows. As a result, Windows Vista users can be more confident that their systems are honoring hibernations and suspends.
Next Up
As mentioned earlier, this is the second installment in a three-part series. The first part covered Windows Vista kernel improvements in the areas of I/O and processes. This time, I looked at Windows Vista enhancements in memory management, startup, and shutdown. Next time, I‘ll conclude the series by describing changes to the kernel in the areas of reliability and security.
Identifying a Delayed-Autostart and Pre-Shutdown Service
The built-in SC command is updated in Windows Vista to show services configured as delayed autostart services:
Using SC to display start type(Click the image for a larger view)
Unfortunately, the SC command does not report services that have requested pre-shutdown notification, but you can use the PsService utility from Sysinternals to see that a service accepts pre-shutdown notification:
Viewing pre-shutdown status(Click the image for a larger view)
Mark Russinovich is a Technical Fellow at Microsoft in the Platform and Services Division. He is a coauthor of Microsoft Windows Internals (Microsoft Press, 2004) and a frequent speaker at IT and developer conferences. He joined Microsoft with the recent acquisition of the company he cofounded, Winternals Software. He also created Sysinternals, where he published the Process Explorer, Filemon, and Regmon utilities.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.
Inside the Windows Vista Kernel: Part 3
Mark Russinovich
At a Glance:
Reliability Recovery Security
This series has so far covered Windows Vista kernel enhancements related to processes, I/O, memory management, system startup, shutdown, and power management. In this third and final
installment, I take a look at features and improvements in the areas of reliability, recovery, and security.
One feature I‘m not covering in this series is User Account Control (UAC), which comprises several different technologies, including file system and registry virtualization for legacy applications, elevation consent for accessing administrative rights, and the Windows® Integrity Level mechanism for isolating processes running with administrative rights from less-privileged processes running in the same account. Look for my in-depth coverage of UAC internals in a future issue of TechNet Magazine.
Windows Vista™ improves the reliability of your system and your ability to diagnose system and application problems through a number of new features and enhancements. For example, the kernel Event Tracing for Windows (ETW) logger is always active, generating trace events for file, registry, interrupt, and other types of activity into a circular buffer. When a problem occurs, the new Windows Diagnostic Infrastructure (WDI) can capture a snapshot of the buffer and analyze it locally or upload it to Microsoft support for troubleshooting.
The new Windows Performance and Re­liability Monitor helps users correlate errors, such as crashes and hangs, with changes that have been made to system configuration. The powerful System Repair Tool (SRT) replaces the Recovery Console for off-line recovery of un­bootable systems.
There are three areas that rely on kernel-level changes to the system and so merit a closer look in this article: Kernel Transaction Manager (KTM), improved crash handling, and Previous Versions.
Kernel Transaction Manager
One of the more tedious aspects of software development is handling error conditions. This is especially true if, in the course of performing a high-level operation, an application has completed one or more subtasks that result in changes to the file system or registry. For example, an application‘s software updating service might make several registry updates, replace one of the application‘s executables, and then be denied access when it attempts to update a second executable. If the service doesn‘t want to leave the application in the resulting inconsistent state, it must track all the changes it makes and be prepared to undo them. Testing the error recovery code is difficult and consequently often skipped, so errors in the recovery code can negate the effort.
Applications written for Windows Vista can, with very little effort, gain automatic error recovery capabilities by using the new transactional support in NTFS and the registry with the Kernel Transaction Manager. When an application wants to make a number of related changes, it can either create a Distributed Transaction Coordinator (DTC) transaction and a KTM transaction handle, or create a KTM handle directly and associate the modifications of the files and registry keys with the transaction. If all the changes succeed, the application commits the transaction and the changes are applied, but at any time up to that point the application can roll back the transaction and the changes are then discarded.
As a further benefit, other applications don‘t see changes made in a transaction until the transaction commits, and applications that use the DTC in Windows Vista and the forthcoming Windows Server®, code-named "Longhorn," can coordinate their transactions with SQL Server™, Microsoft® Message Queue Server (MSMQ), and other databases. An application updating service that uses KTM transactions will therefore never leave the application in an inconsistent state. This is why both Windows Update and System Restore use transactions.
As the heart of transaction support, KTM allows transactional resource managers such as NTFS and the registry to coordinate their updates for a specific set of changes made by an application. In Windows Vista, NTFS uses an extension to support transactions called TxF. The registry uses a similar extension called TxR. These kernel-mode resource managers work with the KTM to coordinate the transaction state, just as user-mode resource managers use DTC to coordinate transaction state across multiple user-mode resource managers. Third parties can also use KTM to implement their own resource managers.
TxF and TxR both define a new set of file system and registry APIs that are similar to existing ones, except that they include a transaction parameter. If an application wants to create a file within a transaction, it first uses KTM to create the transaction, then passes the resulting transaction handle to the new-file creation API.
TxF and TxR both rely on the high-speed file system logging functionality of the Com­mon Log File System or CLFS (%Sys­tem­Root%\System32\Clfs.sys) that was introduced in Windows Server 2003 R2. TxR and TxF use CLFS to durably store transactional state changes before they commit a transaction. This allows them to provide transactional recovery and assurances even if power is lost. In addition to the CLFS log, TxR creates a set of related log files to track transaction changes to the system‘s registry file in %Systemroot%\System32\Config\Txr, as seen in Figure 1, as well as separate sets of log files for each user registry hive. TxF stores transactional data for each volume in a hidden directory on the volume that‘s named \$Ex­tend\$RmMetadata.
Figure 1 System registry hive TxR logging files  (Click the image for a larger view)
Enhanced Crash Support
When Windows encounters an unrecoverable kernel-mode error—whether due to a buggy device driver, faulty hardware, or the operating system—it tries to prevent corruption of on-disk data by halting the system after displaying the notorious "blue screen of death" and, if configured to do so, writing the contents of some or all of physical memory to a crash dump file. Dump files are useful because when you reboot from a crash, the Microsoft Online Crash Analysis (OCA) service offers to analyze them to look for the root cause. If you like, you can also analyze them yourself using theMicrosoft Debugging Tools for Windows).
In previous versions of Windows, however, support for crash dump files wasn‘t enabled until the Session Manager (%Systemroot%\Sys­tem32\Smss.exe) process initialized paging files. This meant that any critical errors before that point result in a blue screen, but no dump file. Since the bulk of device driver initialization occurs before Smss.exe starts, early crashes would never result in crash dumps, thus making diagnosis of the cause extremely difficult.
Windows Vista reduces the window of time where no dump file is generated by initializing dump file support after all the boot-start device drivers are initialized but before loading system-start drivers. Because of this change, if you do experience a crash during the early part of the boot process, the system can capture a crash dump, allowing OCA to help you resolve the problem. Further, Windows Vista saves data to a dump file in 64KB blocks, whereas previous versions of Windows wrote them using 4KB blocks. This change results in large dump files being written up to 10 times faster.
Application crash handling is also improved in Windows Vista. On previous versions of Windows, when an application crashed it executed an unhandled exception handler. The handler launched the Microsoft Ap­pli­cation Error Reporting (AER) process (%Systemroot%\System32\Dwwin.exe) to display a dialog indicating that the program has crashed and asking whether you wanted to send an error report to Microsoft. However, if the stack of the process‘s main thread was corrupted during the crash, the unhandled exception handler crashed when it executed, resulting in termination of the process by the kernel, the instant disappearance of the program‘s windows, and no error reporting dialog.
Windows Vista moves error handling out of the context of the crashing process into to a new service, Windows Error Reporting (WER). This service is implemented by a DLL (%Sys­temroot%\System32\Wersvc.dll) inside a Service Hosting process. When an application crashes, it still executes an unhandled exception handler, but that handler sends a message to the WER service and the service launches the WER Fault Reporting process (%Systemroot%\System32\Werfault.exe) to display the error reporting dialog. If the stack is corrupted and the unhandled exception handler crashes, the handler executes again and crashes again, eventually consuming all the thread‘s stack (scratch memory area), at which point the kernel steps in and sends the crash notification message to the service.
You can see the contrast in these two approaches in Figures 2 and 3, which show the process relationship of Accvio.exe, a test program that crashes, and the error reporting processes highlighted in green, on Windows XP and Windows Vista. The new Windows Vista error handling architecture means that programs will no longer silently terminate without offering the chance for Microsoft to obtain an error report and help software developers improve their applications.
Figure 2a Application error handling in Windows XP (Click the image for a larger view)
Figure 2b(Click the image for a larger view)
Figure 3a Application error handling in Windows Vista (Click the image for a larger view)
Figure 3b
Volume Shadow Copy
Windows XP introduced a technology called Volume Shadow Copy to make point-in-time snapshots of disk volumes. Backup applications can use these snapshots to make consistent backup images, but the snapshots are otherwise hidden from view and kept only for the duration of the backup process.
The snapshots are not actually full copies of volumes. Rather, they are views of a volume from an earlier point that comprise the live volume data overlaid with copies of volume sectors that have changed since the snapshot was taken. The Volume Snapshot Provider driver (%Systemroot\%System32\Drivers\Volsnap.sys) monitors operations aimed at volumes and makes backup copies of sectors before allowing them to change, storing the original data in a file associated with the snapshot in the System Volume Information directory of the volume.
Windows Server 2003 exposed snapshot management to administrators on the server and to users on client systems with its Shadow Copies for Shared Folders. This feature enabled persistent snapshots that users could access via a Previous Versions tab on the Explorer properties dialog boxes for their folders and files located on the server‘s file shares.
The Windows Vista Previous Versions feature brings this support to all client systems, automatically creating volume snapshots, typically once per day, that you can access through Explorer properties dialogs using the same interface used by Shadow Copies for Shared Folders. This enables you to view, restore, or copy old versions of files and directories that you might have accidentally modified or deleted. While technically not new technology, the Windows Vista Previous Versions implementation of Volume Shadow Copy optimizes that of Windows Server 2003 for use in client desktop environments.
Windows Vista also takes advantage of volume snapshots to unify user and system data protection mechanisms and avoid saving redundant backup data. When an application installation or configuration change causes incorrect or undesirable behaviors, you can use System Restore, a feature introduced into the Windows NT® line of operating systems in Windows XP, to restore system files and data to their state as it existed when a restore point was created.
In Windows XP, System Restore uses a file system filter driver—a type of a driver that can see changes at the file level—to make backup copies of system files at the time they change. On Windows Vista, System Restore uses volume snapshots. When you use the System Restore user interface in Windows Vista to go back to a restore point, you‘re actually copying earlier versions of modified system files from the snapshot associated with the restore point to the live volume.
BitLocker
Windows Vista is the most secure version of Windows yet. In addition to the inclusion of the Windows Defender antispyware engine, Windows Vista introduces numerous security and defense-in-depth features, including BitLocker™ full-volume encryption, code signing for kernel-mode code, protected processes, Address Space Load Randomization, and improvements to Windows service security and User Account Control.
An operating system can only enforce its security policies while it‘s active, so you have to take additional measures to protect data when the physical security of a system can be compromised and the data accessed from outside the operating system. Hardware-based mechanisms such as BIOS passwords and encryption are two technologies commonly used to prevent unauthorized access, especially on laptops, which are most likely to be lost or stolen.
Windows 2000 introduced the Encrypting File System (EFS) and, in its Windows Vista incarnation, EFS includes a number of improvements over previous implementations, including performance enhancements, support for encrypting the paging file, and storage of user EFS keys on smart cards. However, you can‘t use EFS to protect access to sensitive areas of the system, such as the registry hive files. For example, if Group Policy allows you to log onto your laptop even when you‘re not connected to a domain, then your domain credential verifiers are cached in the registry, so an attacker could use tools to obtain your domain account password hash and use that to try to obtain your password with a password cracker. The password would gain them access to your account and EFS files (assuming you didn‘t store the EFS key on a smart card).
To make it easy to encrypt the entire boot volume (the volume with the Windows directory), including all its system files and data, Windows Vista introduces a full-volume encryption feature called Windows BitLocker Drive Encryption. Unlike EFS, which is implemented by the NTFS file system driver and operates at the file level, BitLocker encrypts at the volume level using the Full Volume En­cryption (FVE) driver (%Systemroot%\Sys­tem32\Drivers\Fve­vol.sys) as diagrammed in Figure 4.
Figure 4 BitLocker FVE filter driver (Click the image for a larger view)
FVE is a filter driver so it automatically sees all the I/O requests that NTFS sends to the volume, encrypting blocks as they‘re written and decrypting them as they‘re read using the Full Volume Encryption Key (FVEK) assigned to the volume when it‘s initially configured to use BitLocker. By default, volumes are encrypted using a 128-bit AES key and a 128-bit diffuser key. Because the encryption and decryption happen beneath NTFS in the I/O system, the volume appears to NTFS as if it‘s unencrypted and NTFS does not even need to be aware that BitLocker is enabled. If you attempt to read data from the volume from outside of Windows, however, it appears to be random data.
The FVEK is encrypted with a Volume Master Key (VMK) and stored in a special metadata region of the volume. When you configure BitLocker, you have a number of options for how the VMK will be protected, depending on the system‘s hardware capabilities. If the system has a Trusted Platform Module (TPM) that conforms to v1.2 of the TPM specification and has associated BIOS support, then you can either encrypt the VMK with the TPM, have the system encrypt the VMK using a key stored in the TPM and one stored on a USB flash device, or encrypt the key using a TPM-stored key and a PIN you enter when the system boots. For systems that don‘t have a TPM, BitLocker offers the option of encrypting the VMK using a key stored on an external USB flash device. In any case you‘ll need an unencrypted 1.5GB NTFS system volume, the volume where the Boot Manager and Boot Configuration Database (BCD) are stored.
The advantage of using a TPM is that Bit­Locker uses TPM features to ensure that it will not decrypt the VMK and unlock the boot volume if the BIOS or the system boot files have changed since BitLocker was enabled. When you encrypt the system volume for the first time, and each time you perform updates to any of the components mentioned, BitLocker calculates SHA-1 hashes of these components and stores each hash, called a measurement, in different Platform Configuration Registers (PCR) of the TPM with the help of the TPM device driver (%Systemroot%\Sys­tem32\Drivers\Tpm.sys). It then uses the TPM to seal the VMK, an operation that uses a private key stored in the TPM to encrypt the VMK and the values stored in the PCRs along with other data BitLocker passes to the TPM. BitLocker then stores the sealed VMK and encrypted FVEK in the volume‘s metadata region.
When the system boots, it measures its own hashing and PCR loading code and writes the hash to the first PCR of the TPM. It then hashes the BIOS and stores that measurement in the appropriate PCR. The BIOS in turn hashes the next component in the boot sequence, the Master Boot Record (MBR) of the boot volume, and this process continues until the operating system loader is measured. Each subsequent piece of code that runs is responsible for measuring the code that it loads and for storing the measurement into the appropriate register in the TPM. Finally, when the user selects which operating system to boot, the Boot Manager (Bootmgr) reads the encrypted VMK from the volume and asks the TPM to unseal it. Only if all the measurements are the same as when the VMK was sealed, including the optional PIN, will the TPM successfully decrypt the VMK.
You can think of this scheme as a verification chain, where each component in the boot sequence describes the next component to the TPM. Only if all the descriptions match the original ones given to it will the TPM divulge its secret. BitLocker therefore protects the encrypted data even when the disk is removed and placed in another system, the system is booted using a different operating system, or the unencrypted files on the boot volume are compromised.
Code Integrity Verification
Malware that is implemented as a kernel-mode device driver, including rootkits, runs at the same privilege level as the kernel and so is the most difficult to identify and remove. Such malware can modify the behavior of the kernel and other drivers so as to become virtually invisible. The Windows Vista code integrity for kernel-mode code feature, also known as kernel-mode code signing (KMCS), only allows device drivers to load if they are published and digitally signed by developers who have been vetted by one of a handful of certificate authorities (CAs). KMCS is enforced by default on Windows Vista for 64-bit systems.
Because certificate authorities charge a fee for their services and perform basic background checks, such as verifying a business identity, it‘s harder to produce anonymous kernel-mode malware that runs on 64-bit Windows Vista. Further, malware that does manage to slip through the verification process can potentially leave clues that lead back to the author when the malware is discovered on a compromised system. KMCS also has secondary uses, like providing contact information for the Windows Online Crash Analysis team when a driver is suspected of having a bug that‘s crashing customer systems, and unlocking high-definition multimedia content, which I‘ll describe shortly.
KMCS uses public-key cryptography technologies that have been employed for over a decade by Windows and requires that kernel-mode code include a digital signature generated by one of the trusted certificate authorities. If a publisher submits a driver to the Microsoft Windows Hardware Quality Laboratory (WHQL) and the driver passes reliability testing, then Microsoft serves as the certificate authority that signs the code. Most publishers will obtain signatures via WHQL, but when a driver has no WHQL test program, the publisher doesn‘t want to submit to WHQL testing, or the driver is a boot-start driver that loads early in system startup, the publishers must sign the code themselves. To do so, they must first obtain a code-signing certificate from one of the certificate authorities that Microsoft has identified as trusted for kernel-mode code signing. The author then digitally hashes the code, signs the hash by encrypting it with a private key, and includes the certificate and encrypted hash with the code.
When a driver tries to load, Windows decrypts the hash included with the code using the public key stored in the certificate, 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, which is 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. Attempts to load an unsigned 64-bit driver should never occur on a production system, so unlike the Plug and Play Manager, which displays a warning dialog when it‘s directed to load a driver that doesn‘t have a signature confirming that it‘s been through WQHL testing, 64-bit Windows Vista silently writes an event to the Code Integrity application event log, like the one shown in Figure 5, anytime it blocks the loading of an unsigned driver. 32-bit Win­dows Vista also checks driver signatures, but allows unsigned drivers to load. Blocking them would break upgraded Windows XP systems that require drivers that were loaded on Windows XP, and also allows support for hardware for which only Windows XP drivers exist. However, 32-bit Windows Vista also writes events to the Code Integrity event log when it loads an unsigned driver.
Figure 5 Unsigned driver load attempt events (Click the image for a larger view)
Because code signing is commonly used to label code as a rigorously tested official release, publishers typically don‘t want to sign test code. Windows Vista therefore includes a test-signing mode you can enable and disable with the Bcdedit tool (described in my March 2007 TechNet Magazine article), where it will load kernel-mode drivers digitally signed with a test certificate generated by an in-house certificate authority. This mode is designed for use by programmers while they develop their code. When Windows is in this mode, it displays markers on the desktop like the one in Figure 6.
Figure 6 Windows Vista test-signing mode
Protected Processes
Next-generation multimedia con­tent, like HD-DVD, BluRay, and other formats licensed under the Advanced Access Content System (AACS), will become more common over the next few years. Windows Vista includes a number of technologies, collectively called Protected Media Path (PMP), that are required by the AACS standard for such content to be played. PMP includes Protected User-Mode Audio (PUMA) and Protected Video Path (PVP) that together provide mechanisms for audio and video drivers, as well as media player applications, to prevent unauthorized software or hardware from capturing content in high-definition form.
PUMA and PVP define interfaces and support specific to audio and video players, device drivers, and hardware, but PMP also relies on a general kernel mechanism introduced in Windows Vista called a protected process. Protected processes are based on the standard Windows process construct that encapsulates a running executable image, its DLLs, security context (the account under which the process is running and its security privileges), and the threads that execute code within the process, but prevent certain types of access.
Standard processes implement an access control model that allows full access to the owner of the process and administrative accounts with the Debug Programs privilege. Full access allows a user to view and modify the address space of the process, including the code and data mapped into the process. Users can also inject threads into the process. These types of access are not consistent with the requirements of PMP because they would allow unauthorized code to gain access to high-definition content and Digital Rights Management (DRM) keys stored in a process that is playing the content.
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. But 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 so don‘t require direct access to the process. Accesses that could compromise media are allowed only by other protected processes.
Further, to prevent compromise from within, all executable code loaded into a protected process, including its executable image and DLLs, must be either signed by Microsoft (WHQL) with a Protected Environment (PE) flag, or if it‘s an audio codec, signed by the developer with a DRM-signing certificate obtained from Microsoft. Because kernel-mode code can gain full access to any process, including protected processes, and 32-bit Windows allows unsigned kernel-mode code to load, the kernel provides an API for protected processes to query the "cleanliness" of the kernel-mode environment and use the result to unlock premium content only if no unsigned code is loaded.
Identifying a Protected Process
There are no APIs that specifically identify protected processes, but you can indirectly identify them based on the limited information available for them and the inability to debug them even from an administrative account. The Audio Device Graph Isolation process (%Systemroot%\System32\Audiodg.exe) is used to play Content Scramble System (CSS)-encoded DVDs and is identifiable as a protected process in the Task Manager pane by the fact that Task Manager can’t obtain its command line, virtualization, and Data Execution Prevent status even when it is run with administrative rights.
Task Manager viewing the audiodg protected process(Click the image for a larger view)
Address Space Load Randomization
Despite measures like Data Execution Prevention and enhanced compiler error checking, malware authors continue to find buffer overflow vulnerabilities that allow them to infect network-facing processes like Internet Explorer®, Windows services, and third-party applications to gain a foothold on a system. Once they have managed to infect a process, however, they must use Windows APIs to accomplish their ultimate goal of reading user data or establishing a permanent presence by modifying user or system configuration settings.
Connecting an application with API entry points exported by DLLs is something usually handled by the operating system loader, but these types of malware infection don‘t get the benefit of the loader‘s services. This hasn‘t posed a problem for malware on previous versions of Windows because for any given Windows release, system executable images and DLLs always load at the same location, allowing malware to assume that APIs reside at fixed addresses.
The Windows Vista Address Space Load Randomization (ASLR) feature makes it impossible for malware to know where APIs are located by loading system DLLs and executables at a different location every time the system boots. Early in the boot process, the Memory Manager picks a random DLL image-load bias from one of 256 64KB-aligned addresses in the 16MB region at the top of the user-mode address space. As DLLs that have the new dynamic-relocation flag in their image header load into a process, the Memory Manager packs them into memory starting at the image-load bias address and working its way down.
Executables that have the flag set get a similar treatment, loading at a random 64KB-aligned point within 16MB of the base load address stored in their image header. Further, if a given DLL or executable loads again after being unloaded by all the processes using it, the Memory Manager reselects a random location at which to load it. Figure 7 shows an example address-space layout for a 32-bit Windows Vista system, including the areas from which ASLR picks the image-load bias and executable load address.
Figure 7 ASLR‘s effect on executable and DLL load addresses (Click the image for a larger view)
Only images that have the dynamic-relocation flag, which includes all Windows Vista DLLs and executables, get relocated because moving legacy images could break internal assumptions that developers have made about where their images load. Visual Studio® 2005 SP1 adds support for setting the flag so that third-party developers can take full advantage of ASLR.
Randomizing DLL load addresses to one of 256 locations doesn‘t make it impossible for malware to guess the correct location of an API, but it severely hampers the speed at which a network worm can propagate and it prevents malware that only gets one chance at infecting system from working reliably. In addition, ASLR‘s relocation strategy has the secondary benefit that address spaces are more tightly packed than on previous versions of Windows, creating larger regions of free memory for contiguous memory allocations, reducing the number of page tables the Memory Manager allocates to keep track of address-space layout, and minimizing Translation Lookaside Buffer (TLB) misses.
Service Security Improvements
Windows services make ideal malware targets. Many offer network access to their functionality, possibly exposing remotely exploitable access to a system, and most run with more privilege than standard user accounts, offering the chance to elevate privileges on a local system if they can be compromised by malware. For this reason, Windows started evolving with changes made in Windows XP SP2 that reduced the privileges and access assigned to services to just those needed for their roles. For example, Windows XP SP2 introduced the Local Service and Network Service accounts that include only a subset of the privileges available to the account in which services always previously ran, Local System. This minimizes the access an attacker gains when exploiting a service.
Seeing ASLR in Action
You can easily see the effects of ASLR by comparing the DLL load addresses for a process in two different boot sessions using a tool likeProcess Explorer from Sysinternals. In these two screenshots, taken from two different sessions, Ntdll.dll loaded into Explorer first at address 0x77A30000 and then at address 0x77750000.
Different base addresses for ntdll.dll(Click the image for a larger view)
Different base addresses for ntdll.dll(Click the image for a larger view)
In my previous article, I described how services run isolated from user accounts in their own session, but Windows Vista also expands its use of the principle of least privilege by further reducing the privileges and access to the files, registry keys, and firewall ports it assigns to most services. Windows Vista defines a new group account, called a service Security Identifier (SID), unique to each service. The service can set permissions on its resources so that only its service SID has access, preventing other services running in the same user account from having access if a service becomes compromised. You can see a service‘s SID by using the sc showsid command followed by the service name, as seen in Figure 8.
Figure 8 Viewing a service SID (Click the image for a larger view)
Service SIDs protect access to resources owned by a particular service, but by default services still have access to all the objects that the user account in which they run can access. For example, a service running in the Local Service account might not be able to access resources created by another service running as Local Service in a different process that has protected its objects with permissions referencing a service SID, however, it can still read and write any objects to which Local Service (and any groups to which Local Service belongs, like the Service group) has permissions.
Windows Vista therefore introduces a new restricted service type called a write-restricted service that permits a service write access only to objects accessible to its service SID, the Everyone group, and the SID assigned to the logon session. To accomplish this, it uses restricted SIDs, a SID type introduced back in Windows 2000. When the process opening an object is a write-restricted service, the access-check algorithm changes so that a SID that has not been assigned to a process in both restricted and unrestricted forms cannot be used to grant the process write access to an object. You can see if a service is restricted with the following command:
Copy Code
sc qsidtype [service]
Another change makes it easy for a service to prevent other services running in the same account from having access to the objects it creates. In previous versions of Windows, the creator of an object is also the object‘s owner, and owners have the ability to read and change the permissions of their objects, allowing them full access to their own objects. Windows Vista introduces the new Owner Rights SID, which, if present in an object‘s permissions, can limit the accesses an owner has to its own object, even removing the right to set and query the permissions.
A further enhancement to the service security model in Windows Vista enables a service developer to specify exactly what security privileges the service needs to operate when the service registers on a system. For example, if the service needs to generate audit events it could list the Audit privilege.
When the Service Control Manager starts a process that hosts one or more Windows services, it creates a security token (the kernel object that lists a process user account, group memberships, and security privileges) for the process that includes only the privileges required by the services in the process. If a service specifies a privilege that is not available to the account in which it runs, then the service fails to start. When none of the services running in a Local Service account process need the Debug Programs privilege, for example, the Service Control Manager strips that privilege from the process‘s security token. Thus, if the service process is compromised, malicious code cannot take advantage of privileges that were not explicitly requested by the services running in the process. The sc qprivs command reports the privileges that a service has requested.
Conclusion
This concludes my three-part look at Windows Vista kernel changes. There are features and improvements I didn‘t cover or mention, like a new worker thread pool for application developers, new synchronization mechanisms such as shared reader/writer locks, service thread tagging, support for online NTFS disk checking and volume resizing, and a new kernel IPC mechanism called Advanced Local Procedure Call (ALPC). Look for more information on these and other features in the next edition of Windows Internals, scheduled for publication by the end of 2007.
Viewing Write-Restricted Service
Only one service-hosting process on Windows Vista hosts restricted services and you can identify it with a process-viewing tool like Process Explorer as the one that has the command line:
Copy Code
svchost -k LocalServiceNoNetwork
Services configured to run in this process include Base Filtering Engine, Diagnostic Policy Service, Windows Firewall, Performance Logs and Alerts, and Windows Media® Center Service Starter.
This screen shows the textual form of the Base Filtering Engine’s service SID, NT SERVICE\BFE, listed once with the Restricted flag and again without it, so the process has access to resources accessible to that account. It doesn’t necessarily have access to other objects normally accessible to the Local Service account, however. For instance, because the NT AUTHORITY\SERVICE account doesn’t appear in the process token with the restricted flag, the process can’t modify objects that grant write access only to that account but not to other accounts in the token that have the restricted flag.
The services running in this process also limit their privileges, because the privileges listed at the bottom of the properties dialog are a subset of those available to the Local Service account.
SID flags on a service(Click the image for a larger view)
Mark Russinovich is a Technical Fellow at Microsoft in the Platform and Services Division. He‘s coauthor of Microsoft Windows Internals (Microsoft Press, 2004) and a frequent speaker at IT and developer conferences, including Microsoft Tech•Ed and the PDC. He joined Microsoft with the acquisition of the company he co-founded, Winternals Software. He also created Sysinternals, where he published many popular utilities, including Process Explorer, Filemon, and Regmon.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.