解决方案－Soc发展概观(下)
多核SoC时代的终极演化　Network-On-Chip （林宗辉／DigiTimes.com） 2006/12/25  
目前SoC的发展限制

SoC指的是在单一芯片上进行操作的迷你计算机系统，构成一个完整的SoC平台，必须要包含硬件部分以及软件部分，在软件部分，我们以手机的运算需求为例，一般而言，我们可以将通话过程的上行和下行任务视为并行的任务，而其它方面的功能，比如说简讯、记事、玩游戏、上网、听MP3等等，基本上都被视为优先权较低的执行绪，即使多个任务同时存在于存储器中，最多也只能同时操作一个，而当电话接通时，基本上所有的次要执行绪都将被中断，转而将处理器效能移为通话之用。


图说：标准单芯片手机架构图。（资料来源：Silicon Laboratories）

而面对越来越多需要同时处理的工作时，除在软件端支持多执行绪以外，芯片内建多运算核心架构也是随之而来的必要过程。然而一个多工系统在进行软硬件协同设计是非常复杂的工作，这是由于多核心芯片架构中，通常会包含多个处理器IP以及相对应的互连结构，不仅在软件撰写时要考虑到资源的分配合理性，执行阶段要避免overhead等等。虽然如此，基于以下的理由，采用多核心架构仍有其必要。首先，每个核心都需要透过软件来完成特定的任务，因此多核心架构基本上等同于允许单一芯片的多用途特性，由于偏向于通用性，因此很容易被不同性质的平台所采用。

不过虽然多核心架构的并行分配方式为应用程序提供了极大的空间以及选择余地，但是对于采用何种算法来进行多任务的调度与运算能量分配，却造成了相当大的难题。简单来说，如果有多个任务流程需要并行处理，每个任务流程都有其不同的性能需求，若是采用多核心架构来进行处理，则必须透过软件来进行调配。简单来说，就是决定哪里个任务由哪里个核心来处理，以及该在哪里个时间来执行这两个考量，而影响因素则包括了特定节点的执行速度、传输延迟以及处理器的工作储列的多寡。

最能适应这种运算架构的，就非Network-On-Chip（后简称NOC）莫属了，简单来说，NOC是将应用处理器（Application Process Unit；APU）群利用区域网络的路由节点结构互连的一种单芯片内部封包交换网络通讯系统。各个APU之间的沟通都是透过类似于TCP/IP的协定的封包交换，而非传统的电路/汇流排交换，在这种架构上的任务进行方式，便是在多工操作系统中的每个任务流程都能依照其deadline需求，将任务节点拓朴到合适的处理器上进行。


图说：NOC架构概念图。（资料来源：麻省理工学院）

传统基于ASIC基础而发展出来的SoC架构，基本上都还是使用汇流排架构设计，虽然在一对一的资料传输中，汇流排可以很好的负担起来，但是在面对多对多的运算架构之下，其定址空间的局限性与同时间传输对象数量的限制，就很难有出色的表现了。而且汇流排必须随著芯片制程与技术的进步不断的进行改版，这对于SoC的设计有著不良的影响，当要推出新一代的产品时，就必须伴随著汇流排界面的修改，因此也会拉长产品从设计到上市的时程。

芯片制程演化对NOC的影响

随著芯片规模的不断微缩，以及随之成等比级数增加的单一芯片晶体管数量，我们可以预想到，单一芯片上可以包含越来越多的IP数量。这样的发展趋势给了业界几个相当大的挑战，首先，在整合庞大规模的设计时，将会面对因为同时提出要求的处理单元过多，导致汇流排阻塞的现象。虽然汇流排可以连结多个节点，由多个处理单元共享，但是汇流排架构有个限制，那就是同时间只能有一个传送端与一个接收端动作，其余有传输需求的节点只能乖乖排队，因此就针对多核心架构的传输需求来谈，汇流排架构的效率显得相当低。

其次，虽然次微米技术理论上可以有效减少闸极延迟的问题，但是导线延迟仍会显著的增加，虽然可藉由附加继电器来维持延迟不变，但是附加继电器的方式将会使得芯片面积以及芯片耗电量大为增加，不符合经济效益。而现有的NOC（Network on chip）设计大多仍依循著时脉同步以及不可变规模（non-scalable）汇流排架构，而基本上这样的设计已经明显不符设计、生产以及应用上的需求。

而为了克服以上的问题，采用基于在普通PC网络环境上被广为采用的交换式架构，就成了十分合理的解决方式。如前所述，应用到NOC之中的交错连结架构（Interconnection Architecture）是个具有高效能表现的平行运算架构，在设计上，不同IP之间的沟通都是透过基于封包的形式传输，在此设计之下，总体布线的影响已经是可忽略的了，线路都被用于交换器的连结，而我们也不再需要担心由于对节点之间的去耦而导致的整体同步的问题，且基于封包的架构也可以有效改善传统采用实体通道设计所会产生电子噪音的问题。

而随著芯片网络拓朴的导入，也引进了原先在架构区域网络上应用的两个相当优秀的连结架构，这两大架构分别是网状架构（Mesh Architecture）以及树状架构（FAT TREE Architecture）。网状架构意即在两个节点之间存在著不只单一个通道，而是具有多重路径交互连结，而树状架构则是呈树枝状分支延伸，两个节点之间只有单一通道，而当资料进入任何一个节点之后，就会向所有的分支传递，因此树状架构也具有广播传送的特性。这个架构是由麻省理工学院Computer Science与Electrical Engineering的教授Leiserson所提出，树状架构有几个相当大的优点：具备良好的延展性、可靠性高、简单而规律的拓朴、高输出率以及高效能表现，一般来说，树状架构拥有比网状架构更优秀的效能表现。除了这两种网络架构以外，还有其实一般网络常用的环状、 意法半导体所提出的蛛网状等，各有其应用上的优势所在。

NOC的设计概念


图说：NOC的设计流程。（资料来源：arteris）

传统汇流排时脉必须同步的方式，在导入汇流排设计时，会随著芯片时脉的增加，而必须增加延迟的时间，随著制程的微缩，芯片操作时脉越趋增加，2007年已经可以得见时脉高达6GHz的处理器产品，若是采用传统汇流排架构设计，汇流排的延迟将会影响到整体时脉树状网络的设计，进而影响到芯片产品的耗电量与效能表现。

有监于此在1999年左右，几个研究小组提出了NOC（Network on chip）的设计概念，说起来其实很单纯，其实不过就是把计算机网络技术移植到芯片内部，取代了传统的汇流排传输架构，不过这样做有两大好处：

■NOC不仅具有良好的空间可扩展性，并且也提供了非常优秀的平行通讯能力。

■NOC以交换式封包传输最为基本通讯技术，并且采用了全体非同步局部同步的GALS（Globally Asynchronous Locally Synchronous）技术，每个资源节点都具有独立的时脉区域，而不同的节点之间则是利用通讯节点进行非同步传输，因此不同的处理单元之间就可以以最为有利的时脉运行，而不需因迁就于汇流排而统一时脉。

从NOC架构提出之后，包括Bologna、KAIST、KTH、LIP-6、MIT、UCSD、Manchester、Stanford、Tampere和Technion以 及飞利浦研究实验室、意法半导体和VTT技术研究中心等产业研究实验室都已经积极的在发展相关领域的技术。虽然目前的研究报告指称，新的NOC架构对未来的MPSoC（多核SoC）极具吸引力，但是有很多细节问题还尚未解决。例如，选择适合的拓朴、路由选择和流量控制策略、伫列管理策略、资料封包／消息格式和节点到节点的网络服务类型。

NOC虽然还在发展初期，但是其潜力无穷，各大半导体厂商都已经着手进行实际产品的研究与开发，比如说Intel就已经发表过一款80核心的NOC试作品，并且公开表示，当制程技术进步到45nm时，便有可能实际商品化，而以Intel的制程技术演进来看，45nm已经接近完备，而32nm制程也已经有个初步成果，若是预言成真，那么我们将可以在未来的一两年内看到实际产品。

基于网络架构的NOC设计


图说：NOC的封包架构堆叠。（资料来源：ISO）

在NOC设计过程中，通讯是指系统中各元件之间所进行的讯息交换过程，这种〝行为〞与系统中的另一个行为—计算具有同等重要的地位。过去一款芯片的设计，往往都是着重于其计算能力的加强，而非通讯架构的改进。而汇流排架构本来就很难有什么突破性的发展，但是为了配合芯片计算能力的演进，必须跟随著处理能力的需求而变更设计，比如说更高的存储器宽度、更高的时脉、更灵活的同步或非同步设计等等，每一代芯片的推出都伴随著程度不等的设计变更，因此在通讯架构上的可沿用性不佳，对于开发人员而言是相当大的负担。若是将通讯架构独立设计，并且运用更具弹性的技术，那么对于缩短设计时程、减少开发成本都有不小的助益。

从通讯架构来看，由于NOC所使用的通讯协议层本身是属于独立的资源，理应可以在不同的抽象层次上被描述，在设计采用的方式上就有更多的选择。通讯与计算架构的分离就必须彻底，具备了独立的通讯架构，芯片也可朝模块化设计方式进行，单纯化的设计也能提高特定功能模块的可重复利用性，避免了牵一发就必须动全身的结果。

协议层透过详细定义的界面相互作用，为程序设计人员提供了一个通讯框架的抽象概念。协议堆叠隐藏了下层的实体层深次微米技术问题，使网络服务如服务质量机制得以高效实现。在这种设计流程中，经过验证的IP模块经过配置，也可以透过自己的NoC界面与其它SoC组件通讯。

虽然芯片本身的计算能力不断加强，但要能发挥全部的计算潜力，也必须要依赖通讯架构能够持续不间断的供给庞大的资料传输量，就拿现在的PC架构来说，中央处理器改朝换代的速度越来越快，理论速度也越来越高，但是表现给使用者的效能呈现却未能如预期般的增长，换句话说，目前的运算架构有很大一部分的瓶颈要落于通讯架构上。

NOC采用计算与通讯分离的架构之后，处理单元执行计算任务，只需将处理完成的资料往网络交换架构一丢，就不需要担心其它如资料传输流程等杂事，而是全权交由通讯节点来进行处理，这有点类似过去硬碟由PIO模式转移到DMA模式的概念，通讯节点将资料从来源端沿著特定的路径发送到接收端的过程有专属的处理单元在进行，这个处理单元可以视为通讯中枢，在设计上，能够整合于芯片内部，也能独立出来，端视设计者与客户方面的需求。不过通讯中枢的功能有限，如何最佳化传输流程手法也各有不同。有研究者提出了预测竞争的路由算法（Contention-look-ahead Routing Algorithm），透过监控相邻通讯节点之间的负载状况，可以为当前通讯节点的路由做出选择。不过这种算法只能预测下一步，而无法综观整个通讯网络的负载状况，因此也被称为局部区域的最佳化机制，滥用局部区域的最佳化，将有可能造成总体传输效能的冲击。

一般来说，理想的状况是在资料从原始发送节点准备出发时，就已经确定了从起点到终点的路径，若有多笔资料同时发出传输请求，也要能够在传输前为这些请求合理的分配路径，以避免塞车的状况。而在处理突发的资料传输请求时，也要在可接受的延迟时间内，依据所有路径负载计算出较佳的传输路径。换言之，NOC的网络通讯架构要能够合理安排预期中的资料传输需求，也要能快速处理突发的资料传输请求。

NOC通讯架构的关键设计技术

为了尽量提高资料处理的速度，并且降低通讯中枢以及NOC之间的通讯延迟，以下几个方法是NOC设计的可参考方式：

■任务分配与调度：将通讯任务分配到合适的处理单元，并且尽可能以最佳的方式为这些任务进行排序，这个步骤是典型的多处理器系统的关键设计步骤。

■网络分配：在这部分包含了处理单元映射（Processing Element Mapping）以及路径分配（Routing Path Allocation），由于映射对于系统功耗有著决定性的影响，路径分配则是对于执行效能产生直接影响，因此芯片设计者必须对此谨慎评估。

■动态网络最佳化路径分配：对静态通讯迳行路径分配时，由于对即时性的要求并不高，因此只要对现有的最短路径算法稍做改变即可，但是对于NOC的动态通讯而言，这些算法主要是着重于普通网络环境之中的应用，直接套用并不适合。

根据应用选择合适网络拓朴架构


图说：不同的拓朴架构将会影响NOC的应用范围及效能表现。（资料来源：意法半导体）

NOC之中，网络架构扮演著决定性的关键角色，网络的设计与拓朴方式的选择就决定了一款NOC芯片的生死，在网络结构上，网络界面（NI）透过把子系统的交易转换成在芯片网络内传输资料封包的方式连接各个IP模块，NI还能使与网络相关的属性对传输层来说是不可见的，以提高IP的重覆使用率，能缩减MPSoC（多核SOC）的设计时间。路由器负责在NoC拓朴内高效可靠地传输资料封包。路由器实现网络层、数据链路层和实体层。实体链路负责路由器和／或网络界面之间的实际讯号传播。实体链路技术的选择，例如串行还是平行、同步还是非同步，这些问题需要在芯片区域内的时脉讯号分布、芯片上布线和所需的芯片面积之间做出均衡考虑。

NOC在拓朴方式的选择，深深影响的通讯架构的传输能力，除此之外，通常也会由增加高效能缓冲存储器、流量控管以及强化的路由机制等等。前面也提到过几个不同的拓朴架构，包括了蛛网状（Spidergon）、树状（FAT TREE）、环状（RING）、网状（MESH）以及柱状（TORUS）等等，而总和各种考量，为了要配合芯片架构复杂度与成本，芯片本身的处理特性与应用目标，在通讯架构方面，必须要斟酌拓朴的路径平均距离、可扩展大小、节点数量、顶点数量、网络直径等等。

由于NOC的拓朴架构选择对其产品的最终性价比有著决定性的关键影响，选择正确的拓朴架构，也能有效的缩短各种应用的设计以及验证时间。

结论

由于市场的需求，以封包交换网络架构的NOC在针对未来MPSOC的应用扮演著非常重要的角色在可预见的未来，目前SOC所采用的汇流排架构也将全面转换到NOC架构，并对嵌入式应用造成深远的影响。

随著NOC时代的即将到来，单一系统或芯片内整合的IP数量也将可望跟著水涨船高，从这方面来看，半导体IP分工也将越趋精细，而不再像目前单一IP即整合众多关键功能，因此拥有多样化IP的供应商将拥有更大的竞争优势，小型IP供应商也可从中得到更多机会，甚至转而成为半导体元件供应厂商，进而创造更大的获利。   多媒体应用处理器效能强化关键 (寄信给作者) 2008/10/16  
唐鸿／DIGITIMES

行动终端装置由于多媒体应用广泛，而且对质量的要求更甚以往，例如，2D显示提升为3D显示，而同时进行影音、通讯、导航…等任务，已是基本应用！从基频处理器外分出专用多媒体应用处理器，甚至还必须大规模强化多媒体应用处理器效能，应付日渐繁重的处理需求…


图说：行动终端装置应用愈来愈丰富，但系统能应用的资源却相对有限，如何让装置展现最佳多媒体呈现效果？处理器架构与效能绝对是重要关键！时下如PDA、PMP、PND…都需要极高运算效能支持，架构最佳化多媒体应用处理器与系统环境，已是这类行动装置实用价值的重要基础…

手机、数码电视、数码相机、个人导航装置(PND)、可携式播放机(PMP)…等，处理原本主要用途的元件，称为基频处理器(Baseband Processor)，不过在多媒体运用，特别是愈强调质量的影音播放用途，已超越基频处理器的处理能力，因此，多媒体应用处理器(Multimedia Application Processor)，成为行动装置中协同处理器一员。

换言之，多媒体应用处理器原本只是行动装置内众多处理器的1种，以手机为例，内部处理器根据IDC定义，有高阶多媒体应用处理器(High-End Multimedia Application Processor)、基频或整合式基频处理器(Integrated Baseband Processor)、操作系统应用处理器(OS Application Processor)、多媒体应用处理器(Multimedia Applications Processor)、多媒体协同处理器(Multimedia Co-processor)、相机影像协同处理器(Camera Coprocessor)、及LCD屏幕控制器(LCD Controller)…等7种。

上述众处理器中，现今多媒体应用无论质与量都与时俱进的市场趋势，多媒体应用处理器在许多原本并非职司此道的行动装置上，反成了重要元件！其设计与发展趋势足以影响行动装置整体表现。

高质量多媒体应用渐多　多媒体应用处理器强化效能

多媒体应用处理器发展迄今，第1个重要的设计方向，便是强化效能。作法分为2类，其一是在原本架构上，作更进一步加强、调校，直接的作法是提升时脉，并非线性提升，更重视每时脉所能带来的效率(如MIPS或DMIPS/MHz)，所以，微架构调整也相当重要。

多媒体应用处理器微架构强化方向相当多，举例而言，使用更高效率超纯量管线(Super-scale Pipeline)，让单一时脉能执行多重指令；强化浮点运算单元(FPU)，如加快单倍与双倍精准度纯量运算作业速度，并加入额外16位元浮点运算资料类型转换指令，增进与嵌入型3D处理器间资料交换速度；内建多媒体处理单元(Media Processor Engine)，支持SIMD运作模式，如每周期能处理8、16、32位元整数与32位元浮点运算资料，甚至支持混合资料类型，排除封装/解封装耗费的资源，及结构化加载/储存功能，让资料不必于演算格式与机械格式间来回转换。

在微架构外部方面，可强化与存储器间存取效率，如加大快取容量/频宽、降低迟延，解决L1/L2快取间的一致性问题，例如，设立1个侦测控制单元(Snoop Control Unit；SCU)然而，任何接触存储器中的关联区域存取，SCU都将进行监控，测试要求的信息是否已储存在处理器L1快取中，若信息已存于快取内，就直接传回发出要求元件，否则会利用最佳化算法，尽量使资料尽可能利用L2快取，藉此排除直接写入芯片外部存储器衍生的功耗，并提高整体效能。

单核发展面临瓶颈　多核心技术应战

单核心最佳化，面临多工处理时发生瓶颈，例如，1个行动终端可能同时进行视讯/音讯播放、导航定位、资料库查找、无线传输…等工作，效能再强大的单一多媒体应用处理器，往往也因此捉襟见肘，所以，多核心成最佳解决方案。不过此处必须说明，这里谈的并非基频/多媒体应用处理器封装在一起的异质多核心架构，而是多媒体应用处理器本身就采用同质多核心运作。

多核心架构带来效能提升，在软件支持环境下，利用新增指令让多核心处理器于程序执行时，动态从超纯量执行切换成执行多个并行执行绪，建立程序内执行多执行绪机制，仅双核心针对解码MPEG-2效能，就比单核心提高52％！不过，多核心真正的价值，除直接效能性提升外，更重要的是多核心处理器还能充分利用不同应用指令间的平行处理(Instruction-Level Parallelism；ILP)和执行绪阶层平行化(threading-Level Parallelism；TLP)，换言之，具较高ILP与TLP应用，对于多核心架构适应力较高，效能提升幅度也会更大。

至于采多核心的负面影响，则分为硬件与软件方面。硬件方面是在寸土寸金的行动终端装置，多了1组核心，就表示多1倍晶体管，但多数应用环境中，效能却并非等比提升1倍，但目前半导体技术进步，多核设计可有程度不等的晶体管共享(如L2快取或存储器逻辑控制电路共享…等)，降低多核芯片尺寸与功耗。

反而软件问题比较复杂，例如，多个执行绪甚至应用程序存取同1个存储器区块问题，如果，某1个程序没有针对多核心运作最佳化，可能就会让系统不稳定，因此，因应多核环境修正嵌入式软件与针对多核心最佳化，是目前推展多核心多媒体应用处理器颇大的阻碍。

不过，总体来看，就如同x86处理器在时脉发展遭遇高耗能与高热瓶颈后，即透过多核心抒解的发展轨迹，多媒体应用处理器采多核心抒解性能瓶颈，也是必然趋势，不过多核心对于芯片面积更为敏感，因此，半导体制程进展成为开发关键。此外，多核心架构的省电机制设计也相当重要，如果分配得宜，能比单核心更省电、且效能更高。


图说：多媒体应用处理器设计的首要目标，是弹性架构与效能强化，以适应各种装置需求。(Toshiba)


图说：多核心运作可强化处理器架构，也是多媒体应用处理器设计趋势，但软件支持度仍有待考验。(ARM)

  资料保全设计：RAID技术保障资料安全 (寄信给作者) 2008/10/13  
张玮容／DIGITIMES

由于集中保管多用户端的档案资料，NAS产品的可管理性相当高，但资料损毁的风险即直接集中到NAS上，档案本身或硬碟的损毁都会造成资料的遗失。而NAS提供不同层级的保护措施，目的是为了保障所储存资料的完好及安全，磁碟阵列(Redundant Array of Independent Disks；RAID)就是防止单磁碟的硬件失效，造成资料毁损的技术。

TS-509 Pro的RAID磁碟阵列管理功能，让资料分散记录在各颗硬碟上，使用者可逐步依页面设定完成设定，其中包括RAID 0/1/5/6/5 + Spare、Single及JBOD。RAID 0是将多硬碟结合一同运用，加大储存空间，并将空间予以等量切割(striping)、分散存取，因此可以加速存取效能，缺点是不具资料保护功能。

RAID 1是将2颗相同容量的硬碟进行镜射备份，可以在1颗硬碟损坏的情况下，继续维持资料完整性，缺点是必须占掉一半的储存空间。RAID 5结合RAID 0/1的优点，将资料分散到3颗以上的硬碟，可以在1颗硬碟毁损的情况下，藉由其它硬碟的同位元资料予以修复。而RAID 6在硬碟损毁2颗时，系统则变成read only的模式，待系统修复后再恢复正常运作模式。

TS-509 Pro支持「热抽换硬碟设计」、「在线容量扩充」(Online RAID Capacity Expansion)与「在线磁碟阵列等级迁移」(Online RAID Level Migration)功能，使用者可以在初期建置系统时依需求量购买硬碟，未来若使用需求扩增，再行购买新的硬碟扩充硬碟容量。

在线RAID组态迁移的功能，可让使用者在未来希望升级RAID等级时，能够在不停机、机器正常运作且保留资料的状态下进行RAID等级迁移。藉由RAID技术，soho族或小企业可依自身需求、预算逐步扩充硬碟容量，而热抽换、RAID在线容量扩充、RAID在线等级迁移的友善操作步骤，也让小企业拥有高弹性、高规格的资料中心成为可能。


图说：RAID在线扩充示意图，容量目前最多可扩充到5Gb。(QNAP)

   Symbian智能型手机操作系统　技术与软硬件设计概观 （林宗辉／Digitimes.com） 2007/01/02  
前言：Symbian是由Ericsson、Panasonic、NOKIA、Simens AG、Sony Ericsson等公司所共同开发并拥用的专为手机硬件而设计的操作系统，其包含了函式库(libraries）、用户界面（user interface）架构和共享工具（common tools）的参考实现（reference implementation），Symbian操作系统的前身是Psion的EPOC操作系统，当初仅设计为ARM架构处理器独占使用。

图说：Symbian的官方图标志。（资料来源：Symbian）

而Symbian在2004年7月股权变动后，Nokia的持股比例从32.2％上升到47.9％，维持其第一大股东的地位。为了力拱Symbian，Nokia也发动产业链上的内容开发商来说服手机厂商加强采用Series 60平台，除了联合各移动通信终端设备厂商共同支持Symbian操作系统外，还将该移动通信终端设备平台授权给Samsung、Siemens和 Panasonic，以统一各家移动通信终端设备平台来加强开放性以及降低软件开发成本。

Symbian的成立理念除了有加强开放性以及降低软件开发成本等考量以外，将微软这只软件巨兽给挡在行动应用门外是另外一个重点，由于几大行动电话业者早已看出微软对于行动市场也有著极大的兴趣，迟早会将手伸进来搅和，因此藉由成立Symbian，成为各大手机厂商的通用系统核心，应用程序也可以极大的比例互通，借以形成规模，造成进入门槛。只不过微软巨兽的称号可不是简单就能得到的，在推出Windows mobile行动操作系统家族之后，随著架构与性能的逐步改善，已经在行动装置逐渐闯出一片天，想要完全阻挡微软的入侵，似乎已经是一件不可能的事。

Symbian的设计特性

以Symbian操作系统为基础的智能型手机，在使用者界面上的设计则是以套件形式提供厂商多种不同的选择，比如说常见于Sony Ericsson手机的UIQ界面，Nokia手机的Series 60、Series 80、Series 90等，以及诸如封闭式平台如由Fujitsu、Mitsubishi、Sony Ericsson和Sharp合作开发应用于NTT DoCoMo所采用的FOMA（Freedom of Mobile Multimedia Access，世界上第一个WCDMA网络）等等。提供不同型态的手机操作方式（界面与输入方式），以及程度不等的扩展性。

而Symbian本身也是一款支持先占式多工、多执行绪，以及具备存储器保护功能的操作系统，由于最初是专为行动装置所设计，一般行动装置（如手机）等在硬件资源上都相当有限，无法如桌上平台操作系统般，对硬件需求可以无限制的膨胀。为了要尽可能在维持系统的可操作性以及稳定性的前提之下，延长采用Symbian操作系统的行动装置的使用时间，因此它在资源控管上就进行得非常严格，除了利用各种方式来降低存储器的需求以外，程序写作是采用事件驱动的方式，当存储器中没有应用程序发出事件处理需求，中央处理器将会被关闭，借以节省电源消耗。

在整个处理流程概念上，应用到了活动物件（Active Object）的方式，活动物件是一种多工处理的形式，其具备了协同式多工（cooperative multitasking）的特性，在架构上，当一个物件做了一个非同步服务的要求时（比如说系统要送出一个SMS讯息），当要求成立之后，操作系统就会辨别出该负责该服务执行绪内的活动物件，并且唤醒负责搭载该物件的执行绪，物件本身也将会被附加一个启动排程，并且将控制权交给该物件。

在实作上，一个执行绪内将会有许多的物件，每个物件都有其各自负担的行程，但是晤见之间并不是完全独立的，而是可以互相作用，当A物件的行程与B物件有相关时（比如说传送简讯与连接到网络服务的物件彼此就要互相作用），物件与物件、执行绪与执行绪之间都会有相互的请求，甚至执行绪本身也可以对该执行绪内的物件做处理请求动作。这个软件设计概念其实相当古老，早在70年代就已经被发展出来。利用这些处理规则，Symbian可以很有效率的处理所有的工作流程，并且延长电池使用时间。

虽说因为这些技术的缘故，在Symbian上设计应用程序的难度将会有所提升，但是基本上由于可采用的程序开发工具相当多，相关的官方资源与支持也相当完备，虽然基本上Symbian的原生开发语言是C++，一般来说是采用VC++、Visual Studio以及Carbide等，但是开发者也可以采用OPL、Python、Visual Basic、Simkin以及Perl等来搭配J2ME以及自行开发的JAVA来使用，具备有相当大的弹性空间。

Symbian操作系统结构

Symbian具备有一个微核心架构，在架构内定义了包含排程系统以及存储器管理机制，不过网络与档案系统则是外加在使用者端服务，没有包含在微核心架构之内。在基本层内，包含了档案服务，可在服务内提供类似DOS外观的档案系统（每个逻辑或实体磁碟装置都拥有各自的磁碟代号，利用反斜线来当作目录的定义系统）。Symbian支持多种不同的档案系统，通常这些档案系统被隐藏在最底层，而不会被显示出来。

Symbian具备了一个相当庞大的网络以及通讯子系统，包含了三种主要服务，这三个主要的服务，分别是ETEL（EPOC telephony）、ESOCK（EPOC协定）及C32（序列通讯回应机制）。这三种服务都有其Plun-in结构，举例来说，ESOCK可容许不同的「.PRT」协定模块，借以实作多种不同种类的网络协定架构。这些相关架构也包含了诸如蓝芽、红外线以及USB等短距离有线／无线通讯中。

在使用者界面上，也包含了大量的程序码，虽然使用者界面大多是，第三方厂商所维护但是所有使用者界面的基本类别与次系统都是被包含在Symbian架构之中，相关的绘图功能程序码也被包含在Symbian功能服务中，这些程序码功能包含了视窗服务、自行、点矩阵图形服务等等。

至于在应用程序结构方面，则是提供了不同的应用程序引擎，不同的应用程序都会分散到各种不同的动态连结函式库（DLL）引擎以及图形化程序中，当然，Symbian本身也提供了相当多现成的DLL给程序开发者使用。

Symbian操作系统的体系

从1998年Symbian正式出现以来，历经了十数次的改版，目前Symbian OS最新的版本为9.3版，但是提供给开发者的却不是这种单纯的OS层次程序码，转而代之的是以套件形式来推出的配套方案。目前类似的配套方案主流有Nokia公司的S60与Sony Ericsson的UIQ这两种。


图说：采用UIQ 3.0版的Sony Ericsson P990。（资料来源：Sony Ericsson）

Nokia为Symbian提供了4种方案，分别是S40平台、S60平台、S80平台以及CDMA方案。CDMA方案是给具备基本通话、简讯、通讯录管理功能手机使用，属于非常基本的类型，支持彩色屏幕，但是可扩充能力以及功能方面非常简化，是专门给最低阶产品开发应用。S40平台至专门提供用来设计具备基本功能的智能型手机系统，提供了标准的JAVE中界、FLASH应用等等，不过最高分辨率设定在320*240，因此定位于中高阶产品应用，在操作界面上做了相当程度的简化。S80则是着重于个人资料辅助处理功能上，在定位上，就与Windows CE类似，以全功能完整提供各种应用程序以及网络服务，以双手操作最佳化。在开发应用程序上可使用C++或者是JAVA等弹性方案。不过以上这三种方案主要都是应用于NOKIA的产品中，几乎没有第三方厂商采用。

而S60可以说是目前最主流的智能型手机操作系统，主要是以单手操作为其人机界面概念，除了NOKIA以外，也被诸如Panasonic、SAMSUNG、Motorola等厂商所采用，使用范围相当广，此平台除了包含了完整的事务辅助处理功能以外，更包含游戏、影音等热门功能，并支持了目前流行的移动通信网络以及Wi-fi无线网络等环境使用，在产品竞争方面，可以说是最高的，虽然对于硬件厂商来说竞争非常大，但是对于软件开发商来说，只要针对S60平台开发一套软件，即可应用于不同的厂牌智能型手机中，除了市场可大幅扩张以外，相对的开发成本也可有效降低，不需要针对每个平台来去做底层架构上的更动。消费者也不必担心买了特定厂牌的S60平台手机会有软件支持度不足的状况，毕竟这些智能型行动产品在核心架构上都是属于系出同门，只有硬件设计理念有所不同而已。


图说：采用S60第三版的Nokia N73。（资料来源：Nokia）

S60目前已经发展到3.1版（或称为S60 3rd Edition Feature Pack 1），是基于最新的Symbian OS 9.2的基础上，而不同版本之间因为支持分辨率以及使用者界面的不同，就有可能造成应用程序的不兼容，比如说第三版开始使用的Symbian OS 9.1，与过去S60 2.X版所采用的Symbian OS 8架构有著明显的不同，9.1版采用了新的ARM EABI 2进位执行档模型，在应用程序管理及安全性上有不小的变更，因此旧版针对Symbian OS 8环境所开发的软件就无法沿用到S60 第三版上，最新的S60 3.1版中，则是将Symbian OS版本推进到9.2版，这个版本是在2006年第一季释出，变动部分，主要是支持了蓝芽2.0、OMA装置管理等，不过在实际产品上，采用S60 3rd Edition Feature Pack 1的N95，已经应用了不少Symbian OS 9.3的特色，包含HSDPA、802.11协定以及更多语言的支持等等。



图说：采用S60 3.1版的Nokia N95。（资料来源：Nokia）


图说：采用S60 3.1版的SAMSUNG SGH-i520。（资料来源：SMASUNG）

Symbian应用软件的开发

上一段文章有提到，基于Symbian的应用平台有5种以上，这些平台提供了不同的开发套件供开发人员使用，其中最主要的就是UIQ以及S60这两种。个别手机厂商或者是同家族系列通常都会在网络提供可下载的开发套件以及软件开发环境。Symbian的C++语言程序设计，都是在Commercial IDE之下完成，比较常见的开发套件就属于微软的Visual Studio，CodeWarrior的Symbian版本也常被应用来开发专属应用程序，至于2006年时，Nokia则是使用Carbride.C++来取代CodeWarrior。

Carbride.C++是基于Eclipse IDE 3.1环境以及支持Symbian特定功能的Eclipse CDT 3.0.2延伸套件的整合开发工具，基本上Carbride.C++使用与CodeWarrior相同的编译器，Carbride.C++也被分支为CDT的少数几个部分，但几乎都被包含在Eclipse附加套件上。在架构上，Carbride.C++与标准Eclipse安装非常类似，它可以被应用在其它种类的语言发展上，比如说JAVA与Perl等（必须利用Eclipse的自我升级功能来安装正确的附加套件）。由于Carbride.C++使用了Eclipse的组建管理系统（Eclipse‘s Managed Build System）来建立Symbian的可执行档，相较起标准Symbian开发工具，Carbride.C++在建立执行档的能力方面要来的更为优秀许多，不过这个开发工具倒也不是都毫无缺点，首先，它就无法完全反映出标准Symbian OS开发工具的任何功能上的加强或改变，其次，使用Carbride.C++必须具备更高深的程序写作技巧，以及Symbian的底层结构和使用者界面的了解也必须更透彻。而在程序编译过程，Carbride.C++所提供的编译工具也有可能会隐含瑕疵，导致编译出来的程序有不正常动作的情形。

此外，Borland IDE也有专为Symbian设计的版本；在Linux与MAC OS X环境下也有社群技术支持的开发工具使用，部分Symbian允许公开关键工具的原始码。

Symbian系统的程序设计技巧

最重要的一点，就是将核心程序码与使用者界面部分的程序码分开，分成不同的模块这么一来可以有助于应用程序在不同使用者界面系统之间的移植动作更为顺利。方法之一就是将所有与界面控制非相关部分都放到独立的核心DLL之中，使用者界面则是直接对核心DLL做出连结，藉由存取该DLL而达到功能上的应用。

另一个方法便是再原始码的阶段就做出区分，整个应用程序包括核心引擎与使用者界面可以包一包编译为单一档案，但是在原始码部分的撰写与存放就要放置到不同的.CPP与.H档案中，以便于管理及测试。采用这种设计方式，在移植往新界面时，负担也可以有效减轻，为了适应新的界面，只要变更控制使用者界面的原始码即可，核心部分的变动可以缩小到最低程度。

本地端语言的支持要利用Symbian OS本身的控制方式来提供，而不能将本地语言写死到程序码中，除非市场仅只着眼于本地，不然为了将来国际化版本的开发以及国别转换，将界面语言写死到程序码中，会造成将来改版上的困扰。

尽量使用Symbian所提供的官方SDK中的API来开发应用程序，避免使用第三方厂商或自行开发的API，以避免将来操作系统改版或SDK版本变更之后，应用程序大幅经过改写才能获得操作系统支持的情况。

不同的硬件架构对于资源的管理方式都有可能不同，因此要尽量考虑到不同硬件对其系统资源的分配方式，而不要所有在程序开发过程中所需要的硬件或软件功能都能在硬件中获取，而特定硬件资源的取用代号也可能会因硬件而异，因此采用相对位址，而不是绝对位址，可以避免在不同硬件上执行程序的不兼容情形。

存储器管理是Symbian程序设计的最重要部分

由于Symbian OS本身就是针对存储器与运算资源都颇为受限的硬件来开发，应用程序可能在各种情况之下碰到存储器耗尽，或者是硬件资源被其它应用程序占用的情况，这些例外情况无法透过修改程序码来获得改进，因此必须遵守几个规则：

■ 不要占用不必的存储器空间。
■ 当程序执行完毕，必须记得将所使用到的资源释放出来。
■ 在程序对操作系统本身申请存储器占用时，都必须准备好面对存储器不足的情况。
■ 当存储器不足的情况出现时，就必须将应用程序回归到原始状态，并且将原本占用到的资源回吐出来。

此外，在程序码中，尽可能使用SDK中所推荐的存储器控制指令以及流程，避免造成应用程序的错误。为了避免应用程序有存储器泄漏的状况时，却无法即时做出反应，导致应用程序崩溃，可以利用一些小技巧，将特定检查码放在程序码的开头与结尾，借以找出会导致存储器泄漏的部分程序码。

Symbian OS中的执行绪管理与工作进程管理

在Symbian OS中，每个工作进程都包含了一个或多个执行绪，执行绪是程序执行的基本单位，由于Symbian OS中是属于先占式多工设计，这也意味著，每个执行绪都有自己的执行时间，除非系统将CPU使用权转移到其它执行绪中。当系统调度时，执行绪的定址空间是受到保护的，因此每个使用者端执行绪都有自己的专属空间与时间，可避免互相受到干扰。每个执行绪都有各自的stack以及heap，heap可以是私有的，也可以被其它执行绪所共享。虽然Symbian OS支持多执行绪执行，但基本上还是为单执行绪工作处理做最佳化，因此在应用程序开发上，大多推荐以Active Object（类似协同式多工的一种处理方式）来代替多执行绪的执行方式。

在Symbian OS中使用单执行绪有几个考量，主要是由于每个执行绪都有各自的stack耗用，使用单执行绪可以减少存储器耗用，而在执行绪之间切换，要比使用Active schduler来进行Active Object切换来得慢，而单执行绪也不需要处理不同执行绪之间的户斥状况，因此也可以简化程序码的设计，减少错误的发生。

不过在特定的情况之下，使用多执行绪还是有其优点的，比如说，当要为了保证所执行任务的持续性时，比如说播放音乐，不想让音乐工作被其它简讯活动等干扰而中断，因此就可以将之独立为一个执行绪来处理。而特定应用程序中，也有因为原先设计就比较适合使用多执行序架构，比如说电子游戏，单执行绪处理可能会导致音效或动画显示不同步。

不过在启动执行绪之后，执行绪的stack就不能再增加，否则可能会导致该执行绪崩溃，这是在程序设计时，所必须要注意的一点。

结论

Symbian OS具备了极高质量的设计特性，其应用的广泛度，也被层出不穷的新产品所证明，除了高阶硬件以外，中低阶硬件也可以无痛的导入。由于行动装置逐渐走向低成本与高性能走向，备有不同平台开发方案的Symbain可以很好的适应这些不同的应用需求，在架构上，也要比竞争对手更容易发挥出硬件的效能。目前市场现况来说，采用Symbian的行动装置已经突破一亿台，而发展中国家如印度、中国大陆以及巴西等都是人口密集的大国，将来出货量更有水涨船高的可能，IDC预估，到2011年，全球行动装置出货量可能高达10亿部以上，不论是针对开发中国家的低阶硬件产品或是为年轻用户准备的高阶全功能产品，都是产业界所不能忽视的市场机会。  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 1Mark 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 CountingWindows 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 ServiceUsers 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 UsageYou can see the inaccuracy of the Windows standard clock-based time accounting using the Process 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 LinksThe 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 BoostingYou 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 CancellationThere 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 PriorityWhile 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 UpNow 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 2Mark 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 SpaceWindows 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 PrioritiesJust 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.
SuperFetchA 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 SuperFetchAfter 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)

ReadyBoostThe 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.
ReadyBootWindows 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)
ReadyDriveReadyDrive 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 DatabaseWindows 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 ProcessesIn 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 RelationshipsYou 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 ProvidersEven 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 ServicesIf 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.
ShutdownA 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 ManagementSleep 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 UpAs 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 ServiceThe 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 3Mark 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 finalinstallment, 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 ManagerOne 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 SupportWhen 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 the Microsoft 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 CopyWindows 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.
BitLockerWindows 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 VerificationMalware 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 ProcessesNext-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 ProcessThere 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 RandomizationDespite 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 ImprovementsWindows 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 ActionYou can easily see the effects of ASLR by comparing the DLL load addresses for a process in two different boot sessions using a tool like Process 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.
ConclusionThis 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 ServiceOnly 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.