包含受信执行环境的主机的证明专利检索-翻译管理系统人工智能专利检索查询-专利查询网

包含受信执行环境的主机的证明

阅读：716发布：2020-05-13

专利汇可以提供包含受信执行环境的主机的证明专利检索，专利查询，专利分析的服务。并且证明服务验证从主机接收到的指示，该指示涉及主机包含受信执行环境 (TEE)。在成功验证之际，证明服务发放一证书，该证书能够被主机用来向与证明服务具有信任关系的实体进行认证。，下面是包含受信执行环境的主机的证明专利的具体信息内容。

权利要求

1.一种在计算环境中建立针对主机的信任的方法，所述方法包括：
主机证明服务从被部署在物理机器上的主机接收所述主机满足的特定特征的可验证指示；
尝试从所述特定特征的指示中确定所述主机满足特定要求；以及
如果所述主机满足所述特定要求，包括至少满足所述主机包括受信执行环境TEE的要求，则所述主机证明服务向所述主机颁发证书，所述主机能使用所述证书来向与所述主机证明服务具有信任关系的一个或多个实体进行认证。
2.如权利要求1所述的方法，其特征在于，所述特定要求还包括与实现所述主机的物理机器上的受信平台模块TPM有关的要求。
3.如权利要求1所述的方法，其特征在于，还包括作为在确定实现所述主机的所述物理机器可验证地满足所述特定要求方面失败的结果，向被配置成部署访客虚拟机的虚拟机管理器VMM通知所述主机不满足所述特定要求。
4.如权利要求1所述的方法，其特征在于，还包括作为在确定所述主机可验证地满足所述特定要求方面失败的结果，向虚拟机管理器VMM通知所述主机不可用于被屏蔽的访客虚拟机的部署。
5.如权利要求1所述的方法，其特征在于，所述特定要求还包括下述要求：针对实现所述主机的物理主机机器来提供正确且可信的统一可扩展固件接口UEFI报告以验证未被损害的引导已发生。
6.如权利要求1所述的方法，其特征在于，所述特定要求还包括所述主机包括正确管理程序实施的代码完整性HVCI策略确认的可验证指示被提供的要求。
7.如权利要求1所述的方法，其特征在于，其中所述特定要求还包括所述主机位于特定地理位置中的要求。
8.如权利要求1所述的方法，其特征在于，其中所述特定要求还包括所述主机耦合到安全网络的要求。
9.如权利要求1所述的方法，其特征在于，还包括创建所述主机证明服务与密钥分发服务之间的信任关系，所述主机能通过呈现所述证书来从所述密钥分发服务获得密钥。
10.如权利要求1所述的方法，其特征在于，所述方法被执行在一环境中，其中所述主机证明服务被实现在具有结构管理系统的环境中，其中所述结构管理系统被配置成管理主机操作系统、主机配置、HVCI白名单、HVCI撤销列表、UEFI白名单或UEFI撤销列表中的至少一个，并且其中相比于被用于认证所述结构管理系统的管理员，不同的认证和/或授权服务被用于认证所述主机证明服务的管理员。
11.如权利要求1所述的方法，其特征在于，其中所述方法被执行在一环境中，其中所述主机证明服务被实现在具有虚拟机管理器的环境中，其中所述虚拟机管理器被配置成将被屏蔽的访客虚拟机部署到所述主机，但是其中所述虚拟机管理器不能解密被屏蔽的访客虚拟机。
12.如权利要求11所述的方法，其特征在于，所述方法被实施在一环境中，其中相比于被用于认证所述虚拟机管理器的管理员的认证服务，不同的认证服务被用于认证所述主机证明服务的管理员。
13.一种在计算环境中建立针对主机的信任的方法，所述方法包括：
使用物理机器来实现的主机将所述主机的特定特征的可验证指示发送到主机证明服务；以及
如由所述主机证明服务评估所述特定特征的指示所确定的，作为所述主机满足特定要求的结果，包括至少满足所述主机包括受信执行环境TEE的要求，所述主机从所述主机证明服务接收一证书，所述主机能使用所述证书来向与所述主机证明服务具有信任关系的一个或多个实体进行认证。
14.如权利要求13所述的方法，其特征在于，所述特定要求还包括从以下构成的组中选择的要求：
(a)与实现所述主机的所述物理机器上的受信平台模块TPM有关的要求，
(b)针对在其上实现所述主机的所述物理机器来提供正确且可信的统一可扩展固件接口UEFI报告的要求，
(c)所述主机包括正确管理程序实施的代码完整性HVCI策略确认的可验证指示被提供的要求，
(d)所述主机位于特定地理位置中的要求，以及
(e)所述主机被耦合到安全网络的要求。
15.如权利要求13所述的方法，其特征在于，所述方法被实施在一环境中，其中存在所述主机证明服务与密钥分发服务之间的信任关系，所述主机能通过呈现所述证书来从所述密钥分发服务获得密钥。
16.如权利要求15所述的方法，其特征在于，其中被屏蔽的访客虚拟机被虚拟机管理器在承租人的请求之际被部署到所述主机，其中所述虚拟机管理器不能够解密被屏蔽的访客虚拟机，所述方法还包括：
所述主机使用所述证书来从信任所述主机证明服务的密钥分发服务获得密钥，其中所述密钥分发服务接受被所述主机证明服务签名的证书；以及
主机使用所述密钥来解密被屏蔽的访客虚拟机，使得所述访客虚拟机能被运行在所述主机上。
17.如权利要求16所述的方法，其特征在于，还包括：
所述主机准备关于所述访客虚拟机的部署的安全细节的经加密的消息，其中所述经加密的消息不能被所述虚拟机管理器解密，但能够被所述承租人解密；以及所述主机将所述经加密的消息发送到所述虚拟机管理器，其中其能被转发到所述承租人，而无需所述虚拟机管理器能够读取所述经加密的消息。
18.一种在计算环境中用于将经加密的实体部署在受信实体上的方法，所述方法包括：
在受信实体处，接收来自非受信实体的经加密的实体，其中作为提供满足特定要求的受信实体的特定特征的可验证指示的结果，所述受信实体被授权机构信任，其中所述非受信实体不被所述授权机构信任，所述特定要求包括受信实体是具有受信执行环境TEE的虚拟机的要求；
在所述受信实体处，使用来自所述授权机构的信任证书来从密钥分发服务获得密钥，其中所述密钥分发服务被所述授权机构信任；以及
使用所述密钥来解密所述经加密的实体以允许所述经加密的实体被部署在所述受信实体处。
19.如权利要求18所述的方法，其特征在于，所述特定要求包括与实现所述受信实体的物理机器上的受信平台模块TPM有关的要求。
20.如权利要求18所述的方法，其特征在于，所述特定要求包括所述受信实体使用具有正确且可信的统一可扩展固件接口UEFI报告的物理机器来实现的要求。
21.如权利要求18所述的方法，其特征在于，所述特定要求包括所述受信实体包括正确管理程序实施的代码完整性HVCI策略确认的要求。
22.如权利要求18所述的方法，其特征在于，所述特定要求包括所述受信实体物理地位于特定地理位置中的要求。
23.如权利要求18所述的方法，其特征在于，所述特定要求包括所述受信实体耦合到安全网络的要求。
24.如权利要求18所述的方法，其特征在于，所述经加密的实体包括要被部署在所述受信实体上的网络翻译信息。
25.如权利要求18所述的方法，其特征在于，所述经加密的实体包括要被部署在所述受信实体上的敏感数据。
26.如权利要求18所述的方法，其特征在于，所述经加密的实体包括被用于配置所述受信实体或要被部署在所述受信实体上的其他实体的配置数据。
27.一种具有指令的计算机可读存储介质，当所述指令被执行时使得机器执行如权利要求1-12中任一权利要求所述的方法。
28.一种计算机系统，包括用于执行如权利要求1-12中任一权利要求所述的方法的装置。
29.一种具有指令的计算机可读存储介质，当所述指令被执行时使得机器执行如权利要求13-17中任一权利要求所述的方法。
30.一种计算机系统，包括用于执行如权利要求13-17中任一权利要求所述的方法的装置。
31.一种具有指令的计算机可读存储介质，当所述指令被执行时使得机器执行如权利要求18-26中任一权利要求所述的方法。
32.一种计算机系统，包括用于执行如权利要求18-26中任一权利要求所述的方法的装置。

说明书全文

包含受信执行环境的主机的证明

[0001] 背景

[0002] 背景和相关技术

[0003] 计算系统的互连促成了分布式计算系统，诸如所谓的“云”计算系统。在本说明书中，“云计算”可以是用于允许对可配置的计算资源(如网络、服务器、存储、应用、服务等)的共享池进行无处不在的、方便的、按需的网络访问的系统或资源，这些计算资源可用减少的管理努力或服务提供者交互来被供应和释放。云模型可由各种特性(如按需自服务、广泛网络访问、资源池、快速灵活性、测量服务等)、服务模型(如软件即服务(“SaaS”)、平台即服务(“PaaS”)、基础结构即服务(“IaaS”))以及部署模型(如私有云、社区云、公共云、混合云等)组成。

[0004] 基于云和远程的服务应用是流行的。这种应用被主控于诸如云的公有和私有远程系统上，并且通常提供一组基于web的服务用于与客户端来回通信。

[0005] 企业计算系统在增加的违约风险之下，从而导致金钱赔偿、知识产权的泄漏或人为破坏。具体而言，可能存在针对运行在虚拟机中的数据中心中的工作负载的来自这些虚拟机运行在其上的主控结构(虚拟化主机、存储和联网系统)和被用于管理该结构和虚拟机的管理系统的威胁。

[0006] 该威胁与在公共云处或在服务提供者处操作它们的工作负载的承租人相关：尽管承租人可能在作为一个机构的情况下信任服务提供者，但是其不想将该信任扩展到服务提供者的工作人员，这些工作人员可能由于个人犯罪主动性或已经被外部攻击者收买或招募而是恶意的，或者这些工作人员的凭证可能已经被外部攻击者使用包括“钓鱼式攻击”在内的多种类型的攻击中的一种盗取。但是这还与一企业的内部操作相关：企业自己的IT人员可类似地使得他们的凭证被盗取，或可以出于其他原因而是恶意的。在当前实践中，具有用于操作主控结构的特权的IT人员具有对所有工作负载的广泛且近乎无限制的访问。

[0007] 这些增加的威胁在现代云计算出于降低的资本和操作花费和出于大规模、高可用性和地理范围到达而利用自动化时出现。但是通过允许攻击者充分利用自动化技术并在大量的合法动作之中隐藏他们的踪迹，这种自动化和大规模还增加了风险。

[0008] 因而，能够启动虚拟化的工作负载和结构两者的自动化管理工作流，同时针对操作该结构的IT人员保护工作负载可以是有用的。挑战是，在当前实践中，虚拟机管理系统(VMM)在供应和管理虚拟机(VM)中扮演了积极的角色，并且类似地，结构管理系统(FM)在供应和管理结构中扮演了积极的角色，但是使得任一者作为受信计算以此为基础被构建的“受信计算基础”的一部分出于至少两个原因可能是有问题的：管理系统是大型且复杂的，并且由此通常不能使其成为安全的或被证明为是安全的，并且承租人不想要将信任扩展到运行VMM和FM的服务提供者的操作人员。

[0009] 本文要求保护的主题不限于解决任何缺点或仅在诸如上述环境这样的环境中操作的各实施例。相反，提供该背景仅用于例示其中可实施所述一些实施例的一个示例性技术领域。

[0010] 简要概述

[0011] 本文中示出的一个实施例包括本文中示出的一种用于在受信实体上部署经加密的实体的方法。一方法包括，在受信实体处，接收来自非受信实体的经加密的实体，其中作为提供满足特定要求的受信实体的特定特征的可验证指示的结果，受信实体被授权机构信任。非受信实体不被授权机构信任。在受信实体处，来自授权机构的信任凭证被用于从密钥分发服务获得密钥。密钥分发服务可以是授权机构的一部分或可信任授权机构。密钥被用于解密经加密的实体以允许经加密的实体被部署在受信实体处。

[0012] 提供本概述以便以简化的形式介绍以下在详细描述中进一步描述的一些概念。本概述并非旨在标识出要求保护的主题的关键特征或必要特征，亦非旨在用作辅助确定要求保护的主题的范围。

[0013] 附加特征和优点将在以下描述中提出，且部分会从描述中显而易见，或者可以通过实施本文的原理来获悉。本发明的特征和优点可以通过在所附权利要求书中特别指出的工具和组合来实现和获得。本发明的特征从以下描述和所附权利要求书中将更完全显而易见，或者可以通过如下文所述实施本发明而获悉。

[0014] 附图简述

[0015] 为了描述可获得以上记载的及其他优点和特征的方式，将参照各具体实施例呈现以上简述的主题的更具体描述，各具体实施例在附图中例示。理解这些附图仅描述典型的实施例，因此不应被视为限制本发明的范围，各实施例将通过使用附图以附加的具体性和细节来描述和解释，附图中：

[0016] 图1示出耦合到安全设备的处理单元；

[0017] 图2是一般地表示根据本文所述的主题的各方面配置的系统的示例性组件的框图；

[0018] 图3是例示出根据一个或多个实施例的实现本文所讨论的技术的示例计算设备的框图；

[0019] 图4示出根据一个或多个实施例的多个虚拟信任等级的示例；

[0020] 图5示出根据一个或多个实施例的实现多个虚拟信任等级的示例系统；。

[0021] 图6是示出根据一个或多个实施例的针对虚拟机启用虚拟安全模式的示例过程的流程图；

[0022] 图7是示出建立针对主机的信任的方法的流程图；

[0023] 图8是示出建立针对主机的信任的另一方法的流程图；以及

[0024] 图9是示出在受信实体上部署经加密的实体的另一方法的流程图。

[0025] 详细描述

[0026] 本发明的各实施例可实现被用于自动化虚拟机(VM)上的管理操作(诸如部署和迁移)的模式。具体而言，各实施例可确定主机满足特定策略要求。当主机满足特定策略要求时，证书可被颁发给主机，主机可使用该证书来执行各种部署活动。具体而言，要求中的至少一个可以是主机包括受信执行环境(TEE)。各种不同的TEE可以联合地或替换地被使用。在一个实施例中，这可以被实现为在主机VM的内核中运行的函数。在另一实现中，它可以在管理程序中运行。在其他实施例中，其可以被实现为由管理程序使用处理器的存储器映射能力所实施的单独地址空间。在其他实施例中，它可以被实现为由处理器实施的单独执行区域(诸如ARM架构的TrustZone(信任区域)、由加利福尼亚州圣克拉拉市的英特尔公司描述的新兴SGX能力、或受信平台模块(TPM)技术)。这些不同的实现可以提供相似的功能，诸如执行密码操作、存储凭证、验证代码或数据的完整性、以及保护秘密的能力。然而，它们在它们所提供的安全属性方面有所差异。一些实施例可通过使用本文中称为虚拟安全模式(VSM)的功能来包括受信执行环境(TEE)，该虚拟安全模式在以下被更加详细描述。

[0027] 以上示出的模式可被一般化到取决于安全部署或配置或迁移的许多其他场景，诸如配置用于安全联网的IPsec、在比VM小的轻量容器中运行工作负载等。

[0028] 现在参考附图示出细节。

[0029] 在图1中，处理单元120可被连接到硬件安全设备122。安全设备122可以能够生成并安全地存储密码密钥，所述密码密钥可被用于保护计算机110的各个方面。在一个实施例中，安全设备122可以包括受信平台模块(TPM)安全设备等等。

[0030] 在本文档中，术语受信平台模块(TPM)被频繁地使用。TPM被本领域技术人员所熟知。然而，对术语TPM的使用并不旨在将本文中描述的主题的各方面仅限制为符合用于实现TPM的一个或多个标准版本的设备。相反，该术语被用作可根据本文中描述的主题的各方面所使用的安全组件的一个示例。

[0031] 在其他实现中，提供安全功能的其他安全组件也可被使用，而不背离本文所述的主题的各方面的精神或范围。各种安全设备可具有诸如以下的特征：

[0032] 1.受保护的存储器(在许多TPM应用中称为“被屏蔽的位置”)。安全设备可包括仅安全设备可向其进行写入的存储器。该存储器可被用于针对其他密码函数以及针对各种其他函数来存储测量、密封和拆封。

[0033] 2.用于标识安全设备并提供没有其他设备能解密的加密存储的方式。例如，安全设备可包括仅该设备知晓且能将该设备与其他设备区分开的秘密。

[0034] 3.用于执行证明的方式。安全设备可具有可被用于创建关于被安全设备控制的任意资产的受信消息的处理器或其他电路系统。被安全设备控制的一些示例性资产可包括密码对象、密封团块、安全设备与其相关联的平台的状态等。

[0035] 虽然安全设备通常被认为是分开的分立组件，但这不是必须的。例如，在一个实现中，与处理器耦合的固件可被用作安全设备。

[0036] 当术语TPM在本文中被使用时，可以理解，其他安全设备(包括在本说明书中本文提到的那些)的替代实现也可被使用，而不背离本文所述的主题的各方面的精神或范围。

[0037] 在使用虚拟机的情况下，用户可能想要具有关于虚拟机和主控环境的完整性的保证。图2是一般地表示根据本文所述的主题的各方面的系统的示例性组件的框图。图2中示出的各组件是示例性的且不意味着包括一切的可能需要或包括的组件。此外，在其他实施例中组件的数量可以不同，而不背离本文所述的主题的各方面的精神或范围。在一些实施例中，结合图2描述的组件可被包括在其他组件(示出或未示出)中或者被放置在子组件中，而不背离本文所述的主题的各方面的精神或范围。在一些实施例中，结合图2所描述的组件和/或功能可跨多个设备分布。

[0038] 转向图2，系统200可包括主机230、密钥分发服务235和其它组件(未示出)。主机230可适合用于主控可与VHD 205-207相关联的一个或多个虚拟机208-210。主机230可主控一个或多个虚拟机(例如，访客虚拟机208-210)。虚拟机可与一个或多个VHD(例如，VHD
205-207中的一个或多个)相关联。作为与将操作系统功能提供到主机230的“根”VM 231的对比，访客虚拟机208-210可在各主机之间迁移。主机230可包括管理程序215和分立受信平台模块261或其他安全设备。

[0039] 管理程序215是创建虚拟机208-210和根VM 231可在其中操作的虚拟环境的组件。管理程序215可用软件、固件、硬件、以上中的两者或更多者的组合等等被实现。管理程序
215可直接在主机230的硬件上执行或可在被主控在主机230上的操作系统环境内执行。

[0040] 在一个实现中，管理程序215可管理一个或多个虚拟TPM(vTPM)220-222。每个vTPM可与一虚拟机(例如，虚拟机208-210中的一个)相关联。在这个实现中，管理程序215可在对管理程序215外部的组件不可用的管理程序215的安全存储器中存储表示vTPM的数据。为了获得对vTPM的访问，攻击者可被要求获得对管理程序215本身的控制。在另一实现中，主机230可管理vTPM 220-222。在这个实现中，具有管理员特权的用户和进程可以能够访问vTPM
220-222。在另一实现中，主机230外部的服务可管理vTPM 220-222。在另一实现中，如由图2中的虚线中显示的vTPM所示的，vTPM可被实现在根VM 231的VSM 265中。

[0041] 在一个实现中，密钥分发服务235可被主控在主机230的外部。

[0042] 可用于解密vTPM的密钥可用各种方法来分发。例如，在一个实现中，密钥可在知晓主机的状态满足策略之后的任意时间被分发。例如，在将主机230配置在满足策略的状态中之后，TPM的一个或多个寄存器的状态可被TPM 261签名并被发送到密钥分发服务235。在接收到这个之后，密钥分发服务235可立即或在此后的任意时间向主机230发送按照如下方式加密或包装的密钥，使得主机230可仅在主机230处于满足策略的状态中时解密该密钥。以这种方式来加密该密钥可涉及用主机的TPM的公钥来加密该密钥以及密封到满足策略的状态(如被主机的TPM测量的)。

[0043] 在另一实现中，密钥分发服务235可在提供密钥之前等待直到密钥被请求。在这个实现中，密钥分发服务235可在提供密钥之前验证进行请求的机器的状态。如果密钥满足策略，则密钥可由密钥分发服务235提供。否则，密钥分发服务235可拒绝给请求者密钥。

[0044] 以上的密钥分发的示例仅仅是示例性的。基于此处的教示，本领域技术人员可认识到也可使用的用于分发密钥的其他方式，而不背离此处所描述的主题的各方面的精神或范围。

[0045] 以上的教导可被应用到不具有安全设备或具有较旧版本的安全设备的安全机器。例如，一些机器可能根本不具有TPM。其他机器可能具有TPM，但是该TPM可能根据旧的TPM标准来实现。一些操作系统不可执行，除非它们能够访问根据某个版本或更高的版本实现的TPM。

[0046] 为了改进如以上描述的平台之类的平台，平台可被配置有管理程序。管理程序接着可被用于在虚拟环境中执行操作系统。当操作系统请求访问TPM时，管理程序可提供适当版本的虚拟TPM。管理程序可保护虚拟TPM，所以只有管理程序才可改变虚拟TPM的受保护的存储器。对操作系统而言，虚拟TPM看上去就像分立的物理TPM。

[0047] 此外，用于创建虚拟TPM的种子秘密可经由键盘或其他输入设备来输入、从在种子秘密被使用之后断开连接的USB或其他外部存储中读取等等。

[0048] 以上用于保护机器的方法的一个益处是，机器的快速硬件(例如，CPU)可被用于执行vTPM的功能。这可极大地加速机器的密码功能。

[0049] 在较旧版本的TPM在机器上可用的情况下，该较旧版本的TPM可被用于提供该机器处于其中该机器被允许获得对vTPM密钥的访问的状态中的证据。虽然这可能没有像在机器上具有新版本的TPM以及使用该新版本的TPM来获得对vTPM密钥的访问那么理想，但是这可优于非TPM方案。

[0050] 现在考虑一初始方案，该方案具有VM 208、209和210的集合并且已经存在于数据中心环境中。用于加密的密钥分别受到虚拟受信平台模块(vTPM)220、221和222的保护。

[0051] 虚拟机208-210可经由数据中心被提供到一个或多个承租人。承租人可与虚拟机208-210中的一个或多个相关联。被屏蔽的VM被存储在数据中心的存储系统250中，但是在此处考虑的威胁模型下，承租人不信任存储系统250的访问控制机制，因为具有管理员特权的服务提供者职员可绕过这些控制。

[0052] 承租人可包括具有访问虚拟机中的一个或多个的权限的用户、公司或其他实体。多承租人环境中的“承租人”可以是分开的企业，如通常针对VM所假设的。但是它们也可以是一企业内部的各部门、或用户、或分开的应用－应当远离其他分组的任意种类的分组。在一些情况下，企业可通过在企业内允许用户、部门和应用的操作来管理这种容器的较弱的分隔，但是使用较强的VM分隔来针对其他潜在的敌意实体进行保护。

[0053] 在一种场景中，VM 208、209和210被部署在结构中的主机230之一上。在本文中示出的实施例中，“主机”是虚拟化平台。在示出的一些示例中，主机包括被部署在硬件(示出为服务器251)上的管理程序215加上被部署在管理程序215上的主机VM 231。然而应当领会，主机也可按其他方式来实现。例如，一些时候，主机可在没有主机VM的情况下被实现在管理程序215中。由此，如本文中使用的“主机”简单地指具有任何可被构造的形式的虚拟化平台。部署动作可由承租人使用VMM 253所呈现的自服务管理门户或由承租人通过编程接口行动或由另一接口来进行。在该场景的另一变体中，该动作可由VMM253的自动化功能来进行，诸如以承租人指定的调度来部署或响应于主机故障的故障转移操作。在该场景的另一变体中，该动作可由服务提供者的操作人员来进行，以促进操作任务(诸如主机服务或资源分配)。对VM 208、209和210的保护并不基于对发起该动作的动作者的身份的信任，因为系统许可服务提供者的操作人员或自动化FM 254进行的动作，并且即使在承租人发起动作的情况下，也存在恶意职员截取并损害或伪造这样的动作的可能性。

[0054] 一旦被屏蔽的VM被部署在主机上，主机就对其进行解密，如被图2中示出的VM 208、209和210的非网纹版本示出的。在典型场景中，VM的虚拟硬盘驱动器(VHD)例如使用从华盛顿州雷蒙德市的微软公司获得的微软的BitLocker机制被加密，并如以上大致讨论的，使得其加密密钥以与经加密的物理硬盘驱动器用物理TPM对其密钥进行保护的方式相同的方式来用虚拟TPM(例如，vTPM 220、221和222)进行保护。在物理情况下，硬盘驱动器和物理TPM两者均属于相同的物理计算机并且由于它们在物理机器上的物理共位而被静态地启用且相互信任，但是在可被部署在任一物理机器上的虚拟机的情况下，虚拟TPM是自身被加密的软件+数据构造。所以，对被屏蔽的VM进行解密开始于主机230对vTPM 220、221和222进行解密，并且从其处访客VM将测量扩展到vTPM中来检索用于开始数据解密过程的密钥。为了这么做，主机需要检索用于解锁vTPM 220、221和222的密钥。在该情况下，主机解密被屏蔽的vTPM数据以使得vTPM能够执行。VM的TPM(从主机展示的vTPM)被VM内部的代码用于解密数据。

[0055] 如本文中使用的术语“虚拟硬盘驱动器”仅仅是示例性的。在其他替代中，其他虚拟存储设备(诸如虚拟软盘、虚拟固态存储或其他虚拟读写介质、虚拟CD ROM、DVD或其他虚拟介质)可取代，而不背离本文所述的主题的各方面的精神或范围。术语虚拟存储设备旨在涵盖包括例如以上提到的各个虚拟存储设备在内的任意类型的虚拟存储设备。

[0056] 虚拟存储设备可包括旨在供管理程序215使用的元数据或与该元数据相关联。在一些实现中(在以下更加详细描述)，该元数据可被隐藏并且不可被管理程序215所主控的虚拟机看到。该视图排除了旨在供管理程序215使用的元数据。在这些实现中，使用vTPM的虚拟机可仅对视图中的内容进行加密或解密。

[0057] 在其他没有vTPM的实现中(在以下更加详细描述)，包括旨在供管理程序使用的元数据的整个虚拟存储设备可被加密。在这些实现中，在从密钥分发服务获得密钥之后，管理程序可对包括旨在供管理程序使用的元数据的整个虚拟存储设备进行解密。

[0058] 返回图2，系统200可被主控在公共或私有云中。云是一术语，该术语借鉴了这样的理念，即计算、软件、数据存取、存储、以及其它资源可由连接到某个网络的实体来提供而无需用户知晓与递送那些资源的计算基础结构有关的位置或其它细节。

[0059] 承租人可能不想要其他承租人、云主控操作者、攻击者或其他实体获得对承租人的虚拟机的访问。承租人可能还想要来自云主控操作者的关于主控承租人的虚拟机的主机满足特定策略(例如，主机的配置处于承租人所定义的一个或多个状态的集合中)的保证。

[0060] 为了确保策略被满足，在一个实现中，承租人可要求分别与虚拟机208、209和210相关联的虚拟硬盘驱动器205、206和207的全部或各部分用秘密密钥来加密。经加密的虚拟硬盘驱动器可仅在秘密密钥被知晓的情况下不被加密。在没有其相关联的虚拟硬盘驱动器的情况下，虚拟机可能不能够被执行。

[0061] 关于一个和多个策略，可以理解，本文中的操作可被应用到一个或多个策略，而与是使用术语一个策略还是术语多个策略无关。例如，如果主机符合可接受策略集合中的任意一个(或在一些情况下，当主机符合全部策略或特定策略子集时)，则密封的密钥可被拆封。类似地，如果管理程序提供关于主机状态满足可接受策略集合中的任意一个的证据(或当主机状态满足所有策略或特定策略子集时)，密钥分发服务可提供用于访问vTPM的密钥。例如，管理程序可通过提供由主机的TPM作出的主机状态的证明来提供该证据。在一些实施例中，一个可被实现的这种策略是以下策略：其指定主机使用主机的安全子系统(诸如VSM
265)作出特定证书请求或主机能够使用主机的安全子系统来执行处理。如提到的，以下包括关于VSM的详细信息。

[0062] 在一个实现中，可被用于解密VHD的秘密密钥可以是与密钥分发服务235所提供的相同的密钥。在这个实现中，vTPM 220-222可能不需要。一旦从密钥分发服务235获得了秘密密钥，该密钥可被用于解密VHD。

[0063] 在另一实现中，能解密虚拟机的VHD的秘密密钥可被密封到与虚拟机相关联的vTPM。该密封可涉及vTPM的一个或多个寄存器。该寄存器集合可被选择以实施承租人选择的策略。当密钥经由vTPM密封时，该密钥仅可在被用于密封该密钥的寄存器包括在该密钥被密封时它们作出的相同数据的情况下从vTPM获得。

[0064] 此外，vTPM可以以下方式被保护：只有拥有vTPM的正确密钥k的主机才将能够访问它。vTPM可用密钥k来保护，并且KDS可将密钥k在密封团块内发送到主机。密封团块可用这样的方式来构造：TPM将只在所选PCR寄存器集合具有理想值的情况下才解密它。在一个实现中，KDS使用标准化的TMP格式来实现这个，并且主机通过使用TPM的拆封操作来使用TPM解密密钥k。

[0065] 拆封操作可由主机230基于以下描述的密钥分发来执行。如果拆封操作由分发服务235执行，则主机可在被TPM签名的包中将TPM 261所测量的数据传递到密钥分发服务235。如果拆封操作由主机230执行，则主机可使用先前分发的密钥，该先前分发的密钥仅可在主机230处于满足策略的状态中(如被TPM 261测量的)的情况下才在主机230上被拆封。

[0066] 如果所有寄存器都处于正确的状态中(表明主机230处于符合策略的状态中)，则拆封将成功并且主机230将被提供用于解密虚拟机的vTPM的密钥或用于直接解密VHD的密钥。在此时，虚拟机可引导，因为vTPM可用于拆封解密虚拟机的VHD所需要的密钥。如果引导之后vTPM状态是依照承租人的策略的，则将出现解锁。随着虚拟机解锁，其还可基于其当前的vTPM状态来试图作出一证明。该证明允许虚拟机向其他承租人资源说明其符合承租人策略。

[0067] 此时，以下目标已经实现：

[0068] 1.通过由执行虚拟机完成的证明，承租人被保证虚拟机符合承租人设置的虚拟机策略；

[0069] 2.由于对加密虚拟机的VHD的密钥的密封，承租人被保证VHD内容没有被修改；以及

[0070] 3.由于主机TPM以及主机的证明，承租人被保证虚拟机运行在符合针对主机的设置策略的主机上。

[0071] 还为了在运行时期间防止对VM的组件(例如，VHD、设备状态、VM存储器等)的修改，代码完整性策略可被实现在主机上。

[0072] 在一替代实现中，替代于密钥分发服务235执行密封操作，密钥分发服务235可简单地提供用于解密VHD的密钥。例如，主机230可在由TPM签名的包中向密钥分发服务235传递TPM 261所测量的数据，并且密钥分发服务235可通过向主机提供用于解密VHD的密钥来进行响应。

[0073] 在一个实现中，密钥分发服务235可被承租人控制。在另一实现中，密钥分发服务235可被主控者(例如，操作主机230的云操作者)控制。在第一实现中，承租人维持对解密vTPM所需要的密钥(并且通过其，对虚拟机)的完全控制，但可能需要承担维持到主控者的连接以允许虚拟机引导的负担。在第二实现中，承租人可让主控者(例如，主控者的组织的分开的部分)运行密钥分发服务235。在一个实现中，这可被实现，使得主控者的组织中至少两个实体被要求共同操作以便访问承租人vTPM密钥k。

[0074] 由于防止信任VMM 253或其操作人员的情况，在典型实施例中，VMM 253在提供用于解锁被屏蔽的VM 208、209和210的密钥中不具有安全关键角色。但是对于自动化且高效的操作以及启用针对承租人的自服务操作而言，VMM 253能协调(orchestrate)操作是非常有用的。本发明的一些实施例的组合这些要求的一个模式看上去像以下：

[0075] 1.VMM 253以一种传统的方式将访客VM(例如VM 208)部署到适当的主机230，而无需关于部署密钥进行任何安全关键的事物。VMM 253可用正常考虑和动作来执行其正常管理操作，诸如调度、放置的优化和资源分配，而没有归因于VM 208的受保护的性质的显著的改变(一些小的扩展在以下讨论)。VM 208将经加密的vTPM 220以及如针对安全操作所要求的加密的vTPM 220的保护密钥255作为其元数据的一部分来包括，但是所有这个元数据作为标准部署操作的一部分来一起处理，而无需VMM进行专门安全相关处理。

[0076] 2.当主机230检测到这是经屏蔽的VM时(不是所有VM都被屏蔽)，它联系KDS 235来检索用于解锁vTPM 220的密钥。作为这个请求256的一部分，主机包括由主机证明服务(HAS)258提供的证明证书257，该证明证书257示出其是符合服务提供者的策略的有效主机。例如，主机可提供主机证明证书，该证明证书指示主机使用主机的安全子系统来请求证书。KDS 235验证证明证书257满足策略要求。其接着解密vTPM主密钥，该vTPM主密钥用KDS的密钥来加密，并将其进行重新加密为主机的一个或多个公钥，以及将其安全地传送到主机上适当的安全软件。这可以是主机的公钥或主机内部的TEE。主机使用递送的vTPM主密钥来解锁vTPM，并将vTPM作为一服务提供给访客VM，该访客VM可从vTPM检索开始被屏蔽的VM 208的解密过程所需要的密钥。安全基础结构发送确认操作的成功或失败的密码上可信的消息。这些步骤中没有步骤涉及VMM 253。

[0077] 3.在解密VM 208的安全关键过程的结束处，VMM 253用正常部署和配置操作来继续。VMM 253被通知操作的成功或失败，其是针对正常操作的有价值的信息并像所有其他通知那样由VMM 253处理，但是由于VMM 253是不可信的，谨慎的承租人还将确认安全消息的接收。

[0078] 如从本说明书中显而易见的，VMM 253不参与安全关键操作，诸如主机证明和密钥分发。VMM 253提供自动化的协调，但是安全性通过安全基础结构来保护并且不会受到VMM 253的操作的影响。

[0079] 在本发明的一些实施例下，与安全关键功能分隔但与安全关键功能合作的管理和自动化的模式还可被应用到除了部署之外的其他VM操作以及被应用到不应用到VM的操作。其还可被应用来管理VM在其上运行的“结构”、服务器集合、存储、网络和管理系统。

[0080] 模式到其他VM操作的应用

[0081] 在VM 208的生命周期期间，VMM 253协调除了部署之外的许多操作。在具有偶尔特别考虑的情况下，相同的信任关系以及相同的操作和密钥管理的模式跨所有这些场景来应用。

[0082] VM从主机到存储的迁移

[0083] 这个场景是以上描述的部署场景的反向。本发明的一些实施例的组合这些要求的一个模式可被实现为如以下：

[0084] 1.VMM 253作出常规决策并将常规指令发送到主机VM 231来暂停或关闭VM 208。

[0085] 2.主机230在这个操作期间作出保护VM 208所要求的动作。这可包括加密其他VM人工制品(诸如描述VM 208的元数据)和处理器状态以及存储器的内容和虚拟存储器文件，并且相同的密钥传送机制被用于这些其他人工制品。关于这个如何可被实现的一个示例的细节，参见以下题为“虚拟机保证”的章节。

[0086] 3.当这个保护过程完成时，主机230在其所有数据被加密和以及必要密钥被vTPM 220保护(其进而被加密和保护)的情况下来暂停或关闭VM 208，VMM 253用正常存储过程和对所存储的内容的正常管理来进行。例如，VMM 253可使得经屏蔽的VM 208被存储到存储系统250。

[0087] 正如在VM部署过程中那样，VMM 253完全在安全关键操作之外：VMM 253不仅没有参与加密过程和密钥交换，它存储的数据用加密来保护，而且它还没有参与为对VM 208的成功保护进行证明。

[0088] VM到另一主机的迁移

[0089] 现代虚拟化平台支持VM从一个主机到另一个主机的若干形式的迁移：实况迁移维持VM的执行而不发生中断。非实况迁移涉及服务中断，但是具有较不严格的环境要求。这样的迁移可基于虚拟化平台以及存储和网络系统的性质用不同的方式来完成。VMM 253了解能在给定结构中被完成的迁移的形式，并且知晓如何发起和协调这样的动作。对于经屏蔽的VM的迁移，本发明的一些实施例的组合这些要求的一个模式看上去像以下：

[0090] 1.VMM 253作出关于迁移的类型和目的地的常规决策，并接着指令源主机230发起到所选的目标主机259的迁移。

[0091] 2.源主机230参与与KDS 235的安全会话来发起对VM 208及其vTPM 220的加密以及必要的密钥交换，并且目标主机259向KDS 235作出针对用于解锁VM 208的vTPM 220的密钥的安全请求。VHD 208不仅仅负责对VHD 205自身的加密，而且还确保其他VM人工制品(诸如运行中的进程的存储器状态和页文件)，并且相同的密钥传送机制可被用于这些其他人工制品(诸如描述VM的元数据以及处理器状态和存储器的内容以及虚拟存储器文件)，并且相同的密钥传送机制可被用于这些其他人工制品。

[0092] 3.一旦存在密钥同意，主机230和259就用信号通知它们准备好进行迁移，并且VMM 253向主机230和259发送针对要被完成的迁移的类型的常规命令。在一些实施例中，VMM
253向始发主机给出指令，并且该主机负责其余部分，使得VMM不参与迁移的细节－但可复查迁移代码所有者。尽管上述内容暗示了逐步骤的过程，但是在一些迁移技术(诸如实况迁移)中，加密和迁移一起操作，从而递增地加密事物。由此，操作可不被划分为如本文中描述的顺序运行的分开的步骤。例如，操作可交织，使得加密和迁移针对操作的各部分来完成，如由使用本领域的技术人员公知的标准过程的迁移过程所要求的。由此，各种替代技术可被注入以实现在本发明的各实施例的范围内的迁移。

[0093] 如以上，存在对VMM协调的极小改变，并且VMM 253不参与任何安全关键工作流。成功或失败的安全通知由安全基础结构来完成，而VMM 253获得常规通知并以常规方式对它们进行响应。

[0094] 群集内的故障切换

[0095] 迁移的一种特殊情况是群集内的故障切换。存储和管理两者均被配置成允许服务在一个组件故障时快速地将通信量切换到健康的系统。在产业内存在许多已知形式的群集。

[0096] 如果构成应用群集的VM被屏蔽，则当故障切换发生时，密钥在目标系统上可用。如果所有系统是活动的，则密钥在原始部署时被供应到主机，并且在故障切换期间不需要特殊的处理。但是在主动－被动配置中，若干选项可用。例如，将这样的故障切换作为一迁移来对待是可能的，其中目标主机259作出如以上讨论的相同种类的密钥递送请求，但在故障切换时引入活动(诸如密钥分发)可减少可用性和响应性。在一些实现中，密钥与VM使用以上讨论的部署过程一起被供应到群集中所有相关主机(不管是活动的还是不活动的)。这允许在具有或不具有VMM 253涉及的情况下群集管理软件使用正常管理或控制技术来执行故障切换操作，而不对VM保护如何完成产生影响。这种安排以与以上描述的部署和迁移场景中相同的方式来针对VMM 253和群集管理软件两者保护VM。

[0097] 迁移到另一数据中心

[0098] 迁移到另一数据中心可发生，因为承租人想要出于业务或合规性原因或出于业务连续性或灾难恢复的目的移动到其他地方。该过程由VMM 253或其他管理系统以与在常规情况下会发生的方式相同的方式来完成，但是相比于以上的迁移情况，针对从一个数据中心到另一数据中心的安全密钥交换的要求可能更加复杂。

[0099] ·如果两个数据中心共享安全主控服务(诸如HAS 258和KDS 235)，则跨数据中心迁移以与以上的迁移情况中相同的方式来组合管理和安全操作，但是人工产物的物理迁移可使用如针对长距离运输通常采用的其他技术。

[0100] ·如果两个数据中心具有分开的安全主控服务，则两个服务使用受信机制来进行密钥交换。一种方案是在安全主控服务之间建立联盟或其他信任关系以允许它们在一些情况中充分利用产业标准协议直接进行密钥交换。

[0101] ·如果两个安全主控服务不具有信任关系，则承租人或支持服务检索VM208以及其对应的密钥，并将它们以与以下描述的初始VM被传送到数据中心类似的过程传送到目标数据中心。

[0102] 代替关注于迁移是否发生在两个分开的数据中心大楼之间或物理距离是多少，各实施例可关注于源和目标主机是否共享一安全主控服务或是否具有带有建立的信任关系的分开的安全主控服务或是否具有不带有这种信任关系的分开的主控服务。所有这些变体的示例可在单个数据中心内的各部分之间、在单个服务提供者所运行的数据中心之中、在多个服务提供者之中或在承租人和服务提供者之间存在。在所有这些情况下，所示出的描述VMM 253和安全主控服务之间分开但合作关系的本发明的各实施例的模式保持有效，只有密钥交换和物理传送的细节不同。

[0103] 承租人基于私有人工产物来创建被屏蔽的VM

[0104] 承租人可从普通未受保护的人工产物中创建被屏蔽的VM，但是对于承租人而言，能够在私有计算环境内通过以下自始保护人工产物是有用的：经历这个私有计算环境中合适的VM创建过程并使用标准工具(诸如微软BitLocker)来加密VM及其VHD。这些受保护的人工产物接着可使用常规的文件传送机制被传送到服务提供者的数据中心并被存储在VM存储库上，并使用VMM 253作为VM来启动。为了允许被屏蔽的VM被启动，承租人的保护密钥被传送到服务提供者并被供应到KDS 235。在一个实施例中，承租人在帐户供应过程期间或在另一合适的时间使用安全传送被提供服务提供者的KDS公钥。VM保护密钥被存储在vTPM的受保护的存储分层结构内，其进而受到KDS公钥的保护。在传送到服务提供者之后，该被屏蔽的VM包(由此被保护)可被KDS解密并此后使用本文中描述的技术来处理。

[0105] 承租人基于模板来创建被屏蔽的VM

[0106] 在云计算中，服务提供者提供由服务提供者、独立软件供应商(ISV)、系统整合者或其他第三方提供者提供的模板图库是常见的。这样的模板是还未针对承租人的要求被定制以及还未被提供有帐户标识、管理员口令、软件或其他敏感数据的VM的完整或部分定义。这种对系统的一般化及其后续的专门化可使用微软的sysprep工具或其他适当工具组合其他工具(诸如引导管理器)来完成。

[0107] 对于承租人而言，能够从这样的模板中创建被屏蔽的VM是有用的。当这么做时，对于承租人而言能够验证模板的完整性是有用的，诸如验证模板没有被服务提供者工作人员插入恶意软件或会允许对VM的后续攻击的配置所篡改。VHD和其他VM人工产物的完整性可例如通过数字签名被验证，并且承租人可在针对创建被屏蔽的VM的请求中指定用于验证VM组件的完整性的受信方式。

[0108] 在其他场景中，模板可包括秘密(诸如用于连接到外部服务的软件、数据或凭证)，并且这对于通过加密来保护模板是有用的。但是，由于这种加密是使用属于模板的作者的密钥来完成的，虚拟存储设备用特定于VM并因此特定于承租人的密钥来被重新加密(例如，解密并用不同的密钥重新加密)。这种解密以及用不同的密钥重新加密可用其他重新加密场景来替换，诸如使用用于改变密钥的硬件支持而无需完整的解密/重新加密。

[0109] 在确认模板资源和创建被屏蔽的VM或解密并重新加密模板VHD来创建VM VHD的过程中，信息在一个连续流中被处理并且不是在任意时间以未经加密的形式存储。这个过程由在数据中心内的某个系统上操作的安全过程来执行。在一个实施例中，安全过程在虚拟化主机上操作，而在一些实施例中，这可在被屏蔽的VM自身内发生。

[0110] 当从模板创建被屏蔽的VM时，每个VM受到唯一密钥保护是常见的，但是确认和加密或重新加密步骤花费某一时间量并且对于创建大型应用以避免针对每个VM的这种延迟可能是有用的，尤其在响应于增加的负载对VM的自动供应期间。为了针对其他承租人和服务提供者保护VM但避免对于每个VM的延迟，确认和加密或确认和重新加密步骤可在无需模板专门化的情况下被执行以创建用特定于承租人的密钥加密的模板，从而允许从这个模板中创建被屏蔽的VM，而无需针对每个被屏蔽的VM的耗时的密码任务。

[0111] 为了针对服务提供者员工来保护这个VM以及承租人注入到VM内的任何秘密，VMM和安全基础结构之间的关系遵循本发明的各实施例中的其他地方所使用的模式：承租人创建包括用于创建所需的信息的任务定义并通过数字签名、加密或签名和加密的组合来保护这个任务定义，并且这个受保护的任务定义被传送到不能够解密或更改其的VMM 253，并且受保护的任务定义被传送到以本发明的各实施例中的其他地方所使用的方法向KDS 235请求用于解锁任务定义的秘钥的安全过程，并且中央确认和加密或解密和加密任务被安全过程作为不能被VMM 253中断或修改的原子任务来执行。VMM 253以常规方式来在安全创建之前和之后进行其他有用任务，诸如验证承租人的帐户并向其收费、存储被屏蔽的VM、部署VM以及向承租人通知操作的结果。确认任务的完成的消息是可信的，因为其包括以下信息：该信息仅被安全过程知晓并且被安全过程使用证书来数字地签名，该证书植根于服务提供者的私钥中，并由此可防止来自服务提供者的员工进行的篡改。

[0112] 承租人可能想要部署并检索被屏蔽的VM以供在私有云或在另一服务提供者处执行。如果承租人具有带有用于用安全主机服务来保护VM的类似主控结构的数据中心，则如以上描述的数据中心间传送可被使用。如果服务提供者和承租人建立了信任关系，则传送可如以上描述的进行。如果他们没有，则承租人可请求VM用正常方式被加密并且vTPM主密钥被加密为属于承租人的密钥。这允许VM用常规的数据传送机制被传送并被承租人打开。这种方式被实现，其中VM和承租人的公钥之间的关联是安全且防篡改的，以防止攻击者假装是承租人，替换另一公钥和检索vTPM主密钥。若干已知的技术存在用于密码上保护这个关联：承租人的公钥能被包括在被vTPM加密和保护的VM元数据内，并且因此能被KDS或批准的主机访问但不能被攻击者访问；替代地，承租人ID可用这样的方式来保护，并且查找表对KDS可用以从承租人ID中标识承租人的公钥。在一个实现中，VM元数据包括被加密为承租人的公钥的vTPM主公钥，其允许VM使用简单数据传送机制被传送到承租人，而无需KDS或其他安全相关服务的参与。

[0113] 本发明的各实施例以常规传送技术可被VMM或结合其他工具使用、协调的这种方式来分隔管理和安全操作，甚至包括对存储介质的物理传送，同时VM内容和密钥受到安全机制的保护。

[0114] 支持技术

[0115] 用于在操作上实现数个支持活动的各实施例既促进自动化又形成安全基础。本发明的一些实施例还包括若干支持活动来在针对有效保护所要求的有纪律的过程中协助服务提供者和承租人。

[0116] 主机的供应、配置和证明

[0117] VM的安全取决于主机的完整性，其应当仅运行不具有恶意软件(诸如“根工具包”)且不具有带有漏洞的旧版本的软件的正确软件，并且应具有正确的配置设置和正确的策略。这些主机被典型地供应有和配置有常规的结构管理系统(诸如FM 254)，并且在本发明的一些实施例的威胁模型下，出于如针对VMM 253所讨论的同样理由，FM 254不是受信计算基础的一部分：FM 254是大型且复杂的系统，并且承租人不想要将信任扩展到操作FM 254的员工。本发明的一些实施例不要求用特殊的工具或技术来代替现有的FM 254—这样的改变对于基于现有工具具有现有过程的服务提供者的IT员工而言是费力的，并且在任何情况下，其对于防止对现有工具和接口的过多使用会是个挑战。由此，本发明的一些实施例不是基于尝试防止错误配置或损害的。相反，这些实施例基于检测被错误配置或损害的主机、基于排除这种被错误配置或损害的主机参与主控结构以及基于确认成功和未被损害的操作。

[0118] 当主机230接收被屏蔽的VM 208并向KDS 235作出请求256来检索vTPM密钥时，其包括用于表明其符合某些策略的证明证书257。例如，证明证书可指示主机230是该结构的已知成员，并且其运行正确的软件以及正确的安全相关策略正在实行。系统一般不可靠地对其自己的健康进行证明。为了获得这个证明证书，主机230向主机证明服务(HAS)作出请求260。这个请求可包括与主机的完整性方面的信任有关的若干信息片段。在一个实现中，该请求包括信息，诸如以下中的一个或多个：

[0119] ·从主机230的物理受信平台模块(TPM)261中得到的密钥，诸如背书秘钥。这个密钥与已知服务器密钥列表进行比较，该列表在服务器251被递送到数据中心时被供应。该服务器密钥列表被提供在清单中，该清单与服务器递送并行地被安全地递送。用于标识的替代方法是可能的。

[0120] ·对软件的测量被包括在引导过程(如由统一可扩展固件接口(UEFI)模块262提供)中或其他引导软件中并被TPM 261签名。

[0121] ·标识该请求源自主机的安全软件子系统的证书。用于实现这样的安全子系统的若干方式对于本领域的人员而言是已知的。在一个实施例中，这一子系统可以被实现为在主机VM的内核中运行的函数。在另一实现中，它可以在管理程序中运行。在其他实施例中，其可以被实现为由管理程序使用处理器的存储器映射能力所实施的单独地址空间。在其他实施例中，其可被实现为由处理器实施的单独执行区域(诸如ARM体系结构的TrustZone(信任区)或Intel(英特尔)描绘的新兴的SGX能力)。这些不同的实现可提供相似的功能，诸如用于进行密码操作、存储凭证、确认代码或数据的完整性以及以类似于vTPM的方式来保护秘密的能力。它们可在它们所提供的安全的强度方面不同。本发明的各实施例可在各个实现上等价地操作，因为本发明的各实施例取决于功能，而非安全强度。

[0122] ·主机的代码完整性策略的签名证书，包括管理程序实施的代码完整性(HCVI)263和AppLocker(这些针对主机的侵入来保护VM)。替代地，各实施例可识别其他不具有主机VM的虚拟化安排。例如，HVCI和AppLocker(来自华盛顿州雷蒙德市微软公司)是针对主机的代码完整性确认的示例。可以替代地使用其他替换方式。

[0123] ·用于允许HAS 258建立与主机的安全通信的安全软件组件的公钥。

[0124] 在其他实现或配置中，该信息中的一些可被忽略，例如，在企业深信它们的数据中心是安全的并具有适当的用于防止损害的强劲过程的情况下。实际上，所有这些可被忽略，并且本发明的各实施例可在没有证明步骤的情况下操作。在特定数据中心中证明的要求由证明策略所定义。

[0125] 在其他实施例中，其他信息可被添加以支持其他策略，诸如关于主机的地理位置符合数据主权条例的可验证证据、或关于主机在数据中心内的锁笼内的放置的可验证证据、或关于组件在物理服务器和它们的供应链出处中的可验证标识、或关于主机连接到安全网络的可验证确认。行业和政府组织实现用于以密码上稳健的方式来提供这样的信息的技术，并且如果这样的信息在主机上可用，则其可被用于证明步骤中。替代地，服务提供者可作出宣称这种类型的信息的声明，该声明用服务提供者的公共证书数字地签名、或用在密码上基于TPM密钥的证书签名或两者，这样的声明可能即使不是技术上强劲的，但对合规性而言是足够的。

[0126] HAS 258将这个信息与证明策略264中的规范进行比较，并且如果匹配策略264，则返回被HAS 258签名的证明证书257。如果主机信息不符合策略264，并且由此如果主机被错误配置或损害，则证明服务检测这个情况并拒绝提供证明证书257，这表明主机230不接收用于解锁vTPM 230以及由此VM 208的密钥255。

[0127] 由此，本发明的各实施例允许标准FM工具来供应和配置主机。主机的完整性被HAS 258监视并被证明证书257确认。该证明证书257被KDS 235使用以实现在VMM 253的控制下的对被屏蔽的VM的部署和迁移，并且VMM 253和FM 254两者均被通知成功和失败并根据标准管理策略和规程来处理这些结果，例如通过将VM 208放置在另一符合策略264的主机上来对主机证明失败进行响应。

[0128] FM 254和VMM 253可在发现证明失败和可能的损害之际采取用于隔离或修复主机230的其他动作。例如，服务提供者可具有用于决定如何处理被预期通过证明但之后没能证明的已知主机的策略：一种谨慎的方式会是“隔离”主机并拒绝允许其连接到网络或主控结构，更实际的方式可能是将其从主控中排除但将其留在网络中以用于故障排除和迁移。

[0129] 由此，FM 254和安全主控服务之间责任的分隔可与VMM 253和安全主控服务之间的分隔相同的方式来进行，具有类似的益处：考虑到成本效益、速度和可靠性，FM 254提供结构管理的自动化和协调，但是结构的安全关键方面由安全主控服务提供并且不被暴露给FM 254或有权操作的员工。

[0130] 对VMM的用于完全支持被屏蔽的VM的改变

[0131] VMM 253的操作不需要从先前存在的VMM的显著改变来支持对被屏蔽的VM的操作，但是较小的改变可被引入以协助承租人和服务提供者进行的使用。例如，安全主控过程引入新类型的故障的可能性，诸如主机失败证明以及作为后果的对该主机失败的VM部署或迁移。如针对其他故障模式所进行的，VMM 253应当理解这样的故障消息并应当作出纠正动作，诸如寻找另一主机以供部署、向服务提供者员工报告故障以用于修复、如果自动修复是不可能的或如果存在服务降级或不能满足服务等级协议则向承租人通知该故障、将事件包括在报告中并将发生故障的主机从将来的动作中排除直到被修复。

[0132] VMM 253还可在用户界面中以及编程界面中呈现用于启用在VM上传、创建和检索工作流方面的保护的选项。并且，VMM 253可提供用于允许服务提供者附加被屏蔽的VM的不同价格以及整合类似商业事务的设施。

[0133] 在本发明的一些实施例中，这些有用功能不是安全关键的，因为对VM的保护依赖于安全主控基础结构而非不受信的VMM。如果VMM或其数据库被损害，则该数据中心中的操作效率和服务等级可受损，但是VM的安全性不被损害。

[0134] 被屏蔽的VM在能够实现安全性的主机上的放置

[0135] 在典型的数据中心中，可能存在若干配备有针对安全操作所需要的硬件和操作系统的主机，以及共存有若干不具有这种能力的常规主机。随着数据中心经历硬件更新周期，这种混合环境可存在数年。最初，能够实现安全性的主机可以是稀有资源。

[0136] 在类似的过渡期期间，一些VM可被屏蔽而其他一些VM没有被屏蔽，因为它们的工作负载不认为足够敏感来值得对保护的努力或花费，或因为承租人还未经历用于保护所有工作负载的过程或策略过渡。

[0137] 在这种异构主机和异构工作负载的环境下，VMM 253需要管理受保护的工作负载到能够实现安全性的主机(诸如主机230)上的放置，以避免其中VM 208将不能启动的注定失败的放置。此外，未受保护的工作负载可被择优地放置在常规主机上，以最优化服务提供者的资源利用率以及允许服务提供者按需针对受保护的执行收取更高的价钱。典型的VMM将广泛的资源要求与主机的特征进行匹配并使用策略来引导针对最优资源利用率或其他商业目标的放置。将保护能力添加到该特征列表并将其包括在放置决策制定中是直观的。VMM 253将这些属性维护在其在数据中心中的主机的清单中。实践中，这将涉及用于标识具有这种能力的主机的发现机制。该清单应当与HAS 258链接：一主机可被知晓为具有硬件能力，但是如果其在任意点都没能通过证明过程，则也许因为它已经被损害，其暂时地从能够实现保护的主机列表中移除。

[0138] 但是，由于VMM 253和其操作人员不被信任，该放置以保留保护的方式来完成，尽管存在具有管理员特权的服务提供者工作人员可能具有更改VMM 253中的主机清单数据库或损害放置决策制定算法的能力的可能性。自动化的清单管理和放置算法在数据中心中的可靠且高效的操作中扮演重要角色，但是不在工作负载保护中起作用。从以上描述中应当明显看到这被解决了：如果VMM 253被损害并被诱导将被屏蔽的VM部署到无效主机，则该主机将不能参与与KDS的密钥分发过程并且将不能够解锁和引导被屏蔽的VM，所以没有承租人数据被损害。

[0139] 对主机中的策略改变的响应

[0140] 在各个时间，主机上的安全策略(诸如代码完整性(CI)确认策略(有时本文中称为管理程序实施的代码完整性(HVCI)策略))需要改变。例如，考虑如被FM 254管理的软件更新：服务提供者可能已经被通知驱动程序的新版本已经被发布，因为先前版本被发现包括安全漏洞。在这种情况下，该新版本应当被添加到允许软件列表并且先前版本应当被添加到不允许软件列表。在这些情况下，CI策略在对驱动程序的更新的同时被更新可能是重要的：如果驱动程序在策略被更新之前首先被更新，则驱动程序将不被允许执行并且系统可发生故障。如果这个过程不被正确地管理，则广泛应用的软件更新可使整个数据中心不能运转。出于这个原因，软件和策略更新被协调。在一个实现中，策略更新被打包并作为软件更新(“补丁”)被分发，采用所定义的前导关系使得常规补丁软件将在软件更新之前部署策略更新，并最终触发使得策略264和驱动程序更新生效所需的重新引导。通过依赖现有的补丁软件，FM可充分利用现有自动化，诸如跨某一范围的主机来协调“滚动更新”以避免广泛分布的服务中断，或在更新和重新引导每个主机之前VM到另一主机的实况迁移。

[0141] 但是，还存在一个要被协调的改变：HAS 258确认正确的CI策略正在实行，所以再次，如果证明策略264不被更新来识别并允许经更新的CI策略，则服务器251将不通过证明并将不被允许参与结构。该过程开始于基于接收到的信息来定义补丁和经更新的CI策略。接着，新的CI策略被添加到证明策略264。接着，补丁以某个受控次序被滚出到服务器。并且最终，当所有服务器已经被更新并且HAS 258不再接收具有旧的CI策略的证明请求时，旧的CI策略可从证明策略264中移除。这个过程是在服务提供者IT人员的控制下，该人员批准更新并调度它们的应用。该技术支持有序且安全的过程，但不消除针对该人员的管理控制的要求。

[0142] 在本发明的一些实施例中，使用常规FM工具对这些改变的管理与数据中心的被安全基础结构所确保的安全性分隔开。合作对于平滑且高效的操作是有价值的，但是管理系统的损害是不将VM暴露给损害。

[0143] 对安全相关状态和故障的报告

[0144] 在本发明的一些实施例中，VMM 253完全在安全关键操作之外：VMM 253不仅不参与加密过程和密钥交换。其还不参与对被屏蔽的VM 208的成功保护的证明。受保护的部署可出于任意数量的安全相关原因而失败：主机230可能没能通过证明，因为它已经被损害或因为策略264在初始部署后已经改变，HAS258或KDS 235可能已经被损害或已经发生故障。VMM 253将接收关于这个故障的通知并将报告它，就像它处理常规的非安全相关故障那样。
但是，VMM 253不被信任来报告安全相关故障，因为恶意VMM管理员可在即使保护因为损害发生了故障的情况下伪造成功消息。所以，尽管VMM 253作出对每日操作有用的尽最大努力的报告，但是安全主控服务依然发送故障事件通知，该故障事件通知被发送到可信的事件报告系统。这个确认消息在密码上是稳健的并且被主机230的安全基础结构和KDS 235签名。

[0145] 特权在若干IT工作人员之间的分隔

[0146] 尽管本发明的一些实施例将一般管理系统(VMM 253和FM 254)从数据中心的安全性方面的任意角色中移除，但是HAS 258和KDS 235在一些实施例中转而具有重要角色。具体而言，在一些示出的示例中，HAS 258是主机中信任的起源：如果证明策略被损害以允许恶意软件在主机上，则整个安全模型可发生故障。

[0147] 由此，HAS 258和KDS 235可针对损害被保护。由于威胁中可被解决的一个是能够访问主机、VMM 253或FM 254的恶意管理员的威胁，所以针对HAS 258和KDS 235的管理员特权保持与一般主机或结构管理员的管理员特权分开。具体而言，HAS 258和KDS 235不被VMM 253或FM 254管理。还推荐它们不加入到与主机相同的域或森林。

[0148] 这种特权的分隔帮助确保成功的攻击需要常规管理员与负责证明策略的特殊、高特权管理员之间的串通。

[0149] 因此，整个系统架构并且具体而言HAS 258和KDS 235可被构造，使得它们在一方面的HAS 258和KDS 235以及另一方面的主机、FM 254和VMM 253之间不需要任意公共管理。它们不需要在相同的域或森林中。

[0150] 尽管本发明的一些实施例不需要确保这些特权保持分隔，而是将其留给服务提供者的过程和条例，但是各实施例可被特别地构造以允许特权的这种分隔。

[0151] 扩展

[0152] 本发明的各实施例可被扩展到提供附加的能力或满足附加的保护或合规性要求。

[0153] 特定于承租人的KDS主密钥

[0154] 在一个实现中，KDS 235用属于KDS 235的主密钥来加密vTPM密钥来保护它们。但是，vTPM密钥也可用每个承租人的单独主密钥来加密，以增强保护和隔离或满足管理上的合规性要求。KDS 235的主密钥可受到TPM的保护，但是将特定于承租人的密钥存储在硬件安全模块(HSM)中也是理想的，因为这提供了承租人的环境和服务提供者的HSM之间密钥的安全交换，以及针对主密钥的承租人发起的移除以及其他益处。

[0155] 如果结构使用或支持特定于承租人的主密钥，则本发明的一些实施例适应并支持这种情况，从而提供管理自动化与安全关键功能的隔离。在VMM 253、FM 254、HAS 258、KDS 235或主机之中不需要交互方面的显著改变。为了操作便利性，VMM 253应当提供小的操作支持功能(诸如在报告和通知中反映承租人标识)并应当识别和处理附加故障情况(诸如错误匹配的承租人ID)。

[0156] 在各实施例中，以上描述的VM操作使用一个显著改变来支持对HSM的使用：VM 208及其元数据包括承租人ID，其以未经加密的形式对主机230可用，所以主机可在其发送到KDS 235的密钥发布请求中包括承租人ID。在至少一些实施例中，VM 208和承租人ID之间的这种关联使得能够实现管理自动化和/或使得能够实现便利性特征(诸如用户界面和报告)，但是不是安全关键的并且不必是防篡改的，因为如果假的承租人ID被替换，则错误的加密密钥被提供并且vTPM 220不能被解密。

[0157] 承租人持有的密钥

[0158] 该系统的各实施例可被设置，使得承租人负责运行KDS 235(也许在他们自己的数据中心中)，并且使得服务提供者的安全主控服务能够在每次它们需要用于执行VM操作的密钥时就联系承租人。在另一实现中，承租人可与第三方提供者建立合同以代表承租人来操作KDS 235，从而与主控服务提供者隔离。

[0159] 本发明的各实施例可被容易地扩展以支持这样的场景。KDS 235将使用以对VM 208明确的方式存储的承租人ID，并在查找表中查找网络地址。再次，VM 208和承租人ID之间的这种关联使得能够实现管理自动化，使得能够实现便利性特征(诸如用户界面和报告)，但是不必是安全关键的：如果攻击者替换无效承租人ID，则KDS 235将联系错误的承租人KDS并将检索无效的密钥或根本检索不到任何事物。

[0160] 即使在从承租人检索到vTPM密钥255时，对验证主机的完整性的需要依然保留，其可使用HAS 258来完成。尽管承租人提供HAS 258来确认主机配置的某些方面是可能的，但是主机配置的其他方面(诸如已知服务器的标识密钥)对承租人不可用。因此，一个实现使用两个步骤：第一个步骤是，主机230、HAS 258和KDS 235之间的安全会话如本文中描述的进行以确认主机230的健康并发布解锁VM 208所要求的第一密钥，并且第二个步骤是，KDS 235或主机230联系承租人的服务来检索完整密钥，也许包括证明信息。在对服务提供者的以及承租人的密钥两者的递送之际，VM可被解密。

[0161] 在这样的实现中对以下问题的考虑可被纳入考虑：

[0162] ·地理上远程的请求相比于以上描述的本地操作而言更加容易出错：可能存在断网、承租人的服务可能被关闭或建立安全会话所需的安全密钥和证书可能已经期满。为了实践上有用，这样的远程密钥检索提供故障排除工具。

[0163] ·承租人持有的密钥的目的是承租人可在适当时确认请求和拒绝它们。这可手动地或使用自动化的策略来完成。这表明有效请求包括用于允许这样的决策被作出的关于操作的充足元数据，该元数据被服务提供者的安全主控服务在密码上签名。该元数据还可包括证明证书以及关于参与证明请求的主机的信息。

[0164] KDS中的复杂策略

[0165] 当作出发布vTPM密钥255的决策时，KDS 235仅查看主机的证明证书257：如果主机是有效且健康的，则其发布密钥。

[0166] 本发明的各实施例可被容易地扩展来实现更复杂的策略以确定密钥是否应当被发布，该更复杂的策略考虑关于请求256、VM 208和承租人的其他信息。例如，该系统支持将VM转移到服务提供者与其具有信任关系的另一设施。但是，承租人可能想要限制这样的移动，例如，出于国家数据主权或其他管理上合规性的理由或出于一般的注意。这样的策略可通过自动策略系统被实现或可涉及人为批准工作流。

[0167] KDS 235可支持这样的策略，从而仅要求关于VM操作的充足元数据与请求256一起提供，如针对承租人持有的密钥的情况所讨论的——实际上，目标和实现是基本相同的。但是，由于KDS 235在服务提供者的多承租人设施处操作，策略的完整性受到密码强度的保护。所推荐的实现是使得承租人或服务提供者的具有特权的管理员能够对策略签名，并且KDS 235针对承租人的或服务提供者的已知证书来验证签名证书。

[0168] VMM 253可包括扩展以允许承租人输入策略，并在VM操作不被策略允许时呈现故障消息。

[0169] 到其他场景的一般化

[0170] 以上描述关注用受到经加密的vTPM保护的密钥在被屏蔽的VM上进行安全操作。但是，本发明的各实施例可被应用在其他场景中，具有将使用标准工具的管理自动化与使用安全基础结构的安全保证组合的相同益处。

[0171] 可能需要秘密的安全传送的其他事物

[0172] 存在其他系统，这些其他系统使用加密或安全通信并且需要以不容易受到基础结构或管理系统的损害或恶意员工的影响的方式的对密钥、证书或其他秘密的安全传送。

[0173] 例如，在一些感兴趣的领域(诸如分布式应用服务)内，承租人可能想要使用IPsec或其他技术来保护网络通信。这些技术需要密钥到组件系统的传送。存在多种用于实现这个的方式，但是用常规技术来管理这些密钥的安全传送是困难或麻烦的，尤其是在其中应用服务的范围和配置例如响应于通信量负载的改变而频繁地改变的虚拟化的环境中。并且，使用类似VMM 253之类的管理工具来自动化网络的配置和密钥的分发将系统暴露给由恶意管理员进行的损害。本发明的各实施例使用vTPM来保护VM加密密钥可被一般化到保护任意种类的密钥或其他秘密，其允许使用本发明的各实施例来安全地自动化这种秘密的分发。

[0174] 到这种场景的扩展的示例元素是(a)要求密钥、证书或其他秘密到分布式系统中的组件的安全递送的机制，(b)具有类似于HAS 258和KDS 235的功能的功能的安全服务，(c)具有类似于VMM 253的功能的管理自动化系统，以及(d)它们之间遵循以上示出的模式的协作，其中管理系统协调过程但不涉及在安全关键操作中。

[0175] 需要对数据的经确认的或秘密传送的其他场景

[0176] 类似地，感兴趣的领域(诸如分布式应用)内的系统需要对配置、策略或商业数据的安全递送是常见的。在这种情况下“安全”可意味着信息是秘密的、免受泄露、其完整性被确认或以上的任意组合。在这些情况中的任一种下，密码技术是可应用的。

[0177] 例如，一服务内的若干系统可能需要被供应秘密凭证来许可对不管是承租人所拥有的还是第三方(诸如金融机构)所拥有的外部服务的访问。在这种情况下，配置数据被保持为私有。

[0178] 在另一示例中，一服务中的系统需要被配置有对范围和通信量方面的限制以针对过载来保护它们自身和其他组件，限制花费，防止系统过载或阻止服务拒绝攻击。在这些情况下，该信息需要完整性确认以防止损害，但不是机密性(虽然谨慎的IT员工可能偏好也将限制保持为秘密的)。

[0179] 在另一示例中，商业服务中的系统可被供应价格列表和目录数据。这些通常出于商业原因被考虑为是秘密的，但是它们的完整性也被保护，因为被损害的价格列表可能被用于欺诈性交易。在许多系统中，这样的数据被保持在集中式数据库中，其中安全管理是直接的，但是在一些分布式体系结构中，这样的敏感数据可被广泛地分布，从而产生安全管理挑战。

[0180] 这样的配置数据可采取多种形式，诸如具有一些专用格式的二进制文件，XML文件或JSON文件。不管格式，它们的秘密性和完整性可使用密码技术来保护，并且使用以上描述的模式来保护和分发的密钥。

[0181] 再次，标准管理系统可被用于自动化这种配置或策略数据的递送，但是如以上讨论的，这将它们暴露给来自结构或结构管理员工的损害。

[0182] 到这种场景的扩展的元素是(a)使用密码技术来在递送到分布式系统中的组件期间确认或保持机密信息的机制，(b)具有类似于HAS 258和KDS 235的功能的功能的安全服务，(c)具有类似于VMM 253的功能的管理自动化系统，以及(d)它们之间遵循以上示出的模式的协作，其中管理系统协调过程但不涉及在安全关键操作中。

[0183] 对除了VM之外的其他容器的保护

[0184] VM不是用于计算的仅有的容器。其他容器被增加地使用，通常小于VM并被包括在VM中。这种小的容器通常被用于例如网站的低花费主控。它们可提供与其他容器的较弱的机密性或资源隔离，但是这可以是低花费的有吸引力的折衷。

[0185] 另一示例是远程桌面服务(也称为终端服务)，其中若干个用户会话被主控在一个OS环境内，其中若干个用户会话中的每个用户会话在一个虚拟容器内具有其自己的数据存储，相当于常规计算机上的My Documents(我的文档)文件夹。

[0186] 另一示例是文件或存储服务，该文件或存储服务包括来自多个承租人的、在分组(可被称为“存储帐户”)中被安排和管理的信息。

[0187] 另一示例是数据库服务，该数据库服务包括来自多个承租人的、在被称为数据库的容器中被安排和管理的信息。

[0188] 诸如这些之类的服务通常被部署在具有多个服务器的分布式的、“向外扩展”的配置中，通常是VM在管理基础结构的控制下对处理负载进行合作。

[0189] 在这种容器中的信息可值得如以上讨论的VM的相同种类的保护。本发明的各实施例可以与针对被屏蔽的VM相同的方式被应用。VMM 253的角色由等效管理系统扮演，该等效管理系统部署和管理轻量容器，诸如应用主控系统中的任务管理器、RDS的“代理”或数据库的分布式数据库管理系统，并且如在VMM253的情况中那样，在许多情况下，容器管理器及其操作员工不应当被信任(诸如，该容器管理器以及容器主控不被约束到单个主机VM，但是可以是并可能将跨大量的VM分布)。主机230在VM情况中的角色由机器实例(即物理机器和/或VM)扮演，其可如在VM情况下那样参与与KDS 235的相同种类的安全交换，但是证明的技术细节可以是不同的，因为在这个情况下的“主机”不直接从物理TPM或UEFI但从VM的完整性中导出其完整性。当将本发明的各实施例应用到这样的轻量容器时，密钥管理系统可以不是vTPM，因为在当前实践中，机器实例可仅具有一个TPM，无论是虚拟的还是不是虚拟的。类似的保护机制可被定义来保护每个容器的密钥，进而通过访客OS vTPM来保护其信息。并且，加密技术可不是类似微软的BitLocker的整卷加密，而是针对文件集合或针对另一容器(类似RDS情况下的My Documents文件夹或数据库服务器情况下的数据库)被应用在文件级别处的更细粒度的加密技术。保护机制的细节取决于特定环境。本文中阐述的模式保持有效，其中管理系统提供自动化而不参与安全关键工作，并且安全主控服务提供保证，并且针对容器的“受信计算基础”通过访客的VSM 265引入到主机265的VSM、到硬件功能。

[0190] 到这种场景的扩展的元素是(a)要求密钥、证书或其他秘密到分布式系统中的组件的安全分发的用于保护这种容器中的信息的机制，(b)具有类似于HAS 258和KDS 235的功能的功能的安全服务，(c)具有类似于VMM 253的功能的管理自动化系统，以及(d)它们之间遵循以上示出的模式的协作，其中管理系统协调过程但不涉及在安全关键操作中。

[0191] VSM

[0192] 本文讨论针对虚拟机的虚拟安全模式(VSM)。管理程序实现虚拟安全模式，该虚拟安全模式使得多个不同的虚拟信任等级对虚拟机的虚拟处理器可用。不同存储器访问保护(如读、写、和/或执行存储器的能力)可针对每个虚拟信任等级与存储器的不同部分(例如存储器页)相关联。虚拟信任等级被组织为分层结构，其中更高等级的虚拟信任等级比更低的虚拟信任等级具有更多特权，且运行在更高虚拟信任等级中的程序能够改变更低虚拟信任等级的存储器访问保护。虚拟信任等级的数量可以变化，且可针对不同虚拟机以及针对同一虚拟机中的不同虚拟处理器变化。

[0193] 图3是例示出根据一个或多个实施例的实现本文所讨论的技术的示例计算设备300的框图。计算设备300可以是各种各样不同类型的设备中的任何设备。例如，计算设备
300可以是台式计算机、服务器计算机、膝上型或上网本计算机、平板或笔记本计算机、移动站、娱乐设备、通信上耦合到显示设备的机顶盒、电视机或其他显示设备、蜂窝式或其他无线电话、游戏控制台、车载计算机、可穿戴计算机等等。

[0194] 计算设备300包括管理程序302(也称为管理程序)以及一个或多个组件304。管理程序302管理对由组件304所提供的功能的访问。替代地，管理程序302可运行在主机操作系统(未示出)上，在该情况下主机操作系统管理对由组件304所提供的功能的访问。

[0195] 组件304可以是各种各样的不同处理器组件、输入/输出(I/O)组件、和/或其他组件或设备。例如，组件304可包括一个或多个处理器或处理器核心、一个或多个存储器组件(如易失性和/或非易失性存储器)、一个或多个存储设备(如光盘和/或磁盘、闪存驱动器)、一个或多个通信组件(如有线和/或无线网络适配器)、它们的组合等等。尽管被例示为计算设备300的一部分，但是组件304中的一个或多个(如一个或多个存储设备)可被实现在计算设备300的外部。运行在计算设备300上的包括管理程序502在内的各种组件或模块可直接地和/或经由其他组件或模块间接地访问由组件304所提供的该功能。

[0196] 管理程序302允许虚拟机306在计算设备300上运行。单个虚拟机306被例示在计算设备300中，尽管另选地多个虚拟机可在计算设备300上运行。虚拟机指的是物理计算设备(或其他机器或系统)的软件实现，该软件实现能够类似于物理计算设备运行程序。虚拟机包括类似于组件304(但却是组件304的软件实现)的一个或多个虚拟组件。操作系统以及其他应用可使用虚拟组件就好像它们在使用组件304时那样来执行，包括在虚拟处理器或虚拟处理器核心上运行、访问虚拟存储器等等。虚拟机306中执行的操作系统和其他应用不需要知道且通常不知道它们正在虚拟机中执行。

[0197] 虚拟机306包括操作系统312、一个或多个应用314、以及一个或多个虚拟组件316。操作系统312在作为组件316中的一个或多个组件而被包括在内的一个或多个虚拟处理器或处理器核心上运行或执行，并管理应用314的执行。

[0198] 管理程序302包括虚拟机(VM)控制模块322和虚拟安全模式(VSM)模块324。虚拟机控制模块322管理虚拟机组件316到组件304的映射，包括对虚拟处理器或处理器核心的调度以在物理处理器或处理器核心上执行。虚拟安全模式模块324管理虚拟机306的虚拟安全模式，从而为虚拟组件316提供不同的虚拟信任等级，如下面更详细地讨论的。虚拟信任等级是虚拟处理器的执行环境，且每个虚拟处理器可独立于任何其它虚拟处理器进入或退出虚拟信任等级。尽管被例示为两个分开的模块，但是应注意模块322和324的功能可被组合成单个模块(如虚拟安全模式模块324的功能可被包括在VM控制模块322中)。

[0199] 当针对虚拟机306启用虚拟安全模式时，虚拟安全模式模块324使得多个不同虚拟信任等级(VTL)对虚拟机306的虚拟处理器(一个或多个虚拟组件316)可用。虚拟安全模式可按不同方式被启用或禁用，诸如响应于来自运行在虚拟处理器上的程序(例如，虚拟安全模式加载程序)的请求、响应于管理程序302的配置设置、响应于计算设备300的管理员或用户提供的输入等等。计算设备300可任选地包括多个虚拟机，且可独立地针对不同的虚拟机器启用或禁用虚拟安全模式。从而，在任何给定时间，可针对计算设备300的一个或多个虚拟机启用虚拟安全模式，而针对计算设备300的一个或多个其它虚拟机禁用虚拟安全模式。

[0200] 管理程序302提供一种机制，借助该机制，操作系统312能够检测对虚拟安全模式的支持的存在，以及关于虚拟安全模式的其它信息，诸如所支持的虚拟信任等级的数量。作为示例，管理程序302可经由可被操作系统312读取的虚拟寄存器(例如，经由CPUID叶)来报告对虚拟安全模式的支持的存在以及虚拟信任等级的数量。

[0201] 操作系统312和管理程序302管理由多个块或部分(称为存储器页(或简称为页))组成的存储器的存储和访问。存储器可以是例如任何类型的CPU(中央处理单元)可寻址的存储器，诸如易失性存储器(如RAM)或非易失性存储器(如闪存)。不同程序可被分配存储器页，且这些程序可以是应用314、操作系统312的程序、或其他组件或模块。

[0202] 操作系统312和管理程序302可允许一程序对存储器页的不同类型的访问，诸如读取访问、写入访问、以及执行访问。如果读取访问(也称为读取权限)给予一存储器页，则该存储器页的内容就允许被读取(例如由特定的一个或多个程序)。如果写入访问(也称为写入权限)给予一存储器页，则内容就允许被写入该存储器页(例如由特定的一个或多个程序)。如果执行访问(也称为执行权限)给予一存储器页，则存储在该存储器页中(也称为存储在该存储器页上)的代码就允许被执行。

[0203] 计算设备300采用虚拟存储器，其是被映射到另一地址空间(如物理存储器)的地址空间。应用被指派了虚拟存储器空间，在该虚拟存储器空间中应用代码被执行且数据被存储。存储器管理器(例如处理器的)管理虚拟存储器空间中的虚拟存储器地址到另一存储器空间中的地址的映射。当将虚拟存储器地址从虚拟存储器地址空间映射到另一存储器空间时，执行地址转换。地址转换表被用于执行该映射，且可被充分利用来实现本文所讨论的技术。

[0204] 图4示出根据一个或多个实施例的多个虚拟信任等级的示例。虚拟处理器402(其可以是图3的虚拟组件316)可在任何数量(x个)的不同虚拟信任等级404(0),…,404(x)中运行。虚拟信任等级404被包括为图3的虚拟安全模式模块324所提供的虚拟安全模式的一部分。在一个或多个实施例中，虚拟处理器402可在两个不同虚拟信任等级中运行，它们被称为正常模式(例如，VTL0)和安全模式(例如，VTL 1)。

[0205] 每个虚拟信任等级具有与其相关联的存储器访问保护集合406。不同的虚拟信任等级可具有不同的访问保护集合，且虚拟信任等级的访问保护集合可被用来在该虚拟处理器在该虚拟信任等级中运行时限制什么存储器可被访问和/或该存储器可如何被访问。

[0206] 每个虚拟信任等级还具有与其相关联的虚拟处理器状态408。虚拟处理器状态是指虚拟处理器402的各种不同的寄存器设置、配置值等等。针对不同虚拟信任等级维护独立的虚拟处理器状态408，从而阻止一个虚拟信任等级访问另一虚拟信任等级的处理器状态。尽管某一虚拟处理器状态是针对不同虚拟信任等级独立维护的(也被称为私有处理器状态)，然而其它处理器状态(也被称为共享处理器状态)可跨多个虚拟信任等级共享，如下面更详细地讨论的。

[0207] 每个虚拟信任等级还具有与其相关联的中断子系统410。中断子系统指代用于管理虚拟处理器402的中断的各个不同的模块、程序、设置等。针对不同虚拟信任等级维护独立的中断子系统410，从而允许在一个虚拟信任等级安全地管理中断同时阻止运行在另一虚拟信任等级(例如，较低的虚拟信任等级，如下面更详细地讨论的)的程序生成意外中断或掩蔽中断。

[0208] 虚拟信任等级被组织为层次结构，其中更高等级的虚拟信任等级比更低的虚拟信任等级具有更多特权，且更低虚拟信任等级比更高虚拟信任等级具有更少特权。运行在比另一虚拟信任等级具有更多特权的虚拟信任等级中操作的虚拟处理器402上的程序可限制在该另一虚拟信任等级中操作的程序或设备对存储器位置的访问。运行在虚拟处理器402上的程序还可任选地改变针对虚拟处理器402正在其中运行的虚拟信任等级的存储器访问保护。然而，在比另一虚拟信任等级具有更少特权的虚拟信任等级中操作的虚拟处理器402上运行的程序不能限制在该另一虚拟信任等级中操作的程序或设备对存储器位置的访问。在一个或多个实施例中，用整数值(例如，0、1、2等)来标记虚拟信任等级，其中具有更大整数值的虚拟信任等级是比具有更小整数值的虚拟信任等级更高等级的虚拟信任等级。替换地，具有更小整数值的虚拟信任等级可以是比具有更大整数值的虚拟信任等级更高等级的虚拟信任等级，或者可使用其它标记技术(例如字母、其它字符或符号等等)。

[0209] 在一个或多个实施例中，在每页(每存储器页)的基础上实现存储器访问保护。每个存储器页具有相关联的存储器访问保护，且针对一存储器页的存储器访问保护可以与其它存储器页的存储器访问保护独立地改变。存储器访问保护也独立于特定页或连贯地址范围具有相同存储器访问保护的任何要求做出。尽管本文参考了在每页基础上实现的存储器访问保护，然而应当注意，存储器访问保护可替换地在其它存储器地址组或存储器地址块中实现，诸如存储器页的部分、多个存储器页、地址范围等等。

[0210] 针对一虚拟信任等级的存储器访问保护可按各种不同方式改变。在一个或多个实施例中，虚拟安全模式模块324展现接口(例如函数调用)，该接口由运行在虚拟处理器402上的程序调用以改变针对一虚拟信任等级的存储器访问保护，从而标识要被改变的存储器访问保护。响应于接口被调用，虚拟安全模块324根据请求改变存储器访问保护(假定该改变是用于较低(或任选地相同)虚拟信任等级的)。

[0211] 虚拟处理器402在任何给定时间可运行或操作在仅一个虚拟信任等级中，且在特定时间处理器402在其中运行或操作的虚拟信任等级被称为在该特定时间该处理器402的活动虚拟信任等级。虚拟处理器402可按不同方式从一个虚拟信任等级切换到另一虚拟信任等级，诸如响应于特定事件(例如，中断、特定代码序列的执行等等)。

[0212] 返回图3，作为组件304的物理处理器向作为虚拟组件316的虚拟处理器指派虚拟机存储器空间，且维护地址转换表。地址转换表将被指派到虚拟机306的虚拟机存储器空间中的地址映射到物理存储器空间(作为组件304的物理存储器)中的地址。在任何给定时间虚拟机存储器空间中的特定地址映射到物理存储器空间的哪一地址可改变，且由存储器管理器(例如，物理处理器的一部分)控制。使用各种各样的公共和/或专有技术中的任何技术，存储器管理器可改变映射，允许多个不同的虚拟处理器共享物理存储器空间，和/或允许虚拟机存储器空间比物理存储器空间更大。

[0213] 虚拟安全模式模块324维护针对该虚拟机存储器空间的每个存储器页的存储器访问保护，从而标识针对虚拟机306中的每个虚拟处理器的每个虚拟信任等级的存储器访问保护。虚拟安全模式模块324可按各种不同方式维护针对存储器页的存储器访问保护。在一个或多个实施例中，虚拟安全模式模块324为虚拟机306中的每个虚拟处理器的每个虚拟信任等级维护存储器访问保护的表格、列表或其它记录。替换地，虚拟安全模式模块324可按其它方式维护存储器访问保护，诸如将被指派给虚拟机306的虚拟机存储器空间中的地址映射到物理存储器空间中的地址的地址转换表的部分。

[0214] 在一个或多个实施例中，物理处理器可支持多个虚拟到物理转换层。每个虚拟机可管理器自己的虚拟到访客物理页映射。管理程序管理从访客物理页到真实物理页的映射。此外，每个虚拟信任等级可在其向任何较低等级的虚拟信任等级应用时编辑到机器物理页的此最终映射。

[0215] 图5示出根据一个或多个实施例的实现多个虚拟信任等级的示例系统500。示例系统500包括两个虚拟处理器：虚拟处理器502和虚拟处理器504。虚拟处理器502和504可各自为图3的虚拟组件316和/或图4的虚拟处理器402。

[0216] 虚拟处理器502和504实现了被称为VTL 0和VTL 1的两个不同的虚拟信任等级。每个虚拟处理器的每个虚拟信任等级具有其自己的本地中断子系统，被解说为高级可编程中断控制器(APIC)506(用于虚拟处理器502的VTL 0的中断控制器)、APIC 508(用于虚拟处理器502的VTL 1的中断控制器)、APIC 510(用于虚拟处理器504的VTL 0的中断控制器)、以及APIC 512(用于虚拟处理器504的VTL 1的中断控制器)。在任何给定时间，虚拟处理器502和504可在相同或不同虚拟信任等级中操作。从而，多个虚拟处理器可并行地在不同虚拟信任等级中运行。

[0217] 系统500维护VTL 0的存储器访问保护514的记录以及VTL 1的存储器访问保护516的记录。管理程序(例如，图3的虚拟安全模式模块324)维护存储器访问保护514和516。对于从运行在VTL 0中的虚拟处理器502或504对存储器页的地址的每次访问，管理程序检查包括被访问的地址的存储器页的VTL 0访问存储器保护514。如果VTL 0访问存储器保护514指示该访问被允许，则访客物理到系统物理存储器映射518被用来将该地址映射到系统物理存储器520的存储器地址，且所请求的访问被执行。访客物理到系统物理存储器映射518例如是地址转换表，其将虚拟机存储器空间(访客物理地址，或即GPA)中的地址映射到物理存储器空间中的地址(系统物理地址，或即SPA)，如同上面讨论的。然而，如果VTL 0访问指示该访问不被允许的存储器保护514，则所请求的访问被拒绝(不被执行)。因为所请求的访问被拒绝，所以不需要执行该地址到物理存储器520的存储器地址的映射。

[0218] 对于从运行在VTL 1时的虚拟处理器502或504对存储器页的地址的每次访问，管理程序检查包括被访问的地址的存储器页的VTL 1访问存储器保护516。如果VTL 1访问存储器保护516指示该访问被允许，则访客物理到系统物理存储器映射518被用来将该地址映射到系统物理存储器520的存储器地址，且所请求的访问被执行。然而，如果VTL 1访问存储器保护516指示该访问不被允许，则所请求的访问被拒绝(不被执行)。因为所请求的访问被拒绝，所以不需要执行该地址到物理存储器520的存储器地址的映射。

[0219] 各不同存储器访问保护可被标识为存储器访问保护514和516。例如，存储器访问保护可包括以下保护：不可访问(存储器页上的地址不能被读、写或执行)。只读，不执行(存储器页上的地址可被读，但不能被写或执行)。只读，可执行(存储器页上的地址可被读或执行，但不能被写)。读/写，不执行(存储器页上的地址可被读或写，但不可被执行)。以及读/写，可执行(存储器页上的地址可被读、写或执行)。

[0220] 这些不同的存储器访问保护支持各种不同使用场景。例如，当运行在VTL 1中时，一存储器页的VTL 0存储器访问保护可被设置为“不可访问”。此设置将存储器页设为“安全”模式，使得该存储器页对运行在VTL 0中的虚拟处理器502和/或504上的程序不可访问。作为另一示例，当运行在VTL 1中时，一存储器页的VTL 0存储器访问保护可被设置为“只读、可执行”。此设置将该存储器页放在其中其可被运行在VTL 0中的虚拟处理器502和/或
502上的程序读和执行但是不能被运行在VTL 0中的虚拟处理器502和/或504上的程序更改的模式中。从而，各代码完整性和其它安全程序可被存储在VTL 1中的存储器页中，并由VTL
0中的程序运行，同时确保运行在VTL 0中的那些程序不能更改所述程序。

[0221] 附加设备也可任选地与特定虚拟信任等级相关联。访问存储器页(例如，执行直接存储器访问(DMA))的任何附加设备可与虚拟信任等级相关联。系统500包括示例设备522和524。设备522与VTL 0相关联，且与运行在VTL 0中的虚拟处理器502和504类似，设备522被允许根据VTL 0存储器访问保护514来访问存储器页。类似地，设备524与VTL 1相关联，且与运行在VTL 1中的虚拟处理器502和504类似，设备524被允许根据VTL 1存储器访问保护516来访问存储器页。

[0222] 在一个或多个实施例中，每个设备522和524被初始化以在最低虚拟信任等级(例如，VTL 0)中操作。虚拟处理器502或504可将设备配置成与活动VTL相关联或任选地与任何较低等级VTL相关联。虚拟处理器502或504可按各种方式将设备配置成与特定VTL相关联，诸如通过调用管理程序302所展示的调用(例如函数)。

[0223] 图3的虚拟安全模式模块324维护哪些设备与哪些虚拟信任等级相关联的记录。模块324更新该记录以反映哪些虚拟安全信任等级与哪些设备相关联中的改变。虚拟安全模式模块324还维护在任何给定时间每个虚拟处理器502和504正在哪些虚拟信任等级中操作的记录。虚拟处理器502和504可按不同方式从一个虚拟信任等级切换到另一虚拟信任等级，且每当这种切换发生时，被切换到的虚拟信任等级的指示被包括在模块324所维护的记录中。

[0224] 在所解说的示例系统500中，针对不同虚拟信任等级的存储器访问保护514和516被独立实现，且公共存储器映射518被所有虚拟信任等级共享。替换地，存储器访问保护514和516被作为存储器映射518的一部分实现。在这种情形中，单一存储器映射518可被实现，该单一存储器映射包括针对所有虚拟信任等级的存储器访问保护，或替换地独立存储器映射可被实现(类似于存储器映射518)，每个存储器映射包括针对一不同虚拟信任等级的存储器访问保护。

[0225] 返回图3，在一个或多个实施例中，虚拟机306的虚拟处理器被初始化以在单一虚拟信任等级(诸如VTL 0)中运行。在仅单一虚拟信任等级的情况下，虚拟机306也可被称为没有针对该虚拟机306启用虚拟安全模式。为了在更高虚拟信任等级中运行，虚拟机306被针对一个或多个更高虚拟信任等级启用(也被称为针对该虚拟机306启用虚拟安全模式)。在启用更高虚拟信任等级之后，运行在该更高虚拟信任等级中的程序可改变针对更低虚拟信任等级的存储器访问保护。

[0226] 在一个或多个实施例中，在各种不同时间可针对虚拟机306启用一个或多个更高虚拟信任等级。例如，在虚拟机306的创建和/或管理程序302的引导期间、在虚拟机306引导且运行了阈值时间量之后(例如，数分钟或数小时)，等等可针对虚拟机306启用一个或多个更高虚拟信任等级。

[0227] 图6是示出根据一个或多个实施例的针对虚拟机启用该虚拟安全模式的示例过程600的流程图。过程600由运行在虚拟机中的程序和管理程序(诸如运行在图3的虚拟机306中的程序和图3的管理程序302)执行，且可用软件、固件、硬件或其组合来实现。过程600被示为一组动作，并且不仅限于所示出的用于执行各种动作的操作的顺序。过程600是用于针对虚拟机启用虚拟安全模式的示例过程；针对虚拟机启用虚拟安全模式的附加讨论参考不同附图包括在本文中。

[0228] 在过程600中，运行在虚拟机中的程序将虚拟安全模式镜像加载到存储器中(动作602)。该程序可被视为运行在最低虚拟信任等级中(即使虚拟安全模式尚未被启用)。该程序在其中运行的虚拟信任等级也被称为启动虚拟信任等级。在一个或多个实施例中，虚拟安全模式镜像被该程序(其可被称为虚拟安全模式加载器)加载到存储器中，从而将虚拟安全模式镜像复制到或以其它方式放到该虚拟机的虚拟存储器空间的存储器页中。虚拟安全模式镜像是指在执行时实现虚拟安全模式的代码和数据(例如，可由处理器执行的对象代码)。

[0229] 还(例如由加载虚拟安全模式镜像的程序)向管理程序通知虚拟安全模式镜像被加载到的存储器页。还按不同方式通知管理程序，诸如通过虚拟安全模式加载器调用管理程序所展示的调用(也被称为超级调用(hypercall))并提供该虚拟安全模式镜像被加载到的存储器页的指示作为该超级调用的参数。超级调用可以例如是HvLoadVsmImage()超级调用。

[0230] 响应于虚拟安全模式镜像被加载到的存储器页的通知，管理程序使得那些存储器页对该启动虚拟信任等级不可访问(动作604)。管理程序还使得那些存储器页对比该启动虚拟信任等级更低等级的虚拟信任等级(如果存在)不可访问。可按不同方式使得存储器页不可访问，诸如使得存储器页的存储器访问保护对该启动虚拟信任等级(以及比该启动虚拟信任等级更低等级的任何虚拟信任等级)“不可访问”。

[0231] 此外，管理程序准备虚拟安全模式镜像(动作606)。准备虚拟安全模式镜像是指将管理程序置于能够执行并验证虚拟安全模式镜像的状态。这种准备可包括记录关于虚拟安全模式镜像被存储的位置(例如，存储器页)的各种内部状态，并且还生成虚拟安全模式镜像的散列值。在虚拟处理器上启用更高等级的虚拟信任等级之后首次进入该更高等级的虚拟信任等级时，预期虚拟处理器以良好定义的状态执行。这允许确保该初始程序或运行在该更高等级虚拟信任等级中的程序正确地操作。初始程序或运行在更高等级虚拟信任等级的程序可在其在更高等级虚拟信任等级将其执行环境开机时使用此信息。

[0232] 虚拟安全模式镜像的散列值可使用各种公共和/或专有散列函数中的任何函数来生成，诸如安全散列算法(SHA)散列函数族中的任何散列函数。散列值可以是跨所有存储器页的虚拟安全模式镜像的散列值，或替换地是虚拟安全模式镜像的至少部分被加载到的存储器页中的每个存储器页的散列值的集合。散列值可例如被管理程序用于随后验证虚拟安全模式镜像在被加载到存储器之后没有被更改。对散列值的另一使用是将其发送到要被添加到PCR寄存器状态的TPM，使得TPM可证明VTL的软件配置。

[0233] 管理程序随后在该启动虚拟处理器上启用目标虚拟信任等级(动作608)。目标虚拟信任等级是指比该启动虚拟信任等级更高的虚拟信任等级。启动虚拟处理器是指运行虚拟安全模式加载器的虚拟处理器。在一个或多个实施例中，管理程序响应于管理程序所展示的超级调用被虚拟安全模式加载器调用而在该启动虚拟处理器上启用目标虚拟信任等级。超级调用可以例如是HvEnableVtl()超级调用。

[0234] 管理程序随后在该虚拟机中的其它虚拟处理器上启用目标虚拟信任等级(动作610)。在一个或多个实施例中，管理程序响应于管理程序所展示的超级调用被虚拟安全模式加载器调用而在其他虚拟处理器上启用目标虚拟信任等级。虚拟安全模式加载器可提供该目标虚拟安全等级要在其上被启用的虚拟处理器的标识符作为超级调用的参数，或替换地，超级调用可指示在虚拟机中的所有其它虚拟处理器上启用目标虚拟信任等级。虚拟安全模式加载器还可任选地提供用于目标虚拟信任等级在其上被启用的其它处理器的目标虚拟信任等级的初始虚拟处理器上下文。超级调用可以例如是HvEnableVtl()超级调用。

[0235] 在其中三个或更多虚拟信任等级被实现的实施例中，动作608和610可针对要被启用的每个附加更高等级虚拟信任等级重复。对于每个更高等级虚拟信任等级，管理程序所展示的超级调用被虚拟安全模式加载器(或运行在比被启用的目标虚拟信任等级更低的虚拟信任等级中的其它程序)调用。

[0236] 在一个或多个实施例中，虚拟机的每个虚拟信任等级可被分别地启用或禁用。虚拟信任等级可通过调用管理程序的调用(例如，HvDisableVtlVp超级调用)在处理器上禁用，该调用标识其上的虚拟信任等级要被禁用的虚拟处理器。该调用由在被禁用的虚拟信任等级中操作的虚拟处理器调用。响应于该调用，管理程序禁用所标识的虚拟处理器上的该虚拟信任等级。管理程序任选地触发到所标识虚拟处理器上的更低虚拟信任等级的退出，以使得所标识的虚拟处理器运行在该更低虚拟信任等级中。

[0237] 此外，在一个或多个实施例中，虚拟机的所有更高虚拟信任等级可被禁用，从而有效地移除虚拟机的虚拟安全模式。可通过禁用虚拟机的除一个虚拟处理器(被称为最终虚拟处理器)之外的所有虚拟处理器上的除最低等级之外的所有虚拟信任等级来从虚拟机移除虚拟安全模式。更高等级的虚拟信任等级可通过调用管理程序的调用(例如，HvDisableVtlVp超级调用)在处理器上禁用，其标识其上更高虚拟信任等级要被禁用的虚拟处理器。该调用由在被禁用的更高虚拟信任等级中操作的虚拟处理器调用。响应于该调用，管理程序禁用所标识的虚拟处理器上的除了最低虚拟信任等级之外的所有虚拟信任等级。

[0238] 除最低虚拟信任等级之外的所有虚拟信任等级随后在该虚拟机的最终虚拟处理器上被禁用。通过调用管理程序的调用(例如，HvDisableVTL超级调用)来禁用更高虚拟信任等级。该调用由在正被禁用的更高虚拟信任等级中操作的最终虚拟处理器调用。响应于该调用，管理程序触发到最终虚拟处理器上的最低等级虚拟信任等级的退出。此时，虚拟机中的所有虚拟处理器运行在最低等级虚拟信任等级中。随后通过调用管理程序的调用(例如，HvUnloadVsm超级调用)来卸载虚拟安全模式镜像。响应于此调用，所有存储器访问保护被回复到其初始状态，从而导致存储器页对最低等级的虚拟信任等级可访问，包括存储虚拟安全模式镜像的存储器页可访问(例如，在动作604时被置为不可访问的存储器)。

[0239] 在替代实施例中，管理程序在最高特权VTL中启动虚拟CPU，并且其中的代码启动更低的VTL等级。这可类似地进行，但是可以更为简单，因为在一些实施例中，更高的VTL等级可被相信为不破化更低的VTL等级。

[0240] 返回图4，虚拟处理器402可按各种不同方式改变活动虚拟信任等级。从更低虚拟信任等级切换或改变到更高虚拟信任等级也被称为进入更高虚拟信任等级，而从更高虚拟信任等级切换或改变到更低虚拟信任等级也被称为退出更高虚拟信任等级。

[0241] 在一个或多个实施例中，虚拟处理器402可响应于一个或多个事件发生而从更低虚拟信任等级切换或改变到更高虚拟信任等级，所述事件诸如是虚拟信任等级调用、针对更高虚拟信任等级的中断、陷阱(例如，以允许更高虚拟信任等级处理针对更低虚拟信任等级的特定类型的故障，诸如页故障)、或到更高虚拟信任等级中的截取。虚拟信任等级调用是指被执行以从当前虚拟信任等级过渡到更高虚拟信任等级的特定一个或多个指令(例如，特定指令序列)。针对更高虚拟信任等级的中断是接收到指针对比当前虚拟信任等级更高的虚拟信任等级的中断(或目标在所述更高的虚拟信任等级的中断)。到更高虚拟信任等级中的截取是指访问更高虚拟信任等级的受保护地址或受保护组件的操作，受保护地址或受保护组件为诸如更高信任等级的寄存器、与更高虚拟信任等级相关联的I/O端口、或与更高虚拟信任等级相关联的存储器页。

[0242] 虚拟处理器402的一些处理器状态被跨不同虚拟信任等级共享，且也被称为共享处理器状态。共享处理器状态在改变活动虚拟信任等级时不需要改变，从而改善了改变虚拟信任等级的效率。然而，虚拟处理器402的其它处理器状态不被跨不同虚拟信任等级共享，且也被称为私有处理器状态。私有处理器状态(被示为虚拟处理器状态408)在改变活动虚拟信任等级时被改变。

[0243] 应当注意，尽管在改变活动虚拟信任等级时共享处理器状态保持不变，然而运行在虚拟信任等级中的程序可能取决于虚拟信任等级为何变得活动的原因而具有关于它们如何处理共享处理器状态的不同策略。例如，如果一虚拟信任等级由于虚拟信任等级调用而变得活动，则运行在新活动的虚拟信任等级中的程序可能不需要保存共享处理器状态，因为先前虚拟信任等级(调用对新活动的虚拟信任等级的调用的虚拟信任等级)中的程序能容许该共享处理器状态改变。然而，如果虚拟信任等级由于中断而变得活动，则运行在先前虚拟信任等级(被打断了的虚拟信任等级)中的程序很可能不容许该共享处理器状态改变，因为它们没有意识到虚拟信任等级改变发生了。在此情况下，运行在新活动的虚拟信任等级中的程序可在改变共享处理器状态之前保存共享处理器状态，以使得运行在新活动的虚拟信任等级中的程序可在完成中断处理之际还原共享处理器状态(以使得先前虚拟信任等级可被回复到其原始状态中，使得中断对运行在先前虚拟信任等级中的程序透明)。

[0244] 在一个或多个实施例中，私有处理器状态包括指令指针(或程序计数器)寄存器和栈指针寄存器。活动虚拟信任等级的私有处理器状态在改变活动虚拟信任等级时被管理程序保存，且用被改变到的虚拟信任等级的私有处理器状态替换。被改变到的虚拟信任等级的私有处理器状态可以是默认/初始状态(如果虚拟信任等级先前没有被进入)，或针对该虚拟信任等级的先前被保存的私有处理器状态(在虚拟处理器402上次从该虚拟信任等级改变之前保存的)。

[0245] 在一个或多个实施例中，管理程序为每个虚拟信任等级404(除了最低等级虚拟信任等级外)维护控制页以供管理程序和运行在该虚拟信任等级中的程序之间的双向通信使用。控制页可包括为何进入该虚拟信任等级的原因的指示(例如，所发生的导致进入更高虚拟信任等级的事件)、先前虚拟信任等级的指示(在所发生的导致进入更高虚拟信任等级的事件之前的时间的活动虚拟信任等级)、以及任选地描述所发生的导致进入更高虚拟信任等级的事件或与该事件有关的附加信息的指示。

[0246] 在一个或多个实施例中，虚拟处理器402可从一个虚拟信任等级切换到仅下一更高虚拟信任等级。例如，虚拟处理器402可从VTL 0切换到VTL 1，从VTL 1切换到VTL 2，从VTL 2切换到VTL 3，如此等等，但是不能从VTL 0切换到VTL 3。替换地，虚拟处理器可从一个虚拟信任等级切换到任何更高的虚拟信任等级。例如，在虚拟信任等级调用中，虚拟处理器402可指定要切换到哪个更高的虚拟信任等级，从而允许从VTL 0切换到VTL 3。

[0247] 在从更低虚拟信任等级切换到更高虚拟信任等级之后，虚拟处理器402可响应于各种不同事件切换或改变回到更低虚拟信任等级(退出更高虚拟信任等级)。在一个或多个实施例中，虚拟处理器402执行一个或多个动作(例如，执行一个或多个操作，处理中断等)并随后返回到更低虚拟信任等级。虚拟处理器402通过执行特定的一个或多个指令以从当前虚拟信任等级过渡到更低虚拟信任等级来返回到更低虚拟信任等级。这些指令任选地被存储在被称为虚拟信任等级退出代码页的存储器页上，其允许管理程序抽象出代码序列来切换虚拟信任等级。在一个或多个实施例中，虚拟处理器402返回到从其进入活动虚拟信任等级的更低虚拟信任等级，然而替换地，虚拟处理器402可返回到一不同虚拟信任等级。

[0248] 对于共享处理器状态，该处理器状态在改变虚拟信任等级时不改变，这允许使用共享处理器状态在虚拟信任等级之间传递信息。对于私有处理器状态，每个虚拟信任等级具有其自己的处理器状态的实例(例如寄存器)，其仅可由该虚拟信任等级访问。管理程序管理在各虚拟信任等级之间切换时保存和还原这一处理器状态(例如，寄存器的内容)。当进入虚拟信任等级404时，私有处理器状态与虚拟处理器402上次在该虚拟信任等级402中运行时相同(例如，寄存器包含相同值)。

[0249] 一般而言，在进入虚拟信任等级之际要被适当配置以便代码在该虚拟信任呢等级中执行的寄存器是私有处理器状态。确保了更高等级的虚拟信任等级，其可可靠地获得处于不能被更低等级的虚拟信任等级改变的良好定义的状态的虚拟处理器的执行控制。从而，关键的控制寄存器和对控制执行流而言很重要的寄存器是针对每个虚拟信任等级的私有处理器状态。在进入一虚拟信任等级之际不直接更改代码流的通用寄存器状态可以是共享处理器状态或私有处理器状态。

[0250] 在一个或多个实施例中，除了指令指针(或程序计数器)寄存器和栈指针寄存器之外，通用寄存器、向量寄存器、以及浮点寄存器是共享处理器状态。指令指针(或程序计数器)寄存器和栈指针寄存器是私有处理器状态。除了页故障寄存器之外，控制寄存器也是私有处理器状态。页故障寄存器(例如，用于X64架构处理器的CR2寄存器)是共享处理器状态。

[0251] 表格I解说了是共享处理器状态的寄存器的示例(在表格I中被列为类型“共享”)，以及是私有处理器状态的寄存器的示例(在表格I中被列为类型“私有”)。表格1中解说的寄存器是用于X64架构的处理器的示例。要领会，这些寄存器是示例，不是所有处理器架构均包括所有这些寄存器，且不同处理器架构可包括不同(但任选地类似的)寄存器。

[0252] 表格I

[0253]

[0254]

[0255] 在一个或多个实施例中，管理程序还维护各种不同机器状态寄存器(MSR)，它们也被称为虚拟寄存器，一些虚拟寄存器是共享处理器状态而一些虚拟寄存器是私有处理器状态。表格II解说了是共享处理器状态的MSR的示例(在表格II中被列为类型“共享”)，以及是私有处理器状态的MSR的示例(在表格II中被列为类型“私有”)。表格II中具有前缀“HV_X64”的寄存器指代可从华盛顿州雷蒙德市的微软公司获得的Hyper- 虚拟化软件中的寄存器，而表格II中不具有前缀“HV_X64”的寄存器指代标准X64架构寄存器。表格II中所解说的MSR是用于运行在X64架构处理器上的虚拟机的示例。要领会，这些MSR是示例，不是所有虚拟安全模式均需要包括所有这些MSR，且不同处理器架构可包括不同(但任选地类似的)寄存器。附加地，每个MSR的分类仅仅是出于示例，并且在不同的实施例中可能是不同的。

[0256] 表II

[0257]

[0258]

[0259] 此外，如同上面讨论的，虚拟信任等级404具有独立的中断子系统，其中每个虚拟信任等级404具有其自己的中断子系统410。独立的中断子系统410允许运行在一虚拟信任等级中的程序在各虚拟处理器之间安全地发送处理器间中断而不存在来自更低虚拟信任等级的干扰。独立的中断子系统610还允许一虚拟信任等级的中断子系统从与该相同虚拟信任等级相关联的设备安全地接收中断而不存在来自更低虚拟信任等级中的程序的干扰。独立的中断子系统410还允许每个中断子系统410具有不会受更低虚拟信任等级中的程序干扰的安全计时器设施。独立的中断子系统410还允许中断子系统410在接收到针对更低信任等级的中断(以更低信任等级作为目标的中断)之际接收通知，以便允许各中断在各虚拟信任等级之间的协作式调度。

[0260] 对于活动虚拟信任等级，管理程序可针对活动虚拟信任等级、针对比该活动虚拟信任等级更高的虚拟信任等级(除非该活动虚拟信任等级是该虚拟机的最高虚拟信任等级)、或针对比该活动虚拟信任等级更低的虚拟信任等级(除非该活动虚拟信任等级是该虚拟机的最低虚拟信任等级)接收中断。在一个或多个实施例中，中断包括该中断所针对的(该中断作为目标的)虚拟信任等级的指示。响应于接收到以活动虚拟信任等级作为目标的中断，活动虚拟信任等级的中断子系统410处理该中断。

[0261] 响应于接收到以比该活动虚拟信任等级更高的虚拟信任等级为目标的中断，管理程序可采取各种不同的动作。在一个或多个实施例中，中断控制MSR(例如HV_X64_MSR_VSM_INTERCEPT_CTL MSR)包括确定要采取的动作的中断VTL退出设置。如果中断VTL退出设置具有一个值(例如，指示总是退出)，则管理程序将活动虚拟信任等级切换到该更高虚拟信任等级，且该更高虚拟信任等级的中断子系统410处理该中断。然而，如果中断VTL退出设置具有另一值(例如，指示检查可中断性)，则管理程序仅在该更高虚拟信任等级的处理器状态指示该更高虚拟信任等级可被中断时将活动虚拟信任等级切换到该更高虚拟信任等级。替换地，中断VTL退出设置可被维护在其它位置中，诸如该活动虚拟信任等级(或更高虚拟信任等级)的控制页中。

[0262] 替换地，要采取的动作可按不同方式确定。例如，管理程序可提供一种机制，以允许更高虚拟信任等级指定将触发活动虚拟信任等级到更高虚拟信任等级的切换的特定中断向量，以由更高虚拟信任等级的中断子系统410处理该中断。替换地，各种不同状态准则可被管理程序应用，且管理程序可将活动虚拟信任等级切换到该更高虚拟信任等级以用于仅在活动虚拟信任等级满足状态准则时由该更高虚拟信任等级的中断子系统410处理该中断。

[0263] 响应于接收到以比该活动虚拟信任等级更低的虚拟信任等级为目标的中断，管理程序维护该中断的记录以供随后递送到该更低虚拟信任等级的中断子系统410。在一个或多个实施例中，中断不抢占活动虚拟信任等级中的该虚拟处理器402的操作。相反，在虚拟处理器402下次切换到该更低虚拟信任等级中操作时，管理程序将该中断提供给该更低虚拟信任等级的中断子系统410。

[0264] 应当注意，可能出现以下情形：其中期望在向更低虚拟信任等级发送中断时通知更高虚拟信任等级。例如，这在以下情形中可能是期望的：其中更高虚拟信任等级的程序希望允许虚拟处理器返回到更低虚拟信任等级来处理中断。在一个或多个实施例中，提供中断通知设施，以促进在向更低虚拟信任等级发送中断时通知更高虚拟信任等级。此中断通知设施可按不同方式提供，诸如控制MSR(例如HV_X64_MSR_VTL_CTL MSR)。此中断通知设施可防止更高虚拟信任等级延迟对更新虚拟信任等级的中断处理达长时间段。

[0265] 在使用中断通知设施时，响应于接收到以比活动虚拟信任等级更低的虚拟信任等级为目标的中断，管理程序评估私有处理器状态和更低虚拟信任等级的中断子系统410的状态来确定该中断是否能被呈现给该更低虚拟信任等级的中断子系统410。如果，由于各种私有处理器状态或中断子系统410状态，中断不能被呈现给更低虚拟信任等级中断子系统410，则该中断被标记为待决且不对该中断采取进一步动作。然而，如果该中断可被呈现给更低信任等级中断子系统410，则管理程序维护该中断的记录以供如上所讨论的随后递送给该更低虚拟信任等级的中断子系统410，并在活动虚拟信任等级处生成中断。在活动虚拟信任等级处生成的中断(例如，到在HV_X64_MSR_VTL_CTL MSR中指定的中断向量的中断)导致运行在活动虚拟信任等级处的程序决定如何对该中断进行响应。该程序可使得管理程序退出该更高虚拟信任等级，从而允许该更低虚拟信任等级处理以该更低虚拟信任等级为目标的中断。然而，管理程序不需要退出该更高虚拟信任等级，或该程序可延迟使得管理程序退出该更高虚拟信任等级达各种时间量。

[0266] 此外，如同上面讨论的，管理程序可响应于到更高虚拟信任等级中的中断而切换到更高虚拟信任等级。在一个或多个实施例中，管理程序允许更高虚拟信任等级指定锁定并对处于更低虚拟信任等级中的程序不可访问的特定资源或组件。管理程序可允许更高虚拟信任等级将例如特定输入/输出(I/O)端口访问控制、MSR访问控制、存储器访问控制、和/或控制寄存器锁定并使其不可访问。更高虚拟信任等级可(例如，经由各种MSR设置或按其它方式)指定哪些特定I/O端口访问控制、MSR访问控制、存储器访问控制、和/或控制寄存器被锁定。响应于(例如，由程序或设备)做出尝试来访问由更高虚拟信任等级锁定的资源或组件，生成到较高虚拟信任等级中的截取。响应于该截取，管理程序将虚拟处理器切换到更高虚拟信任等级(或替换地切换到该虚拟处理器支持的最高虚拟信任等级)。

[0267] 更高虚拟信任等级能够按各种不同方式对该截取进行响应。例如，处于更高虚拟信任等级中的程序可认为该访问是致命的并且触发某种故障指示。作为另一示例，处于更高虚拟信任等级中的程序可模仿对该资源或组件的访问。为了允许这种模仿，管理程序提供超级调用，该超级调用可被用来操纵导致该截取的该更低虚拟信任等级的上下文。作为另一示例，处于更高虚拟信任等级中的程序可代理对该资源或组件的访问的执行。作为又一示例，处于更高虚拟信任等级中的程序可反映对更低虚拟信任等级的安全截取。

[0268] 在一个或多个实施例中，在其中虚拟处理器402包括三个或更多虚拟信任等级的情形中，代替支持安全截取设施的嵌套，管理程序提供跨所有虚拟信任等级共享的单一访问控制MRS集合。期望使用访问控制MSR的虚拟信任等级中的程序可使用其自己的定义的接口来协作，或替换地处于最高虚拟信任等级中的程序可模仿对到更低虚拟信任等级的截取设施的支持(例如，更高虚拟信任等级将安全截取注入到更新虚拟信任等级中)。替换地，安全截取设施的嵌套可被管理程序支持，且独立的访问控制MSR可被用于不同的虚拟信任等级。

[0269] 管理程序支持各种不同的MSR。以下是可被管理程序支持的若干MSR的示例。列举了MSR的具体字段。然而要领会，这些MSR是示例，且替换地可使用其它寄存器、寄存器的位布局、字段等等。

[0270] 表格III解说了HV_X64_MSR_VTL_CTL MSR的示例，其对每个虚拟处理器上的每个更高虚拟信任等级(除了最低等级虚拟信任等级之外的所有虚拟信任等级)可用。除了VTL 0之外，每个更高虚拟信任等级具有其自己的HV_X64_MSR_VTL_CTL MSR的实例。HV_X64_MSR_VTL_CTL MSR控制VSM针对更高虚拟信任等级如何操作的各种属性。

[0271] 表III

[0272]

[0273] 表格IV解说了HV_X64_MSR_VTL_CALL MSR的示例，其被用于标识将VTL调用代码页映射到的GPA页。HV_X64_MSR_VTL_CALL MSR跨该虚拟机被共享。每个虚拟信任等级(除了最高虚拟信任等级之外)均在虚拟机中存在HV_X64_MSR_VTL_CALL MSR的一个实例。当HV_X64_MSR_VTL_CALL MSR被使能时，在代码页GPA字段中指定的地址用虚拟信任等级调用代码页(如上讨论的用于管理程序和运行在虚拟信任等级中的程序之间的双向通信的控制页)覆盖。

[0274] 表IV

[0275]

[0276]

[0277] 表格V解说了HV_X64_MSR_VTL_STATUS MSR的示例，其提供了关于虚拟处理器的虚拟信任等级状态的信息。HV_X64_MSR_VTL_STATUS MSR是针对个体虚拟处理器的，且该虚拟处理器的每个虚拟信任等级均存在HV_X64_MSR_VTL_STATUS MSR的一个实例。

[0278] 表V

[0279]

[0280] 表格VI解说了HV_X64_MSR_VTL_EXIT MSR的示例，其被用于标识将虚拟信任等级退出代码页映射到的GPA页。The HV_X64_MSR_VTL_EXIT MSR跨该虚拟机被共享。每个虚拟信任等级(除了最低虚拟信任等级之外)均在虚拟机中存在HV_X64_MSR_VTL_EXIT MSR的一个实例。当HV_X64_MSR_VTL_EXIT MSR被使能时，在VTL退出代码页GPA字段中被指定的地址被用虚拟信任等级退出代码页覆盖。

[0281] 表VI

[0282]

[0283]

[0284] 表格VII解说了HV_X64_MSR_VSM_INTERCEPT_CTL MSR的示例，其控制什么类型的截取将触发对更高虚拟信任等级的进入。HV_X64_MSR_VSM_INTERCEPT_CTL MSR是针对个体虚拟处理器的，且被该虚拟处理器的虚拟信任等级共享(尽管HV_X64_MSR_VSM_INTERCEPT_CTL MSR在最低虚拟信任等级中不可用)。

[0285] 表VII

[0286]

[0287] 表格VIII解说了_X64_MSR_VSM_IOPORT_CTL MSR的示例，其控制哪些I/O端口访问触发到最高(或更高)虚拟信任等级中的截取。两个HV_X64_MSR_VSM_IOPORT_CTL MSR可被包括，它们具有相同字段并被称为HV_X64_MSR_VSM_IOPORT_CTL0MSR和HV_X64_MSR_VSM_IOPORT_CTL1MSR。这两个MSR是针对个体虚拟处理器的，且每一个MSR都被该虚拟处理器的虚拟信任等级共享(尽管这两个MSR在最低虚拟信任等级中不可用)。

[0288] 表格VIII

[0289]

[0290] 表格IV解说了HV_X64_MSR_VSM_MSR_CTL MSR的示例，其控制哪些MRS访问触发到更高虚拟信任等级中的截取。HV_X64_MSR_VSM_MSR_CTL MSR是针对个体虚拟处理器的，且被该虚拟处理器的虚拟信任等级共享(尽管HV_X64_MSR_VSM_MSR_CTL MSR在最低虚拟信任等级中不可用)。

[0291] 表格IX

[0292]

[0293] 应当注意，本文讨论的技术的一个方面在于：更高虚拟信任等级不能被更低虚拟信任等级抢占。从而，当虚拟处理器运行在更高虚拟信任等级时，虚拟处理器可切换到更低虚拟信任等级的唯一方式是当软件通过执行VTL退出主动切换到更低虚拟信任等级时。外部事件(例如中断等)均不能触发从更高虚拟信任等级到更低虚拟信任等级的自动切换。

[0294] 还要注意，使用本文讨论的技术实现的虚拟信任等级独立于由计算设备300的物理处理器实现的任何保护环或其它保护机制。本文讨论的技术独立于物理处理器架构，且从而可跨任何数量的不同处理器架构实现。而且，本文讨论的技术可支持任何数量的虚拟信任等级，包括针对同一和/或不同虚拟机中的不同虚拟处理器的不同数量的虚拟信任等级。

[0295] 还应注意，计算设备300的一个或多个虚拟处理器可支持多个不同模式中的代码的执行，包括至少一个内核模式(kernel mode)(也被称为内核模式(kernel-mode)、监督者模式(supervisor mode)或监督者模式(supervisor-mode))和用户模式(也被称为用户模式(user-mode))。本文讨论的技术独立于代码被在虚拟处理器中执行的任何此类模式。本文讨论的存储器访问保护被基于虚拟处理器正在其中操作的虚拟信任等级而应用，且与该虚拟处理器正在内核模式还是用户模式中执行代码无关地被应用。从而，即使虚拟处理器正在内核模式中执行代码，一虚拟信任等级的存储器访问保护可仅如上讨论地基于活动虚拟信任等级而被虚拟安全模式模块改变(该虚拟处理器是在内核模式还是用户模式执行是无关的)。尽管可由虚拟处理器基于其用于执行代码的模式(例如，用户或内核)来提供附加保护，然而那些保护独立于本文讨论的基于虚拟信任等级应用的存储器访问保护。

[0296] 从而，本文讨论的技术提供了一种比运行在内核模式的操作系统具有更多特权的环境。例如，当运行在VTL 1中时，一存储器页的VTL 0存储器访问保护可被设置为“不可访问”，且数据或代码可被存储在该存储器页中。这种设置将该存储器页置为“安全”模式，使得该存储器页对于运行在VTL 0中的程序而言不可访问。从而，即使操作系统正运行在内核模式中，如果操作系统正在VTL 0中运行，则存储在该存储器页中的数据或代码仍旧对该操作系统而言不可访问。

[0297] 然而，本文讨论的技术可结合支持不同执行模式或保护环的虚拟处理器使用。例如，虚拟处理器可在VTL 1中具有其自己的内核模式和用户模式，且在VTL 0中具有其自己的内核模式和用户模式。从而，VTL 1中的地址空间不能访问VTL 1中的另一地址空间，除非被VTL 1内核模式允许这样做。然而，VTL0内核模式仍旧不能访问VTL 1中的任何地址空间(假定VTL 1中的地址空间的存储器页已被如此标记)。

[0298] 下面的讨论现在涉及可被执行的多个方法和方法动作。尽管这些方法动作可以以特定次序被讨论或在流程图中被例示为以指定次序发生，但是除非特别指明否则不需要任何特定排序，或者因某一动作取决于在该动作被执行之前完成的另一个动作而要求特定排序。

[0299] 现在参考图7，例示出方法700。方法700可在计算环境中实施并包括用于针对主机建立信任的动作。方法700包括主机证明服务从被部署在物理机器上的主机接收主机满足的特定特征的可验证指示(动作702)。例如，图2示出主机230发送被HAS 258接收的请求260。该请求可包括特定主机特征的可验证证据。

[0300] 方法700还包括尝试从特定特征的指示中确定主机满足特定要求(动作704)。例如，HAS 258可尝试验证请求260中的证据。

[0301] 如果主机满足特定要求(包括至少满足主机包括受信执行环境(TEE)的要求)，则主机证明服务向主机颁发证书，主机可使用该证书来向与主机证明服务具有信任关系的一个或多个实体进行认证(动作706)。由此，如图2中示出的，HAS 258颁发可由主机230用于获得各种密钥或其他特权的证书257。

[0302] 方法700可被实施，其中特定要求还包括与实现主机的物理机器上的TPM(受信平台模块)有关的要求。例如，各实施例可要求TPM被安装在实现主机的物理机器处和/或TPM以特定方式或出于特定目的被使用。替代地或附加地，特定要求还包括与ARM TrustZone和/或Intel SGX能力有关的要求。

[0303] 方法700还可包括，作为在确定实现主机的物理机器可验证地满足特定要求方面失败的结果，向被配置成部署访客虚拟机的虚拟机管理器(VMM)通知主机不满足特定要求。在一些这样的实施例中，这可被完成，使得VMM可避免将访客虚拟机部署在主机上以防止到非受信主机的注定失败的虚拟机部署，如以上描述中描述的。

[0304] 方法700还可包括，作为在确定主机可验证地满足特定要求方面失败的结果，向虚拟机管理器(VMM)通知主机不可用于访客虚拟机的部署。

[0305] 方法700可被实施，其中特定要求还包括正确且可信的UEFI(统一可扩展固件接口)报告针对实现主机的物理主机机器被提供以验证未被损害的引导发生的要求。例如，这可被完成来验证没有根工具包已经被安装在主机上。

[0306] 方法700可被实施，其中特定要求还包括主机包括正确HVCI(管理程序实施的代码完整性)策略确认的可验证指示被提供的要求。

[0307] 方法700可被实施，其中特定要求还包括主机位于特定地理位置中的要求。例如，特定实体可能出于某些原因(诸如政治原因、策略合规性原因)或出于其他原因希望限制虚拟机可被部署在何处。这可包括其中主机不位于特定地理。具体而言，要求可以是主机位于不是某个被排除地理位置的特定地理位置中。由此，方法700可被实施，其中特定要求还包括主机不位于特定地理位置中的要求。

[0308] 方法700可被实施，其中特定要求还包括主机耦合到安全网络的要求。在各实施例中，安全网络可由一个或多个特性表征，诸如被物理地和/或逻辑地隔离、位于给定物理建筑物内、使用Kerberos(身份验证)来被保护安全性、使用网络接入保护来被保护安全性、针对使用已知方法的窃听攻击来保护安全性以及针对使用已知方法的重放攻击来保护安全性。方法700可被实施，其中特定要求还包括选自由以下构成的组中的要求：匹配安全引导策略、引导调试程序的缺乏、内核调试程序的缺乏、调试功能的缺乏以及预装OS引导栈中软件的预先确定的配置。

[0309] 方法700还可包括创建主机证明服务与密钥分发服务之间的信任关系，主机可通过呈现证书来从该密钥分发服务获得密钥。

[0310] 方法700可被实施，其中该方法可被执行在一环境中，其中主机证明服务被实现在具有结构管理系统的环境中，其中结构管理系统被配置成管理主机操作系统、主机配置、HVCI白名单、HVCI撤销列表、UEFI白名单或UEFI撤销列表中的至少一个。在一些这样的实施例中，相比于被用于认证结构管理系统的管理员，不同的认证和/或授权服务被用于认证主机证明服务的管理员。这种管理的分隔可通过要求管理员的串通来影响对安全性的“监守自盗(inside-job)”损害来防止这种损害。

[0311] 方法700可被实施，其中该方法被执行在一环境中，其中主机证明服务被实现在具有虚拟机管理器的环境中，其中虚拟机管理器被配置成将被屏蔽的访客虚拟机部署到主机，但是其中虚拟机管理器不能解密被屏蔽的访客虚拟机。由此，虚拟机可由VMM部署，但依然相对于VMM保持秘密性。在一些这样的实施例中，方法700可被实施在一环境中，其中相比于被用于认证虚拟机管理器的管理员的认证服务，不同的认证服务被用于认证主机证明服务的管理员。再次，这可通过要求针对任意这种损害的串通来防止安全性损害。在一些实施例中，可使用相同的认证服务，但具有不同的安全配置。例如，单个认证服务可提供正常的基于口令的认证系统以及基于智能卡的系统。

[0312] 现在参考图8，例示出方法800。方法800可以在计算环境中实施。该方法包括用于针对主机建立信任的动作。该方法包括使用物理机器来实现的主机将主机的特定特征的可验证指示发送到主机证明服务(动作802)。

[0313] 如由主机证明服务评估特定特征的指示所确定的，作为主机满足特定要求的结果(包括至少满足主机包括受信执行环境(TEE)的要求)，方法802包括主机从主机证明服务接收一证书，主机可使用该证书来向与主机证明服务具有信任关系的一个或多个实体进行认证(动作804)。

[0314] 方法800可被实施，其中特定要求还包括与实现主机的物理机器上的TPM(受信平台模块)有关的要求。替代地或附加地，特定要求还包括与ARM TrustZone和/或Intel SGX能力有关的要求。

[0315] 方法800可被实施，其中特定要求还包括正确且可信的UEFI(统一可扩展固件接口)报告针对在其上主机被实现的物理机器被提供的要求。

[0316] 方法800可被实施，其中特定要求还包括主机包括正确HVCI(管理程序实施的代码完整性)策略确认的可验证指示被提供的要求。

[0317] 方法800可被实施，其中特定要求还包括主机位于特定地理位置中的要求。这可包括其中主机不位于特定地理。具体而言，要求可以是主机位于不是某个被排除地理位置的特定地理位置中。由此，方法800可被实施，其中特定要求还包括主机不位于特定地理位置中的要求。

[0318] 方法800可被实施，其中特定要求还包括主机耦合到安全网络的要求。

[0319] 方法800可被实施在一环境中，其中存在主机证明服务与密钥分发服务之间的信任关系，主机可通过呈现证书来从该密钥分发服务获得密钥。在一些这样的实施例中，方法800可被实施，其中被屏蔽的访客虚拟机被虚拟机管理器在承租人的请求之际被部署到主机，其中虚拟机管理器不能够解密被屏蔽的访客虚拟机。该方法还可包括主机使用证书来从信任主机证明服务的密钥分发服务获得密钥，其中密钥分发服务接受被主机证明服务签名的证书。主机接着使用密钥来解密被屏蔽的访客虚拟机，使得访客虚拟机可被运行在主机上。在一些这样的实施例中，主机准备关于访客虚拟机的部署的安全细节的经加密的消息(例如，到承租人的指示部署以安全或经加密的方式被完成的证书消息)。经加密的消息不能被虚拟机管理器解密，但能够被承租人解密。主机将经加密的消息发送到虚拟机管理器，其中其可被转发到承租人，而无需虚拟机管理器能够读取经加密的消息。

[0320] 现在参考图9，例示出方法900。方法900可以在计算环境中实施，且包括用于在受信实体上部署经加密的实体的动作。方法900包括，在受信实体处，接收来自非受信实体的经加密的实体，其中作为提供满足特定要求的受信实体的特定特征的可验证指示的结果，受信实体被授权机构信任，并且其中非受信实体不被授权机构信任(动作902)。方法100还包括在受信实体处，使用来自授权机构的信任证书来从密钥分发服务获得密钥，其中密钥分发服务被授权机构信任(动作904)。该方法还包括，使用密钥来解密经加密的实体以允许经加密的实体被部署在受信实体处(动作906)。

[0321] 方法900可被实施，其中特定要求包括受信实体是具有受信执行环境(TEE)的虚拟机的要求。

[0322] 方法900可被实施，其中特定要求包括与实现受信实体的物理机器上的TPM(受信平台模块)有关的要求。替代地或附加地，特定要求还包括与ARM TrustZone和/或Intel SGX能力有关的要求。

[0323] 方法900可被实施，其中特定要求包括受信实体使用具有正确且可信的UEFI报告的物理机器来实现的要求。

[0324] 方法900可被实施，其中特定要求包括受信实体包括正确HVCI(管理程序实施的代码完整性)策略确认的要求。

[0325] 方法900可被实施，其中特定要求包括受信实体物理地位于特定地理位置中的要求。这可包括其中受信实体不位于特定地理。具体而言，要求可以是受信实体位于不是某个被排除地理位置的特定地理位置中。由此，方法900可被实施，其中特定要求包括受信实体物理地不位于特定地理位置中的要求。

[0326] 方法900可被实施，其中特定要求包括受信实体耦合到安全网络的要求。

[0327] 方法900可被实施，其中经加密的实体是要被部署在受信实体上的终端服务器。

[0328] 方法900可被实施，其中经加密的实体包括要被部署在受信实体上的网络翻译信息。

[0329] 方法900可被实施，其中经加密的实体包括要被部署在受信实体上的敏感数据(诸如价格列表、公司策略、机密个人信息等)。

[0330] 方法900可被实施，其中经加密的实体包括被用于配置受信实体或要被部署在受信实体上的其他实体的配置数据。

[0331] 方法900可被实施，其中经加密的实体被部署有多个其他经加密的实体来作为服务模型部署的一部分。

[0332] 而且，各方法可由计算机系统实现，计算机系统包括一个或多个处理器以及诸如计算机存储器这样的计算机可读介质。特别是，计算机存储器可以存储计算机可执行指令，该计算机可执行指令在由一个或多个处理器执行时使各种功能得以被执行，诸如各实施例中记载的动作。

[0333] 本发明的各实施例可以包括或使用包括计算机硬件的专用或通用计算机，如以下更详细讨论的。本发明范围内的各实施例也包括用于实现或存储计算机可执行指令和/或数据结构的实体及其它计算机可读介质。这样的计算机可读介质可以是可由通用或专用计算机系统访问的任何可用介质。存储计算机可执行指令的计算机可读介质是物理存储介质。承载计算机可执行指令的计算机可读介质是传输介质。由此，作为示例而非限制，本发明的各实施例可包括至少两种显著不同的计算机可读介质：物理计算机可读存储介质和传输计算机可读介质。

[0334] 物理计算机可读存储介质包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储器(诸如CD、DVD等)、磁盘存储器或其他磁性存储设备、或者可用于存储计算机执行指令或数据结构形式的期望程序代码装置并且可被通用或专用计算机访问的任何其他介质。

[0335] “网络”被定义为使得电子数据能够在计算机系统和/或模块和/或其它电子设备之间传输的一个或多个数据链路。当信息通过网络或另一个通信连接(硬连线、无线、或者硬连线或无线的组合)传输或提供给计算机时，该计算机将该连接适当地视为传输介质。传输介质可以包括可用于携带计算机可执行指令或数据结构形式的期望程序代码装置并可被通用或专用计算机访问的网络和/或数据链路。以上的组合也被包括在计算机可读介质的范围内。

[0336] 此外，在到达各种计算机系统组件之后，计算机可执行指令或数据结构形式的程序代码装置可从传输计算机可读介质自动转移到物理计算机可读存储介质(或者相反)。例如，通过网络或数据链路接收到的计算机可执行指令或数据结构可被缓存在网络接口模块(例如，“NIC”)内的RAM中，并且然后最终被传输至计算机系统RAM和/或计算机系统处的较不易失性的计算机可读物理存储介质。因此，计算机可读物理存储介质可以被包括在同样(或甚至主要)利用传输介质的计算机系统组件中。

[0337] 计算机可执行指令包括例如使通用计算机、专用计算机或专用处理设备执行某一功能或一组功能的指令和数据。计算机可执行指令可以是例如二进制代码、诸如汇编语言之类的中间格式指令、或甚至源代码。尽管用结构特征和/或方法动作专用的语言描述了本主题，但可以理解，所附权利要求书中定义的主题不必限于上述特征或动作。相反，上述特征和动作是作为实现权利要求的示例形式而公开的。

[0338] 本领域的技术人员将理解，本发明可以在具有许多类型的计算机系统配置的网络计算环境中实践，这些计算机系统配置包括个人计算机、台式计算机、膝上型计算机、消息处理器、手持式设备、多处理器系统、基于微处理器的或可编程消费电子设备、网络PC、小型计算机、大型计算机、移动电话、PDA、寻呼机、路由器、交换机等等。本发明也可在其中通过网络链接(或者通过硬连线数据链路、无线数据链路，或者通过硬连线和无线数据链路的组合)的本地和远程计算机系统两者都执行任务的分布式系统环境中实施。在分布式系统环境中，程序模块可以位于本地和远程存储器存储设备二者中。

[0339] 替换地或附加地，此处描述的功能可以至少部分由一个或多个硬件逻辑组件来执行。例如、但非限制，可使用的硬件逻辑组件的说明性类型包括现场可编程门阵列(FPGA)、程序专用的集成电路(ASIC)、程序专用的标准产品(ASSP)、片上系统系统(SOC)、复杂可编程逻辑器件(CPLD)、等等。

[0340] 本发明可以以其他具体形式来体现，而不背离其精神或特征。所描述的实施例在所有方面都应被认为仅是说明性而非限制性的。从而，本发明的范围由所附权利要求书而非前述描述指示。落入权利要求书的等效方案的含义和范围内的所有改变应被权利要求书的范围所涵盖。

标题	发布/更新时间	阅读量
一种面向外国人的服药辅助管理系统	2020-05-08	35
一种用于智能印章机的文档管理方法及其系统	2020-05-13	393
一种智能推荐医疗器械的方法、系统和设备	2020-05-13	772
一种计算机软件分析系统	2020-05-14	660
一种基于Android的CORS账号管理系统及其设计方法	2020-05-16	975
基于语音识别和交互的酒店人证查验入住系统及方法	2020-05-19	717
代码管理系统的同步方法及装置、存储介质及终端	2020-05-17	633
一种电话营销呼叫内容记录管理系统	2020-05-14	872
智能旅游终端机的旅游服务智能控制方法	2020-05-14	547
图书翻译智能管理系统用主机	2020-05-18	808

包含受信执行环境的主机的证明

包含受信执行环境的主机的证明

该功能需要专业版企业版VIP权限，您可以：