CN101297280A

CN101297280A - 隔离扩展和设备驱动程序的配置

Info

Publication number: CN101297280A
Application number: CN200680040116.1A
Authority: CN
Inventors: G·C·亨特; J·R·劳瑞斯; M·A·范德瑞; O·霍德森; S·P·莱维; B·斯汀斯嘉德; D·R·泰迪蒂; M·斯帕尔斯; M·卡宾; M·阿巴迪; M·埃肯; P·巴罕姆; T·沃伯; B·齐尔; C·霍伯利特泽; N·墨菲
Original assignee: Microsoft Corp
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2005-10-26
Filing date: 2006-10-16
Publication date: 2008-10-29
Anticipated expiration: 2026-10-16
Also published as: CN101297277A; CN101297280B; CN101297277B

Abstract

本文中描述的是用于描述和/或解决软件系统的应用程序、扩展、设备驱动程序(300)和其它组件的配置要求的一个或多个实现。

Description

隔离扩展和设备驱动程序的配置

背景

诸如操作系统的软件系统一般伴随有用于执行各种任务的软件模块的预定义集合。这些模块彼此相关联，因为它们均是同一预定义集合的一部分。

然而，通常需要附加的功能和/或定制。换言之，功能被“扩展”。一般，软件系统通过允许动态添加新软件模块或进程来允许扩展。这些添加通常被称为“扩展”或“插件”。常规系统中扩展或插件的常见示例包括但不限于：操作系统的设备驱动程序、数据库中扩展的存储过程、web浏览器中的插件和ActiveX^TM控件、web服务器中的ISAPI内容和过滤器扩展、用户交互外壳的外壳扩展等。由扩展添加的功能范围遍及硬件驱动程序的更新版本的简单支持到对电子邮件客户端中工作流工具的病毒扫描器。然而，用于集成扩展的常规方法是有问题的。

例如，常规操作系统(“OS”)通过将一组可执行指令加载到内核保护域中来加载扩展。一旦驱动程序被安装到该地址空间中时，常规内核不能阻止所加载的扩展访问计算系统中的任何(或所有)硬件。因此，恶意制作或恶意的扩展可能会在OS内核中造成破坏。

设备驱动程序是在操作系统中找到的一类扩展。设备驱动程序是将操作系统扩展成访问特定的一个或一类设备的软件模块。例如，IDE驱动程序允许操作系统访问附连于IDE存储控制器的磁盘驱动程序。设备驱动程序执行重要功能，从诸如特定厂商的存储控制器等与特定硬件对话的机械提取操作系统或应用程序所理解的常见功能，诸如读写磁盘存储块。尽管设备驱动程序通常访问物理设备，但本领域的技术人员可以认识到，设备驱动程序也可提供对虚拟资源的访问，或可分层以添加附加的功能——诸如位于存储控制器的设备驱动程序上方的压缩驱动程序。

设备驱动程序的复杂程度在最近的十年来显著增长，因为用户开始期望诸如热交换和电源管理等丰富的特征。众多常规操作系统以各种方式响应，但就其核心而言，这些系统拥有与它们在十年前拥有的相同的驱动程序模型。

与扩展一样，常规操作系统(“OS”)通过将可执行指令加载到内核保护域中来加载设备驱动程序。一旦驱动程序被安装到该地址空间中，常规内核就不能阻止所加载的驱动程序访问计算系统中的任何(或所有)硬件。

而且，由于这些驱动程序一般用低级原语编写以直接访问硬件，常规内核很少验证驱动程序仅使用适当的硬件资源。相反，常规内核信任驱动程序将仅访问它声称服务的设备的硬件。而且，通常常规内核不能保证驱动程序被正确配置、驱动程序将与被分配给活动进程的存储器或甚至与被分配给常规内核内其它组件的存储器相关。

因此，常规驱动程序是OS中的最不可靠的组件之一。某些报告指出，在最流行的常规OS中85％所诊断出的崩溃是因驱动程序而引起的。其它报告指出，较不流行的常规OS的驱动程序与内核中的其它可执行指令相比，包含隐错的可能性高七倍。

概述

本文中描述了用于描述和/或解决软件系统的应用程序、扩展、设备驱动程序和其它组件的配置要求的一个或多个实现。

提供该概述是为了以简化的形式介绍将在以下在详细描述中进一步描述的一些概念。该概述不旨在标识所要求保护的主题的关键特征或本质特征，也不旨在用于帮助确定所要求保护的主题的范围。

附图简述

贯穿附图，使用相同的标号来指示同样的元素和特征。

图1是支持本文中描述的一个或多个实现的操作系统体系结构的操作场景。

图2是支持本文中描述的一个或多个实现的操作系统体系结构的框图。

图3是设备驱动程序进程内的对象及其与图2中所示的操作系统体系结构的其它部分的关系的框图。

图4是本文中所述的另一方法实现的流程图。

详细描述

以下描述示出了用于描述和/或解决软件系统的应用程序、扩展、设备驱动程序和其它组件的配置要求的技术。

常规扩展(例如，设备驱动程序)包括用于对计算资源——诸如输入/输出(I/O)、存储器、视频、声音、中断请求(IRQ)线或其它硬件——的直接访问的可执行指令。与常规扩展不同，根据本文中描述的一个或多个实现创建的扩展(例如，设备驱动程序)经由一个或多个局部访问对象来访问计算资源，这些对象是提供至计算资源的通路或桥梁的对象(即，具有一个或多个数据结构的可执行指令)。

采用一个或多个所述实现，扩展包含指定其配置要求(包括其对这些资源的需求在内)的嵌入元数据。操作系统(OS)基于这些元数据确定扩展的计算资源需求。OS提供必需的可执行指令(按局部访问对象的形式)来分配所需资源并将扩展连接至其进程外的计算资源。

这种新的工作划分向扩展的主机(一个或多个实施例中针对设备驱动程序的的OS)提供了验证所有配置要求并控制扩展对I/O或IPC资源的所有访问的能力。

软件隔离进程

在计算机科学领域，更具体地在操作系统领域，术语“软件进程”(或简称为“进程”)是公知的。应用程序通常由一个或多个进程组成。操作系统(OS)意识到并实际上可管理和监督运行在计算机上的一个或多个单独的进程。

此处，进程包含可执行指令。程序模块也包含可执行指令。一个或多个进程可基于程序模块执行。

此处，扩展可被描述为程序模块。而且，设备驱动程序是扩展的一个示例。此处所述的一个或多个实施例可经由隔离进程实现。在图1的上下文中描述了隔离进程的上下文。

此处描述了在允许和/或支持软件隔离进程(SIP)抽象模型的配置的OS模型中操作一个或多个实现。SIP封装程序或系统，并提供信息隐藏、故障隔离和强接口。根据所述实现，SIP在OS和应用程序软件中贯穿使用。

图1示出了SIP构造的操作场景。它将进程构造体系结构100示为在计算机120上存储和/或执行的操作系统100的一部分。如图1所示，进程构造体系结构100可以是操作系统的一部分。或者，进程构造体系结构100的全部或部分可与操作系统分开，但仍与操作系统协同工作。

进程构造体系结构100在计算机的工作存储器中根据由扩展组件集编辑的组成组件动态集构造进程。一旦经构造之后，活动进程的可执行指令就是固定的。一旦被固定，活动进程就不常运行新的处理器可执行指令。为了这样做，进程一般用作为其一部分的新可执行指令重新构造，或创建新添的进程。

组成和扩展组件的动态集一般被表现为存储在计算机存储中的加载模块集。进程构造体系结构100按照允许关于要执行进程的一个或多个各种属性(例如，完整性、安全性、可靠性、可用性、资源使用分析、完整性分析和/或稳定性)并为要执行的各种期望优化来分析的方式构造进程。

计算机120包括计算机存储设备122(例如，硬盘驱动程序、RAID系统等)，它存储一组加载模块124和工作存储器130。在图1的示例中，进程构造体系结构100构造存储在工作存储器130中的进程140。如此处所述地，进程140是根据加载模块124构造的，加载模块124是由进程的扩展组件编辑的进程的组成组件的表现。

进程140具有进程清单142，它定义了进程140的最终内容。这些最终内容的一部分包括由进程的扩展组件编辑的进程的组成组件。如此所述，进程清单142与其描述组成的进程(诸如进程140)直接相关联。

在构造进程时，进程构造体系结构100可采用以下功能组件中的一个或多个：进程清单合成器150、键入码表示创建器152、键入码表示更新器154、优化器156、键入码表示转换器158、进程间干扰消除器160以及固定身份创建器162。尽管图1将这些功能组件示为彼此分开，但这些功能组件中的一个或多个的功能可被组合。

“Inter-Process Communications Employing Bi-directional Message Conduits(采用双向消息管道的进程间通信)”申请公开了支持可在SIP(以及OS)之中使用的进程间通信的OS模型的各组件。

采用SIP，内核外的所有可执行指令在一SIP中执行，并通过强类型的通信通道与其它SIP通信。SIP是封闭的环境，它不允许数据共享或动态代码加载。SIP在众多方面不同于常规OS进程。

新内核(支持此处所述的实现，并由操作系统210表示)几乎全部由安全可执行指令和系统的其余部分组成，它在SIP中执行，由可验证的安全可执行指令组成，包括设备驱动程序、系统进程和应用程序。尽管所有不受信任的可执行指令必须是可验证安全的，但新内核和运行时系统中被称为可信库的部分却不是可验证安全的。语言安全保护该可信库免于不受信任的可执行指令的破坏。而且，每一SIP的完整性依赖于指令安全以及进程不会保持对另一进程的对象空间的引用的系统范围不变性。

进程间通信

在至少一个所述实现中，SIP通过在通道上发送消息来排他地通信。通道是两个进程之间双向、行为类型的连接。消息是交换堆中从发送进程传输到接收进程的值或消息块的带标签集合。通道由契约定类型，契约指定消息的格式和沿通道的有效消息序列。

SIP通过调用契约的静态NewChannel(新建通道)方法来创建通道，该方法在其输出参数中返回通道的两个端点——不对称地被定为导出方和导入方类型。

SIP可通过现有的通道将端点中任一个或两个端点传递给其它进程。接收端点的进程具有至保存另一相应端点的进程的通道。例如，如果应用程序进程想要与系统服务通信，则应用程序创建两个端点并向系统名服务器发送包含一个端点的请求，该服务器将端点转发给服务，从而建立进程与服务之间的通道。

通道上的发送是异步的。接收同步阻塞，直到特定的消息到达。使用语言特征，线程可等待沿通道的一组消息中的第一个，或可等待来自不同通道的特定的一组消息。当在通道上发送数据时，所有权从可能不会保留对消息的引用的发送进程传递给接收进程。该所有权不变性由语言和运行时系统实施，并服务于三个目的。第一是为防止进程之间的共享。第二是通过消除消息的指针混叠来便于静态程序分析。第三是通过提供可由复制或指针传递来实现的消息传递语义来允许实现的灵活性。

隔离可扩展性

软件创建者很少能预见其系统或应用程序的用户所要求的全部功能。代替尝试以单一系统满足每个人，最不平凡的软件提供通过加载附加的可执行指令来扩充其功能的机制。例如，某些常规的市面上可购买的个人计算机操作系统支持超过100,000个第三方设备驱动程序，这使得OS能够控制几乎任何硬件设备。类似地，无数的因特网浏览器附件和扩展扩充了用于网页的浏览器界面和组件。甚至开放源项目提供“插件”机制，尽管这些项目潜在可修改，这是因为扩展与新软件版本相比更易于开发和分发。

扩展通常由被动态加载至扩展的父亲的地址空间内的可执行指令组成。采用对父亲的内部接口和数据结构的直接访问，扩展可提供丰富的功能。然而，这种灵活性是有大代价的。扩展是软件可靠性、安全性和后向兼容性问题的主要原因。尽管扩展可执行指令通常是不受信任、未经验证、有缺陷或甚至是恶意的，但它们在没有任何硬件接口、边界或主机与扩展之间的区分的情况下被直接加载到程序的地址空间中。

扩展通常是不可兼容性、不良功能或其它错误的源头。而且，因为扩展缺乏硬件接口，它可能变得依赖于其父亲实现的细节，这限制了程序的将来版本的发展，并要求大量的测试来避免不可兼容性。

可执行指令的动态加载对性能和正确性造成其次的较不明显的负担。可动态加载可执行指令的系统是其中难以或不可能对系统的状态、不变性或有效转换作出可靠假设的开放环境。考虑Java^TM虚拟机(JVM)，其中在任何时候，中断、异常或线程切换可执行加载新文件、覆盖类和方法体以及修改全局状态的指令。一般而言，除了在环境不会在两个可执行指令之间任意改变的不可靠假设下以外，不存在分析在这样的环境中运行的程序的可行方法。

由本文中所述的一个或多个实现采用的新方法是禁止可执行指令的动态加载并将动态创建的扩展隔离在其自己的环境中。遵循这些原则的以往的尝试未被广泛使用，因为隔离机制具有性能和可编程性问题，这使得它们与在没有隔离的情况下运行的风险相比较不吸引人。

最普遍的隔离机制是传统的OS进程，但其高昂的成本限制了它的可用性。现代处理器上的存储器管理硬件向进程提供硬件边界并保护处理器状态，但它对进程间控制和数据传输强加了高昂的惩罚。在现代x86处理器上，进程之间的切换可能会花费数百到数千个循环，不包括TLB和高速缓存重新填充未命中。

为可扩展性设计了更新的系统，诸如Java^TM虚拟机(JVM)和Microsoft

通用语言运行时(CLR)，它们因此使用语言安全而非硬件作为隔离运行在同一地址空间中的计算的机制。然而，安全语言本身可能是隔离的不充分保证。共享数据提供计算的对象空间之间的路径，在此点上反射API提供破坏数据抽象和信息隐藏的机制。因此，这些系统需要复杂的安全机制和策略，诸如JVM精细粒度访问控制或CLR的代码访问安全来控制对系统机制和接口的访问。

此外，共享运行时系统并在同一进程内执行的计算在发生故障时不被隔离。当运行在JVM中的计算发生故障时，整个JVM进程一般被重新启动，因为难以隔离和丢弃被破坏的数据并找到没有错误的一点来重启发生故障的计算。

本文中所述的至少一个实现采用SIP来将系统组件的可执行指令封装在封闭环境中。对系统或应用程序的扩展在新的SIP中运行，并通过提供有限且适当功能的通道与父亲通信。如果扩展发生故障，则其SIP终止，这允许OS回收资源并通知通信伙伴。由于这些伙伴未与扩展共享状态，因此错误恢复是局部的，且通过通道的明确协议来促进。

本文中所述的一个或多个实现提供编译时反射(CTR)，它提供当编译文件来生成新的可执行指令时执行的功能。在运行时执行的正常反射具有对运行时值的访问权，且比CTR更普遍。然而，在众多情况中，所需的新可执行指令在执行之前已知。在这些情况中，CTR在编译期间产生新的可执行指令。

支持隔离设备驱动程序的配置的计算机体系结构

某些常规设备驱动程序在没有将驱动程序的可执行指令与内核的可执行指令隔离的机制的情况下被加载到内核的地址空间以及硬件的保护域中。然而，一个或多个所述实现描述了支持隔离设备驱动程序的操作系统。

图2描述了支持隔离扩展和设备驱动程序的配置以及本文中所述的一个或多个实现的示例性操作系统(OS)体系结构200。如所述的，示例性OS体系结构200示出内核210、一个或多个设备驱动程序220、一个或多个文件系统230以及一个或多个应用程序240。本领域的技术人员可以认识到，OS可包括在SIP中运行的其它OS服务，如文件系统330。

内核210是控制对硬件资源的访问、分配和回收存储器、创建和调度线程、提供进程内线程同步和管理I/O的特权系统组件。

内核210提供OS的核心功能。这例如包括管理存储器和其它硬件资源、进程创建和终止、进程间通信、通道操作、调度和I/O。该内核210的一些组件包括IO管理器211、调度器212、页管理器213、设备驱动程序协调器214和硬件抽象层(HAL)215。

该示例性OS体系结构200中的可执行指令或者经验证或者可信。由编译器检查经验证指令的类型安全和存储器安全。不可验证的指令必须为OS所信任，且被限于HAL 215、内核210以及可信运行时324、334和344中的部分。内核的大部分是可验证安全的。

内核和可信运行时外的所有可执行指令用安全语言，诸如C#或Java编写，翻译成安全中间语言(诸如Microsoft

中间语言(MSIL))，然后由一个或多个其它后端编译器编译成处理器可执行指令。

可信运行时系统模糊了内核指令与SIP指令之间的分界线。可信运行时包含可信但不可验证的可执行指令。保护运行时可执行指令以免受SIP指令的影响，因为SIP指令的经验证类型安全阻止它们除通过安全接口以外与运行时系统及其数据结构交互。在众多情况中，后端编译器可安全地将来自可信运行时的指令内联到SIP的其它可执行指令中，从而将传统上在内核中运行的操作安全地移入用户进程中。

设备驱动程序220的可执行指令包括由设备驱动程序的编程员编写的指令加上来自一个或多个类库222及其可信运行时224的可执行指令。类似地，如所述的，文件系统230包括来自类库232及其可信运行时234的可执行指令。而且，如所述的，应用程序240包括来自类库242及其可信运行时244的可执行指令。

图3描绘了与示例性设备驱动程序进程300内的配置有关的对象，及其与本文中所述的一个或多个实现所支持的示例性操作系统(OS)体系结构200的其它部分的关系。如所述的，示例性OS体系结构200示出了OS内核210、示例性设备驱动程序进程300以及硬件和其它计算资源350。

OS内核310包括启用进程间消息传递的一个或多个通道312。如所述的，硬件和其它计算资源350包括I/O端口352(也被称为I/O寄存器)、I/O存储器354、DMA控制器356和中断请求(IRQ)线358。当然，这些仅是一些硬件和其它计算资源的示例。其它实现可包括其它常见和不常见的硬件，以及其它计算资源。实现也可包括一个以上的I/O端口352、I/O存储器354、DMA控制器356或中断请求线358。某些实现可能不全包括这些类型的硬件资源。

示例性设备驱动程序进程300包含实现设备驱动程序的功能的对象，即设备驱动程序对象326。设备驱动程序进程300也包含可信运行时224、零个或多个类库222和配置对象328。

设备驱动程序对象326是可信程序模块的一个示例。与常规方法不同，未给予设备驱动程序的可执行代码自由的支配。然而，其动作也不能被监督或检查。相反，采用本文中所述的一个或多个实现，给予不可信设备驱动程序对计算资源的有限集合的自由但间接的访问权。

可信运行时224包括居中调停对硬件和IPC资源的访问权的访问对象。这些访问对象包括(作为示例而非限制)IoPort 332、IoMemory 334、IoDma 336、IoIrq 338和端点340。可信运行时224中的访问对象用作用于以下资源的通路：

·oPort 332→I/O端口352；

·IoMemory 334→存储器354；

·IoDma 336→DMA通道356；

·IoIrq 338→IRQ线358；

·端点340→通道处理器312。

与常规设备驱动程序不同，包含设备驱动程序对象326的可执行指令的文件不包括配置设备驱动程序或直接访问诸如350处所示的硬件和其它计算资源的可执行指令。相反，设备驱动程序对象326中的可执行指令仅经由访问对象332、334、336、338和340访问硬件和其它计算资源，这些访问对象的可执行指令被包含在可信运行时224内。

创建配置对象328以及访问对象332、334、336、338和340的可执行指令未被包括在由设备驱动程序程序员提供的文件中。相反，设备驱动程序程序员嵌入配置需求作为附连于设备驱动程序的可执行指令的元数据。采用一个或多个所述实现，用于创建配置对象328和访问对象332、334、336、338和340的可执行指令是分开的，并与其余的设备驱动程序对象的可执行指令分开设置。

在一个或多个实现中，创建配置对象328的可执行指令由操作系统提供。在一个实现中，这些可执行指令在安装时使用编译时反射(CTR)模板生成。CTR模板处理作为元数据嵌入在设备驱动程序中所编码的配置对象的描述内的配置要求。在另一实现中，CTR模板处理清单，其部分是根据包含设备驱动程序对象326的可执行指令的文件中的配置元数据创建的。在另一实现中，可信运行时224中的可执行指令通过解释配置元数据或设备驱动程序清单来创建配置对象。

示例性OS体系结构200在单独的软件隔离进程(SIP)中运行每一设备驱动程序(诸如驱动程序220)。示例性OS体系结构200使用语言安全来验证没有SIP能够写另一SIP的页。封装在SIP中，各个驱动程序可被按需停止和重新启动，而无需减慢整个操作系统。

示例性OS体系结构200的程序在安装时被静态链接至可信运行时。尽管针对类型安全而静态验证了程序，但每一可信运行时是其系统的可信计算库(TCB)的组件。可信运行时中的可执行指令保持进程隔离，从而允许进程在主机处理器的特权/管理员模式中运行，而不能够影响其它进程的存储器和硬件资源。在一个所述实现中，在由设备驱动程序编程员提供的可执行指令中不允许可规避类型安全的动态反射或其它机制。

设备驱动程序的可信运行时提供了抽象与硬件的通信的安全环境。通过由驱动程序运行时展示的访问对象保护用于处理中断请求、访问固定存储器、访问I/O端口(也被称为I/O寄存器)以及控制直接存储器访问控制器(DMA)的处理器可执行指令。

所有的进程间通信(IPC)是通过强类型的双向通道的。这些通道具有正好两个端点。通道上的消息受限于值类型，且这些消息的格式由契约定义。契约也用作指定通道上发送的消息的有效序列的通道协议，且包括发起通信的信号交换步骤。应用程序遵循契约与否可被静态验证。

某些端点具有公共名以便允许客户机容易连接。这是通过单根、全局可访问名空间来达成的。全局名空间服务器管理名空间，并允许名字到通道端点、目录和符号链接的映射。名空间不附连于持久后备存储。相反，系统策略允许某些应用程序(诸如文件系统)创建名空间内的虚拟子树，并将内容映射到这些树中。这允许传统文件系统的等效实现，区别在于文件访问是通过通道抽象进行的。

示例性OS体系结构200具有用于将应用程序(诸如240)作为第一类实体对待的抽象，这允许操作系统推出应用程序并提供保证。设备驱动程序是该抽象的子类。而且，设备驱动程序安装是由OS对应用程序执行的第一类操作。

在示例性OS体系结构200中，设备驱动程序声明其I/O和IPC配置要求。在常规方法中，配置要求是不可发现的。此处，配置要求被编码在设备驱动程序的可执行指令的同一文件中。所编码的配置要求可例如为更易于处理起见而被转换成声明配置要求的独立的规范。

配置要求在编译时、安装时、引导时和执行时可验证。实际上，将配置要求编码到设备驱动程序的同一文件中将其转变成自描述产物。给定设备驱动程序的MSIL程序集，OS可完全推出必须满足以便设备驱动程序能正确运作的配置前提(以及对软件和硬件资源两者的依赖性)。

采用应用程序抽象和驱动程序配置声明，示例性OS体系结构200可提供关于由设备驱动程序使用的I/O和IPC资源的保证。例如，OS可通过将新设备驱动程序所需的资源集与所有其它设备驱动程序使用的资源集进行比较并检查诸如I/O端口或I/O存储器的范围的资源重叠(从而是冲突)，来在驱动程序执行之前检测配置冲突。在优选实施例中，在安装时检测配置冲突，且仅在新设备驱动程序与包括所有之前安装的设备驱动程序在内的系统的其余部分之间不存在冲突时才允许安装。

作为另一示例，OS可通过从每一设备驱动程序中提取其配置依赖性，然后对列表排序使得没有设备驱动程序在其依赖对象之一之前初始化来创建有效的总引导次序——初始化设备驱动器的次序。有效总系统引导次序的自动创建是优于以往系统的显著的进步，在以往的系统中，或者引导次序是在开发时硬编码到OS中或者引导次序是由管理员手动更新的。作为从声明性配置要求得到的保证的最后一个示例，OS能够生成与驱动程序的配置和资源的获取相关的驱动程序初始化的所有可执行指令。因此，OS可保证，驱动程序仅使用所声明的资源，且资源是在遵循系统策略的情况下获取的。这些能力增加了系统的可靠性和可维护性，而在运行时性能上没有显著代价。

设备驱动程序协调

与常规方法不同，本文中所述的一个或多个实现的设备驱动程序协调器214阻止驱动程序访问不适当的存储器位置或其它硬件资源。相反，设备驱动程序协调器仅允许驱动程序访问适当的存储器位置和其它硬件资源。而且，代替驱动程序直接访问硬件和资源(这是常规方法允许的)，内核210审查驱动程序对硬件和资源的访问。

本文中所述的一个或多个实现具有由三个层组成的输入/输出(I/O)系统：HAL 214、I/O管理器211和驱动程序220。HAL 214是抽象对计算机硬件的访问的可信可执行指令的小型库。例如，在一个实施例中，HAL实现用于操纵硬件的四个访问对象：用于访问I/O端口352(也被称为I/O寄存器)的IoPort对象332、用于访问I/O存储器354的IoMemory对象334、用于访问DMA控制器356的IoDma对象336、用于访问中断请求线358的IoIrq对象338。在一个实施例中，HAL 314也包括控制定时器、中断控制器和实时时钟硬件的可执行指令。I/O管理器211负责初始化设备驱动程序并将应用程序连接至设备驱动程序220。

内核210或者直接使用设备驱动程序220配置元数据，或者使用每一设备驱动程序的清单(例如图1中所示的进程清单142)来正确配置设备驱动程序220并连接执行所需的资源。一旦启动之后，内核210就对系统进行即插即用配置。内核210使用引导加载器从BIOS中获取的信息以及来自诸如PCI总线等总线的信息来枚举设备、启动适当的设备驱动程序、以及传递封装对设备硬件的访问的这些驱动程序对象。

每一驱动程序220用安全可执行指令编写，且在其自己的进程中运行。驱动程序排他地通过通道与系统的其它部分通信，包括网络堆栈和文件系统。当驱动程序启动时，I/O管理器211提供如由设备驱动程序220的清单所需的I/O访问对象332、334、336和338以便与设备硬件352、354、356和358通信。所有这些访问对象提供在直接访问硬件的存储器映射位置之前检查每一引用的安全接口。

在使用软件隔离的一个实施例中，I/O访问对象的整个可执行指令被包含在可信运行时324内，并在设备驱动程序进程300内运行。由可信运行时224中的I/O访问对象332、334、336和338中的可执行指令执行确保对硬件的访问有效的检查。在使用硬件隔离的另一实施例中，处理器的进程隔离硬件被编程来允许设备驱动程序仅访问I/O端口空间或I/O存储器空间中该驱动程序被准许访问的特定区域。在使用硬件隔离的实施例中，配置进程隔离硬件的可执行指令驻留在OS内核210内。

驱动程序配置

一个或多个实现使用编码在系统组件中的元数据中的配置要求来描述系统各部分、解释它们如何组合并指定它们与系统的其它部分的行为交互。元数据声明性地对系统的每一组件及其配置要求加上标签，诸如内核、应用程序或设备驱动程序。配置要求包括关于依赖性、导出服务和资源要求的信息。工具在系统执行之前使用这种元数据来验证系统组件的可执行指令被正确配置。该元数据在系统执行期间使用以正确配置系统的每一组件，使得它可按其程序员所期望地执行。

系统元数据被归档在被称为清单的一个或多个系统存储中。顶层系统清单指向描述各个组件(诸如设备驱动程序)的清单。通过这些清单，诸如引导加载器或系统验证器的软件可发现系统的每一组件。

系统清单足以允许对系统的离线分析。采用本文中所述的实现，管理员能够仅使用硬件设备的描述和系统清单来发现对众多“设备驱动程序”相关问题的回答。这样的问题例如包括：系统是否会对特定硬件引导、哪些驱动程序和服务将初始化、以及哪些应用程序可运行？

规范

可运行系统映像包含作为元数据嵌入的整个系统的配置要求。使用元数据，一个或多个所述实现维持三个不变性。第一，OS将永远不会安装因与另一驱动程序或系统的另一部分冲突的配置要求而不能成功启动的设备驱动程序。第二，OS将永远不会启动因配置冲突或缺少资源而不能成功运行的设备驱动程序。第三，设备驱动程序不能在运行时使用未在其配置要求中声明的资源。

当可能时，本文中所述的一个或多个实现使用高级语言的自定义元数据属性来将配置要求插入源代码，使得仅必须维护一个源文档。自定义属性可附连于源代码实体，诸如类、方法或字段声明。编译器将属性编码到包含得到的中间语言可执行指令的文件中。编译器、链接器、安装工具和验证工具可读取用可执行指令编码的元数据，尽管它们未执行指令。

作为示例，以下源代码示出用于声明视频设备驱动程序(诸如，S3^TMTrio64^TM)的配置要求的某些属性：

[DriverCategory]

[Signature(″/pci/03/00/5333/8811″)]

class S3TrioConfig :DriverCategoryDeclaration

{

//来自PCI配置的硬件资源

[IoMemoryRange(0，Defaul t＝0xf8000000，Length＝0x400000)]

IoMemo ryRange frameBuffe r；

//固定硬件资源

[IoFi xedMemoryRange(Base＝0xb8000，Length＝0x8000)]

IoMemo ryRange textBuffer；

[IoFi xedMemoryRange(Base＝0xa0000，Length＝0x8000)]

IoMemo ryRange fontBuffe r；

[IoFi xedPortRange(Base＝0x03c0，Length＝0x20)]

IoPo rtRange cont rol；

[IoFi xedPortRange(Base＝0x4ae8，Length＝0x02)]

IoPo rtRange advanced；

[IoFixedPortRange(Base＝0x9ae8，Length＝0x02)]

IoPo rtRange gpstat；

//通道

[ExtensionEndpoi nt(typeof(Extensi onContract.Exp))]

TRef<Extensi onCont ract.Exp:Start>i osys；

[Servi ceEndpoi nt(typeof(vi deoDevi ceContract.Exp))]

TRef<Se rvi ceProvi de rCont ract.Exp:Start>vi deo；

...

}

[DriverCategory(驱动程序类别)]和[Signature(签名)]属性声明该模块为PCI视频设备的特定类的设备驱动程序。DriverCategory表示实现特定硬件的设备驱动程序的应用程序的类别。其它类别包括用于实现软件服务的应用程序的ServiceCategory(服务类别)、用于web服务器扩展的WebAppCategory(web应用程序类别)。

[IoMemoryRange(Io存储器范围)]属性声明frameBuffer(帧缓冲器)是从设备的PCI配置空间中的第一条目得到的。帧缓冲器的该位置是在配置硬件时确定的，且硬件参数，诸如存储器区域的大小，必须可与属性中的配置值兼容。[IoFixedMemoryRange(Io固定存储器范围)]和[IoFixedPortRange(Io固定端口范围)]属性指定驱动程序或者需要用于存储器映射访问的固定范围的地址空间或者用于访问设备寄存器的固定范围的I/O端口。

在此实施例中，IoDmaRange(Io DMA范围)、IoIrqRange(Io中断请求范围)、IoMemoryRange(Io存储器范围)和IoPortRange(Io端口范围)对象是连续访问对象的集合的容器，且可分别与IoDma、IoIrq、IoMemory和IoPort访问对象互换使用。

[ExtensionEndpoint(扩展端点)]属性声明，驱动程序必须配备通道端点来与设备程序的父进程通信。在诸如S3^TMTrio64^TM的设备驱动程序中，I/O系统是父进程。

[ServiceEndpoint(服务端点)]属性声明驱动程序必须配备有至系统目录服务的通道端点，且使用视频驱动程序的应用程序将通过该端点被目录服务绑定至设备驱动程序。

编译时

在编译时，高级语言编译器将自定义属性作为元数据嵌入到包含设备驱动程序的中间语言可执行指令的文件中。使用中间语言元数据访问库，一个或多个所述实现可从中间语言文件中检索所嵌入的元数据，而不执行文件中所包含的可执行指令。

在链接时，清单创建工具从中间语言文件中读取自定义属性元数据来创建应用程序清单。应用程序清单是枚举应用程序的组件和配置要求的XML文件。应用程序清单在“Self-Describing Artifacts and Application Abstractions(自描述产物和应用程序抽象)”中更详细描述。

以下XML包含视频设备驱动程序(诸如S3^TMTrio64^TM视频设备驱动程序)的清单信息的部分：

<assembly filename＝″Namespace.Contracts.dll″

version＝″1.0.0.2299″/>

<assembly fil ename＝″Io.Cont racts.dll″version＝″1.0.0.2299″

/>

<assembly filename＝″System.Compiler.Runtime.dll″

version＝″1.0.0.2299″/>

<assembly filename＝″MS.SingSharp.Runtime.dll″

version＝″1.0.0.2299″/>

</assemblies>

<devicesignature＝″/pci/03/00/5333/8811″/>

<ioMemoryRangeindex＝″0″baseAddress＝″0xf8000000″

rangeLength＝″0x400000″/>

<ioMemoryRange baseAddress＝″0xb8000″rangeLength＝″0x8000″

fixed＝″True″/>

<ioMemoryRange baseAddress＝″0xa0000″rangeLength＝″0x8000″

fixed＝″True″/>

<ioPortRange baseAddress＝″0x3c0″rangeLength＝″0x20″

fixed＝″True″/>

<ioPortRange baseAdd ress＝″0x4ae8″rangeLength＝″0x2″

fixed＝″True″/>

<ioPortRange baseAddress＝″0x9ae8″rangeLength＝″0x2″

fixed＝″True″/>

<extensi on startStateId＝″3″cont ractName＝″MS.OS-

.Extendi ng.Extensi onContract″endpoi ntEnd＝″Exp″

assembly＝″Namespace.Cont racts″/>

<se rvi ceProvi de r startStateId＝″3″cont ractName＝″MS.OS-

.Io.vi deoDevi ceContract″endpoi ntEnd＝″Exp″

assembly＝″Io.Contracts″/>

</d ri ve rCatego ry>

...

</mani fest>

安装时

采用本文中所述的一个或多个实现，系统保证不会安装不能启动的设备驱动程序。为此，系统在设备驱动程序安装之前验证设备驱动程序的整个配置要求可被满足。

应用程序是支持本文中所述的一个或多个实现的OS中的第一类抽象。该概念在“Self-Describing Artifacts and Application Abstractions”中更详细描述。在一个实施例中，为了被执行，一组可执行指令由安装程序添加到应用程序以根据应用程序的配置要求来初始化应用程序。在替换实现中，根据应用程序的配置要求初始化应用程序的可执行指令被包含在可信运行时中，并通过解释应用程序的配置元数据来创建配置对象和访问对象。

安装程序从应用程序清单中的元数据开始。安装程序验证，应用程序的每一程序集存在且是类型和存储器安全的。它也验证，所有通道契约被正确实现。

一旦这些内部特性被解决并验证，安装程序就接着试图解决和验证所有外部依赖性。例如，安装程序确保设备驱动程序使用的任何硬件资源不会与任何其它驱动程序所需的硬件资源冲突。安装程序也验证应用程序所使用的每个类型的通道的存在。如果应用程序导出通道，则安装程序验证，所导出的通道不与另一应用程序冲突。当冲突发生时，系统清单中的策略解决冲突。例如，清单可声明仅一个设备驱动程序可提供视频控制台契约。其它视频驱动程序的安装可被禁止，或在引导时仅激活单个视频驱动程序。

编译时反射(CTR)用于生成可信可执行指令来为系统资源初始化应用程序的配置对象和访问对象。在一个实施例中，CTR模板在安装时处理执行应用程序清单中所指定的程序集中的属性程序元素。

通过将系统清单元数据更新为包括新应用程序或设备驱动程序来完成安装进程。

在至少一个实现中，整个安装进程离线进行，安装仅在下一系统引导时才变为可见。或者，整个安装进程可在线执行和/或部分在线执行。

运行时

在运行时，元数据驱动内核、设备驱动程序、服务和应用程序的初始化。引导加载器读取系统清单的一部分来确定应加载哪些内核、设备驱动器和服务。这些加载和启动执行的次序不在任何地方指定；相反，系统从所指定的依赖性来推断次序。

随着每一应用程序被启动，内核验证并解决所有元数据依赖性，并在内核中建立进程配置记录。使用CTR发射到应用程序内的可信可执行指令解析配置记录来创建配置对象328并创建访问对象332、334、336、338、340以便访问外部资源。编译时反射(CTR)为配置对象428生成可执行指令。

回到S3^TMTrio64^TM设备驱动程序的示例，驱动程序配置记录中的内核记录记录了用于frameBuffer、textBuffer(文本缓冲器)和fontBuffer(字体缓冲器)的IoMemoryRange对象的需求。内核也记录用于控制、高级和gpstat I/O端口的IoPortRange对象。内核创建将设备驱动程序连接至I/O子系统的通道以及将驱动程序连接至名空间的第二通道。通道端点被添加到驱动程序的配置记录。

当设备驱动程序开始执行时，可信运行时中的可执行指令在驱动程序的对象空间中创建适当的IoMemoryRange和IoPortRange访问对象。因为这些仅可由可信运行时构造，所以设备驱动程序仅可访问在其配置元数据中声明并由内核I/O子系统检查过冲突的I/O资源。

在配置元数据中声明通道端点确保三个特性。第一，SIP的可执行指令可被静态验证以确保它们仅通过完全声明的通道、严格遵循通道契约来通信。第二，应用程序不需包含全局名。例如，S3^TMTrio64^TM视频设备驱动程序不知道系统名空间中的/dev/video名。相反，驱动程序使用局部名，S3Trio64Config.video来指示具有给定契约(ServiceProviderContract(服务提供者契约))的通道。I/O名空间的整个布局可在不影响视频驱动程序中的单行源代码的情况下改变。第三，应用程序可以是遵循至少可能的特权的原则装入“沙箱”的，以移除当前系统中的差错和安全易受攻击性的源。例如，尽管S3^TMTrio64^TM驱动程序保存连接至系统目录服务的端点，但驱动程序没有能力创建新名字或连接至任何其它系统进程。

隔离设备驱动程序的方法实现

图4示出了用于任何扩展(诸如设备驱动程序)的初始化的方法400。采用该方法400，OS从设备的驱动程序清单中读取元数据来创建设备驱动程序对象。该方法400由如图1中所示的各种组件中的一个或多个执行。而且，该方法400可用软件、硬件、固件或其组合执行。

在图4的402，操作系统(OS)获取不可信程序模块(诸如设备驱动程序)。OS从设备驱动程序的清单中确定一组所要求或请求的计算资源。此处，计算资源可包括虚拟资源(诸如通道)或硬件资源(诸如多个I/O端口或I/O存储器)或其它这样的资源。

OS通过读取设备驱动程序的清单来作出该判断。或者，OS可分析设备驱动程序的可执行指令。或者，OS可从可执行指令或相关联的数据结构提取元数据。

在404，OS确定是否有资源已经被分配给OS或另一设备驱动程序。如果是，则进程在406异常中止。本发明的替换实施例可在异常中止后继之以附加策略，诸如在系统资源被释放时重启初始化进程、与当前所有者协商来释放资源、请求用户许可停止冲突的驱动程序、向设备驱动程序作者通知潜在错误的资源请求等。

而且，此处OS可作出关于设备驱动程序和所请求的计算资源的其它判断。OS确认设备驱动程序被允许访问所请求的计算资源并以它所请求的方式访问资源。

在408，OS记录对设备驱动程序的资源分配。

在410，OS提供要由设备驱动程序对每一所要求或请求的资源使用的可信局部访问对象。可信运行时对象(图3中描绘)是局部访问对象的示例。

OS执行的“提供”在此处可包括简单地采用已经预先设定和固定的可执行指令(和数据)，它们是局部访问对象。这可包括生成对特定需求和条件定制的新指令(可能基于模板)。或者，OS可在之间做些事。例如，它可配置或略微更改现有的可执行指令，这些指令是局部访问对象。

实际上，OS可将可信局部访问对象的可执行指令(或数据)插入或链接到不可信设备驱动程序，使得设备驱动程序可经由所插入或链接的局部访问对象获取访问权。

在412，OS针对所要求的资源使用该组局部访问对象来初始化设备配置对象。配置对象可包括在清单中指定的附加设置。附加设置的示例可以是表明用户优选数据/时间格式的排序扩展的设置。

在414，OS启动设备驱动程序可执行指令的执行。初始化设备驱动程序的可执行指令由OS或安装系统而非设备驱动程序编程员提供。

在416，执行设备驱动程序通过局部访问对象来访问所请求的计算资源。而且，执行设备驱动程序仅可访问所请求的计算资源(没有其它)且仅经由所链接或插入的局部访问对象。

结论

本文中所述的技术可用众多方式实现，包括(但不限于)作为一个或多个计算机网络的一部分或其组合的程序模块、通用或专用计算系统、网络服务器和装备、专用电子和硬件、固件。

尽管用结构特征和/或方法步骤专用的语言描述了一个或多个上述实现，但可以理解，其它实现可无需此处所述的特定的示例性特征或步骤而实现。相反，特定的示例性特征和步骤被公开为一个或多个实现的优选形式。在某些情况中，可略去或简化公知特征以阐明示例性实现的描述。而且，为易于理解起见，某些方法步骤被描绘为分开的步骤；然而，这些分开描绘的步骤不应被解释为在其实现时必然次序相关。

Claims

1.一个或多个具有处理器可执行指令的处理器可读介质，所述指令在由处理器执行时，执行包括以下步骤的方法：

获取设备驱动程序(300)，其中所述设备驱动程序(300)是一组可执行指令；

确定执行所述设备驱动程序(300)的所述一组可执行指令所需的一组计算资源(312和350)；

提供一个或多个局部访问对象(332、333、336、338和340)以供所述设备驱动程序(300)用于访问所需的一组计算资源(312和350)，所述一个或多个局部访问对象(332、333、336、338和340)中的每一个包括可执行指令；

启动所述设备驱动程序(300)的所述一组可执行指令和所述一个或多个局部访问对象(332、333、336、338和340)的可执行指令的执行。

2.如权利要求1所述的一个或多个介质，其特征在于，所述确定动作包括：获取与所述设备驱动程序(300)相关联的处理器可读清单(142)，所述设备驱动程序清单(142)指定执行所述设备驱动程序(300)的所述一组可执行指令所需的所述一组计算资源(312和350)。

3.如权利要求1所述的一个或多个介质，其特征在于，所述方法还包括确认所述设备驱动程序(300)被授权来访问所需的一组计算资源(312和350)。

4.如权利要求1所述的一个或多个介质，其特征在于，所述提供动作还包括：生成一个或多个局部访问对象(332、333、336、338和340)以供所述设备驱动程序(300)用来访问所需的一组计算资源(312和350)，所述局部访问对象由操作系统提供。

5.一个或多个具有处理器可执行指令的一个或多个处理器可读介质，所述指令在由处理器执行时，执行包括以下步骤的方法：

获取包括一组可执行指令的不可信程序模块(300)，且所述不可信程序模块(300)被配置成访问一个或多个计算资源(312和350)；

确定所述不可信程序模块(300)的一个或多个目标计算资源(312和350)，其中所述一个或多个目标计算资源(312和350)是所述不可信程序模块(300)在所述不可信程序模块(300)的所述一组可执行指令被执行时将设法访问的计算资源(312和350)；

向所述不可信程序模块(300)提供一个或多个可信局部访问对象(332、333、336、338和340)，使得所述不可信程序模块经由所提供的一个或多个可信局部访问对象(332、333、336、338和340)获取对所述一个或多个目标计算资源(312和350)的访问权。

6.如权利要求5所述的一个或多个介质，其特征在于，所述可信局部访问对象(332、333、336、338和340)中的每一个与一个或多个计算资源(312和350)相关联，且所述可信局部访问对象(332、333、336、338和340)中的每一个包括一组可执行指令。

7.如权利要求5所述的一个或多个介质，其特征在于，所述可信局部访问对象(332、333、336、338和340)中的每一个与一个或多个计算资源相关联，所述可信局部访问对象(332、333、336、338和340)中的每一个包括可执行指令，且所述提供还包括配置所述一个或多个可信局部访问对象(332、333、336、338和340)的可执行指令以经由所述一个或多个可信局部访问对象(332、333、336、338和340)所配置的可执行指令向所述不可信程序模块(300)提供对所述一个或多个目标计算资源(312和350)的访问权。

8.如权利要求5所述的一个或多个介质，其特征在于，所述不可信程序模块(300)是设备驱动程序(300)。

9.一个或多个具有处理器可执行指令的处理器可读介质，所述指令在由处理器执行时，执行包括以下步骤的方法：

确定所述不可信程序模块(300)的一个或多个目标计算资源(312和350)，其中所述一个或多个目标计算资源(312和350)是所述不可信程序模块(300)在所述程序模块的所述一组可执行指令被执行时将设法访问的计算资源(312和350)；

向所述不可信程序模块(300)提供一个或多个可信局部访问对象(332、333、336、338和340)，使得所述不可信程序模块经由所提供的一个或多个可信局部访问对象(332、333、336、338和340)获取对所述一个或多个目标计算资源(312和350)的访问权，所述一个或多个可信局部访问对象(332、333、336、338和340)与所述一个或多个目标计算资源(312和350)相关联；

许可所述程序模块访问仅可经由与所述一个或多个目标计算资源(312和350)相关联的一个或多个可信局部访问对象(332、333、336、338和340)来访问所述一个或多个目标计算资源(312和350)。

10.如权利要求9所述的一个或多个介质，其特征在于，所述不可信程序模块(300)是设备驱动程序(300)。