可信度量系统及相关方法和设备与流程

1.本技术的实施例涉及可信计算技术领域，尤其涉及一种可信度量系统及相关方法和设备。


背景技术：

2.可信计算作为信息安全领域一个新的发展方向受到越来越多公司和研究机构的重视。可信计算的主要目标是构建一个用户可以预期的计算环境，从而保证计算资源不会被恶意篡改、盗取，保证系统和应用的完整性，从而确定系统或软件运行在预期的可信状态。可信和安全是相辅相成的，可信是安全的基础。
3.可信度量可以在运行固件代码之前对待度量对象进行完整性度量，确保待度量对象未被篡改。然而，可信度量存在度量主体传递的问题，从而影响安全性。


技术实现要素：

4.本技术实施例公开了一种可信度量系统及相关方法和设备，能够提升电子设备间的安全性。
5.本技术第一方面公开了一种可信度量系统，应用于电子设备中，可信度量系统包括可信度量子系统和可信平台控制模块，可信度量子系统用于获取电子设备中的待度量对象的待度量数据，可信平台控制模块用于根据待度量数据生成度量结果；可信度量子系统包括可信平台控制模块接口、协议模块、需求执行模块，其中，可信平台控制模块接口与协议模块和电子设备中的可信平台控制模块连接，协议模块与需求执行模块连接；可信平台控制模块接口与可信平台控制模块进行通信；协议模块用于处理可信度量子系统与可信平台控制模块间的通信协议；需求执行模块用于获取电子设备中的待度量对象的待度量数据。
6.本技术实施例可以解决主动度量的度量主体传递的问题，避免将可信度量子系统作为度量代理，减少度量主体，可信度量子系统作为基础固件不承担度量或验证任务；由可信平台控制模块主动度量主动控制，从而提升整个系统的安全性。通过采用该技术方案，可信度量子系统不承担度量和验证任务，从而减少度量主体和控制权传递，提升整个系统的安全性。可信度量子系统通过可信平台控制模块接口、协议模块、需求执行模块间的相互配合，获取待度量对象的待度量数据。
7.在一些可选的实施方式中，可信平台控制模块接口包括设备驱动部分和收发接口功能抽象部分，设备驱动部分用于实现可信度量子系统与可信平台控制模块之间的通信，收发接口功能抽象部分用于屏蔽设备驱动部分中的不同硬件设备驱动的差异。
8.通过采用该技术方案，可以实现可信平台控制模块接口，屏蔽设备驱动部分中的不同硬件设备驱动的差异。
9.在一些可选的实施方式中，协议模块包括协议解析子模块和协议封包子模块，协议解析子模块用于解析可信度量子系统发送的协议的协议结构和校验可信度量子系统发
送的协议的协议内容，协议封包子模块用于封装待度量数据。
10.通过采用该技术方案，可以实现协议的解析和度量数据的封装，便于实现待度量数据的获取，和控制请求的发送。可信平台控制模块通过协议的方式与可信度量子系统进行交互，便于通过扩充协议增加需要度量的内容和其他功能，提升场景适应性。
11.在一些可选的实施方式中，需求执行模块包括多个执行子模块，执行子模块用于初始化待度量对象和读取待度量对象的待度量数据。
12.通过采用该技术方案，不同的执行子模块对应不同的待度量对象，可以实现对不同待度量对象的初始化，和对不同待度量对象的待度量数据的读取。
13.在一些可选的实施方式中，响应于可信平台控制模块的度量请求，可信度量子系统进行可信度量，包括：可信平台控制模块接口接收可信平台控制模块的度量请求；协议模块根据度量请求确定度量请求对应的待度量对象；需求执行模块根据待度量对象获取待度量数据；协议模块对待度量数据进行封包；可信平台控制模块接口将封包的待度量数据发送给可信平台控制模块。
14.通过采用该技术方案，可信度量子系统不承担度量和验证任务，从而减少度量主体和控制权传递，提升整个系统的安全性。通过可信平台控制模块接口、协议模块、需求执行模块间的相互配合，获取待度量对象的待度量数据。此外，还可以根据可信平台控制模块的动态的度量请求，实现对待度量对象的动态度量。
15.在一些可选的实施方式中，可信度量子系统还包括控制响应模块，控制响应模块用于根据控制类型控制电子设备中的待控制对象。
16.通过采用该技术方案，可信度量子系统可以实现对待控制对象的控制。
17.在一些可选的实施方式中，可信度量子系统执行可信平台控制模块的控制请求，包括：可信平台控制模块接口接收可信平台控制模块的控制请求；协议模块根据控制请求确定控制请求对应的待控制对象和控制类型；控制响应模块根据控制类型控制待控制对象。
18.通过采用该技术方案，可信度量子系统可以实现对待控制对象的控制。
19.在一些可选的实施方式中，可信平台控制模块与可信度量子系统连接，可信平台控制模块包括可信度量子系统接口和引擎。
20.在一些可选的实施方式中，可信平台控制模块发起主动度量，包括：获取度量策略；根据度量策略向可信度量子系统发送度量请求；接收可信度量子系统返回的待度量数据；根据待度量数据生成度量结果。
21.通过采用该技术方案，可信平台控制模块可以对待度量对象进行主动度量，避免度量主体，从而提升整个系统的安全性。此外，可信平台控制模块还可以动态度量待度量对象，避免待度量对象已经更新或篡改，而可信平台控制模块无法及时检测到的情况发生。
22.在一些可选的实施方式中，在可信平台控制模块根据待度量数据生成度量结果之后，可信平台控制模块通过引擎根据度量结果和控制策略生成控制请求；可信平台控制模块将控制请求发送给可信度量子系统。
23.通过采用该技术方案，可信平台控制模块可以对待度量对象进行主动控制，避免控制权传递，从而提升整个系统的安全性。
24.本技术第二方面公开了一种可信度量子系统，应用于电子设备中，可信度量子系
统包括可信平台控制模块接口、协议模块、需求执行模块，其中，可信平台控制模块接口与协议模块和电子设备中的可信平台控制模块连接，协议模块与需求执行模块连接；可信平台控制模块接口与可信平台控制模块进行通信；协议模块用于处理可信度量子系统与可信平台控制模块间的通信协议；需求执行模块用于获取电子设备中的待度量对象的待度量数据；可信度量子系统用于获取电子设备中的待度量对象的待度量数据。
25.可信度量子系统为可信平台控制模块提供相应机制，进行相应资源的获取和控制行为的执行，为可信平台控制模块提供主体度量和主动控制的基础。可信度量子系统通过运行时服务的方式响应可信平台控制模块的请求，可以实现对待度量对象的动态度量。避免待度量对象已经更新或篡改，而可信平台控制模块无法及时检测到的情况发生。
26.在一些可选的实施方式中，可信平台控制模块接口包括设备驱动部分和收发接口功能抽象部分，设备驱动部分用于实现可信度量子系统与可信平台控制模块之间的通信，收发接口功能抽象部分用于屏蔽设备驱动部分中的不同硬件设备驱动的差异。
27.在一些可选的实施方式中，协议模块包括协议解析子模块和协议封包子模块，协议解析子模块用于解析可信度量子系统发送的协议的协议结构和校验可信度量子系统发送的协议的协议内容，协议封包子模块用于封装待度量数据。
28.在一些可选的实施方式中，需求执行模块包括多个执行子模块，执行子模块用于初始化待度量对象和读取待度量对象的待度量数据。
29.在一些可选的实施方式中，响应于可信平台控制模块的度量请求，可信度量子系统进行可信度量，包括：可信平台控制模块接口接收可信平台控制模块的度量请求；协议模块根据度量请求确定度量请求对应的待度量对象；需求执行模块根据待度量对象获取待度量数据；协议模块对待度量数据进行封包；可信平台控制模块接口将封包的待度量数据发送给可信平台控制模块。
30.在一些可选的实施方式中，可信度量子系统还包括控制响应模块，控制响应模块用于根据控制类型控制电子设备中的待控制对象。
31.在一些可选的实施方式中，可信度量子系统执行可信平台控制模块的控制请求，包括：可信平台控制模块接口接收可信平台控制模块的控制请求；协议模块根据控制请求确定控制请求对应的待控制对象和控制类型；控制响应模块根据控制类型控制待控制对象。
32.本技术第三方面公开了一种可信平台控制模块，应用于电子设备中，可信平台控制模块包括可信度量子系统接口和引擎。
33.在一些可选的实施方式中，可信平台控制模块发起主动度量包括：可信平台控制模块获取度量策略；可信平台控制模块根据度量策略向可信度量子系统发送度量请求；可信平台控制模块接收可信度量子系统返回的待度量数据；可信平台控制模块根据待度量数据生成度量结果。
34.在一些可选的实施方式中，在可信平台控制模块根据待度量数据生成度量结果之后，可信平台控制模块通过引擎根据度量结果和控制策略生成控制请求；可信平台控制模块将控制请求发送给可信度量子系统。
35.本技术第四方面公开了一种可信度量方法，应用于电子设备的可信度量子系统，电子设备包括可信平台控制模块，可信度量方法包括：接收可信平台控制模块的度量请求；
对度量请求进行解析；根据解析后的度量请求确定度量请求对应的待度量对象和执行子模块；通过确定的执行子模块根据待度量对象获取待度量数据；将待度量数据进行封包；将封包的待度量数据发送给可信平台控制模块。
36.在一些可选的实施方式中，可信度量方法还包括：检测当前运行模式是否支持可信平台控制模块的模式；若当前运行模式支持可信平台控制模块的模式，初始化可信平台控制模块。
37.在一些可选的实施方式中，可信度量方法还包括：通过可信度量子系统的可信平台控制模块接口接收可信平台控制模块的度量请求，实现可信平台控制模块接口包括：初始化可信平台控制模块接口的设备驱动部分；建立可信平台控制模块与可信度量子系统的底层数据收发通道；基于底层数据收发通道，根据可信平台控制模块与可信度量子系统的协议特征确定收发接口功能抽象部分；封装收发接口功能抽象部分，得到待调用接口。
38.在一些可选的实施方式中，在将封包的待度量数据发送给可信平台控制模块之后，可信度量方法还包括：接收可信平台控制模块的控制请求；根据控制请求确定控制请求对应的待控制对象和控制类型；根据控制类型控制待控制对象。
39.在一些可选的实施方式中，通过可信度量子系统的协议模块对度量请求进行解析，通过协议模块将待度量数据进行封包包括：判断可信度量子系统是否存在待处理协议；若存在待处理协议，根据待处理协议的来源判断对度量请求进行解析或将待度量数据进行封包。
40.在一些可选的实施方式中，在通过确定的执行子模块根据待度量对象获取待度量数据之前，可信度量方法还包括：通过可信度量子系统的需求执行模块调用确定的执行子模块；根据调用参数确定待度量对象的目标路径；根据目标路径加载待度量对象对应的驱动；基于待度量对象对应的驱动定位待度量对象；将待度量对象加载至电子设备的内存。
41.在一些可选的实施方式中，在将待度量对象加载至电子设备的内存之后，可信度量方法还包括：调用可信度量子系统的协议模块对待度量对象的待度量数据进行反馈。
42.本技术第五方面公开了一种可信度量方法，应用于电子设备的可信平台控制模块，电子设备包括可信度量子系统，可信度量方法包括：获取度量策略；根据度量策略向可信度量子系统发送度量请求；接收可信度量子系统返回的待度量数据；根据待度量数据生成度量结果。
43.在一些可选的实施方式中，在根据待度量数据生成度量结果之后，可信度量方法还包括：通过可信平台控制模块的引擎根据度量结果和控制策略生成控制请求；将控制请求发送给可信度量子系统。
44.本技术第六方面公开了一种可信度量方法，应用于电子设备，电子设备包括可信度量子系统和可信平台控制模块，可信度量方法包括：可信平台控制模块获取度量策略；可信平台控制模块根据度量策略向可信度量子系统发送度量请求；可信度量子系统根据度量请求获取待度量对象的待度量数据；可信度量子系统将待度量数据发送给可信平台控制模块；可信平台控制模块根据待度量数据生成度量结果。
45.在一些可选的实施方式中，在可信平台控制模块根据待度量数据生成度量结果之后，可信度量方法还包括：可信平台控制模块根据度量结果和控制策略生成控制请求；可信度量子系统接收可信平台控制模块的控制请求；可信度量子系统根据控制请求确定控制请
求对应的待控制对象和控制类型；可信度量子系统根据控制类型控制待控制对象。
46.本技术第七方面公开了一种电子设备，包括处理器和存储器；存储器，用于存储指令；处理器，用于调用存储器中的指令，使得电子设备运行可信度量系统，或使得电子设备执行的可信度量子系统，或使得电子设备执行的可信平台控制模块，或使得电子设备执行的可信度量方法。
47.本技术第八方面公开了一种计算机可读存储介质，计算机可读存储介质存储有至少一个指令，至少一个指令被处理器执行时实现可信度量系统的可信度量方法。
附图说明
48.图1为tpcm系统架构示意图。
49.图2为支持tpcm的uefi架构。
50.图3为本技术实施例提供的支持tpcm的uefi架构。
51.图4为本技术实施例提供的tpcm接口。
52.图5为本技术实施例提供的协议模块。
53.图6为本技术实施例提供的需求执行模块。
54.图7为本技术实施例提供的度量和控制流程图。
55.图8为本技术实施例提供的可信度量系统的启动流程图。
56.图9为本技术实施例提供的pcie设备驱动流程图。
57.图10为本技术实施例提供的协议处理流程图。
58.图11为本技术实施例提供的osloader度量准备流程图。
59.图12为本技术实施例提供的osloader执行响应流程图。
60.图13为本技术实施例提供的电子设备的示意图
具体实施方式
61.需要说明的是，本技术实施例中“至少一个”是指一个或者多个，“多个”是指两个或多于两个。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b可以表示：单独存在a，同时存在a和b，单独存在b的情况，其中a，b可以是单数或者复数。本技术的说明书和权利要求书及附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不是用于描述特定的顺序或先后次序。
62.为便于理解，下面对相关术语进行简要说明。
63.基本输入输出系统(basic input output system，bios)：bios是一组被固化到主板(单板)上，为电子设备提供最低级的硬件控制程序，负责初始化硬件，自检，硬件中断处理，程序服务请求，分配基本资源，屏蔽硬件差异并引导操作系统的固件。bios的作用是初始化硬件和提供硬件的软件抽象及引导操作系统(operating system，os)；并完成探测、训练(training)、枚举等工作；bios采用汇编语言编写，开发和维护门槛比较高。
64.可扩展固件接口(unified extensible firmware interface，uefi)：uefi是bios的替代物，uefi既是一个标准也是一个实现方案的名称，非盈利性组织uefi联盟制定和维护uefi系列规范，按照该规范提供的实现方案也简称uefi，有时候为了便于理解也称uefi为uefi bios。
65.可信平台控制模块(trusted platform control module，tpcm)：一种可集成在可信计算平台中，用于建立和保障信任源点的基础核心模块，为可信计算平台提供主动度量、主动控制、可信认证、加密保护、可信报告等功能。
66.可信密码模块(trusted cryptography module，tcm)：可信计算平台的硬件模块，为可信计算平台提供密码运算功能，具有受保护的存储空间。
67.可信平台模块(trusted platform module，tpm)：国际可信计算组织定义的一款安全芯片标准，提供密码算法、安全存储、完整性度量、签名认证。
68.操作系统装载器(os boot loader，osloader)：用于引导操作系统的装载器，包括linux boot loader(elilo.efi)，windows os loader(winload.efi)，x86-64 pc(bootx64.efi)，x86-32 pc(bootia32.efi)，itanium(bootia64.efi)，32位arm aarch32(bootarm.efi)，64位arm aarch64(bootaa64.efi)等。
69.oprom：uefi平台初始化阶段被uefi固件执行的一段存储在外插板卡上的固件；oprom通常可以包括各种固件驱动程序，例如显卡上的vbios、以太网适配器的预启动执行环境(preboot execute environment，pxe)启动驱动程序和冗余磁盘阵列(redundant array of independent disks，raid)控制器上的存储驱动程序。
70.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。
71.关于可信计算，国际采用tpm，国内主流采用tpcm。tpm作为主cpu的外部设备，由bios启动，然后创建信任根，执行度量行为并存储平台配置寄存器(platform configuration register，pcr)和日志，采用上一级度量下一级的方式，需要上层的操作系统或者应用程序检查度量结果。国内采用的tpcm为双系统，tpcm与tpm有着本质上的差别。下面分别介绍。
72.intel、微软主导的可信计算tpm标准工作在“被动”模式；tpm属于平台上普通外部设备，针对intel x86，tpm一般采用串行外设接口(serial peripheral interface，spi)，lpc(low pin count bus)，集成电路总线(inter-integrated circuit，i2c)等接口与计算机主板南桥(ich，pch)连接。在计算机上电启动过程中，主cpu先于tpm启动执行，完成北桥和内存初始化后，再初始化南桥，然后初始化tpm。tpm启动后利用其提供的可信存储根、可信报告根、可信度量根及其密码算法和pcr等，配合bios为平台提供可信计算支撑。相对主cpu而言，tpm属于外部设备，工作在“被动”模式，若bios在早期被攻陷，可绕过tpm的防护。
73.针对tpm“被动”模式的缺陷，提出了tpcm，tpcm标准工作于“主动”模式。tpcm的核心思想包括：防护部件tpcm独立于计算部件执行，为可信计算平台提供具有主动度量和主动控制特征的可信计算防护功能，实现运算的同时进行安全防护，使计算结果总是与预期一致，计算全程可控可测，不被干扰的目标。tpcm支撑的可信计算平台中，tpcm应是平台中第一个上电运行的部件，在平台从引导到正常工作的整个过程中，tpcm应并行于宿主计算组件独立工作并不受其影响，是可信计算功能支撑的基础部件，是可信计算平台的信任源点。
74.如图1所示，为tpcm系统架构示意图。根据tpcm核心思想，tpcm属于防护部件，主动
度量计算部件，包括主动度量bios，osloader，oprom等待度量对象，tpcm是一个庞大的体系，涉及到计算机系统的各个部件，由于需要使用国密算法，所以涉及到密码算法和签名验证的地方均需要对应的修改，整个体量非常庞大，本案主要集中在主动度量系统固件部分，其中bios/osloader/oprom等是系统固件最主要的部分。
75.按照tcg关于tpm相关理论，bios作为执行度量的主体，由bios访问osloader，oprom等bios flash以外的资源，并由bios执行度量行为；tpcm主动度量osloader，oprom需要bios系统具备相关机制，响应tpcm主动度量要求，将待度量对象(osloader、oprom等)发送给tpcm，由tpcm度量并基于执行策略进行主动控制，bios根据度量结果或者tpcm控制行为进行对应的初始化动作。
76.如图2所示，为支持tpcm的uefi架构。uefi(或bios)负责屏蔽硬件差异并引导os，技术复杂度高，代码量大，且基于intel cpu的bios受制于intel ibv限制，uefi修改的技术门槛比较高。如图2所示，tpcm启动完成后验证计算部件uefi(bios)flash上内容的完整性，确认无篡改后，tpcm将释放计算部件控制权给计算部件cpu。计算部件cpu启动uefi，创建c语言执行环节，切换保护模式，初始化内存，初始化部分外部设备，创建uefi度量代理。uefi度量代理根据uefi执行进度，利用tpcm度量外插卡的oprom的完整性或验证合法性等。度量oprom完成后将控制权释放给oprom，外插卡执行自身设备初始化并运行设备功能。uefi度量代理根据uefi执行进度，根据用户选择或设置，利用tpcm度量os loader的完整性或验证合法性，度量或验证通过后将控制权释放给osloader启动对应操作系统，并退出uefi引导阶段。
77.如图2所示的方案中，作为待度量对象的uefi在自身获得执行权限之后，将uefi(bios)自身的一部分重新作为度量执行主体，uefi直接度量osloader和oprom；其本质是将度量功能进行传递，uefi bios被视为扩展度量代理点，未彻底贯彻tpcm主动度量思想。
78.主要原因包括：缺乏合适的自主tpcm硬件，普通采用高速串行计算机扩展总线标准(peripheral component interconnect express，pcie)插卡形式的tpcm，且改造单板硬件走线连接到tpcm，导致相关硬件接口不全；需要bios启动后在bios中建立和tpcm的通信(依赖硬件实现)；tpcm发送的需求及协议需能被uefi bios理解并执行，需bios和tpcm双方进行定制，复杂度高，而当前缺乏相应标准。
79.主要缺点包括：上述方案采用信任传递的方法，传递的链条越长，安全性越低，某一环出现问题会导致后续环节完全失控。uefi相对较开放，一旦uefi被攻破，后续对于osloader和oprom的防护将失效。因tpcm将控制权下放，导致tpcm无法再防护和管控，tpcm无法实时监控，安全性较低。uefi启动过程是上电一次性行为，除提供uefi运行时服务外，在操作系统启动后，uefi其他服务器将完全退出，因此度量osloader和oprom等行为也是一次性行为，难于做到多次的动态度量，比如服务器网卡oprom已在运行时升级，除非下电重启，否则当前方案无法重新度量。将uefi当作度量代理的方式，是技术手段有限的暂时替代性产物，但uefi度量代理度量osloader和oprom的方式与tpcm主动度量主动控制思想偏离；uefi作为度量代理的过程中，tpcm主要提供密码算法支撑及基础硬件，其本质是把tpcm作为普通外部设备，而非tpcm主控。
80.本技术实施例提供一种可信度量系统，应用于电子设备中，可信度量系统包括可信度量子系统和可信平台控制模块，可信度量子系统用于获取电子设备中的待度量对象的
待度量数据，可信平台控制模块用于根据待度量数据生成度量结果。可信度量子系统包括可信平台控制模块接口、协议模块、需求执行模块，其中，可信平台控制模块接口与协议模块和电子设备中的可信平台控制模块连接，协议模块与需求执行模块连接；可信平台控制模块接口与可信平台控制模块进行通信；协议模块用于处理可信度量子系统与可信平台控制模块间的通信协议；需求执行模块用于获取电子设备中的待度量对象的待度量数据。
81.对于可信度量子系统，响应于可信平台控制模块的度量请求，可信度量子系统可以进行可信度量。具体地，可信平台控制模块接口接收可信平台控制模块的度量请求；协议模块根据度量请求确定度量请求对应的待度量对象；需求执行模块根据待度量对象获取待度量数据；协议模块对待度量数据进行封包；可信平台控制模块接口将封包的待度量数据发送给可信平台控制模块。
82.可信度量子系统还包括控制响应模块，控制响应模块用于根据控制类型控制电子设备中的待控制对象。
83.可信度量子系统可以执行可信平台控制模块的控制请求。具体地，可信平台控制模块接口接收可信平台控制模块的控制请求；协议模块根据控制请求确定控制请求对应的待控制对象和控制类型；控制响应模块根据控制类型控制待控制对象。
84.对于可信平台控制模块，可信平台控制模块与可信度量子系统连接，可信平台控制模块包括可信度量子系统接口和引擎。可信平台控制模块可以发起主动度量。具体地，可信平台控制模块通过可信度量子系统接口获取度量策略；根据度量策略向可信度量子系统发送度量请求；接收可信度量子系统返回的待度量数据；通过引擎根据待度量数据生成度量结果。
85.在可信平台控制模块根据待度量数据生成度量结果之后，可信平台控制模块通过引擎根据度量结果和控制策略生成控制请求；可信平台控制模块将控制请求发送给可信度量子系统。
86.下面示例性地以一种具体的可信度量系统进行说明。
87.如图3所示，为本技术实施例提供的支持tpcm的uefi架构。本技术实施例提供的支持tpcm的uefi架构主要包括作为防护部件的tpcm部分和作为计算部件的uefi部分。uefi部分(可信度量子系统)包括可信平台控制模块接口、协议模块、需求执行模块、控制响应模块。其中，可信平台控制模块接口与协议模块和电子设备中的可信平台控制模块连接，协议模块与需求执行模块连接；可信平台控制模块接口与可信平台控制模块进行通信；协议模块用于处理可信度量子系统与可信平台控制模块间的通信协议；需求执行模块用于获取电子设备中的待度量对象的待度量数据。tpcm部分(可信平台控制模块)用于根据待度量数据生成度量结果，可信平台控制模块与可信度量子系统连接，可信平台控制模块包括可信度量子系统接口和引擎。
88.tpcm部分根据tpcm度量策略发起主动度量需求，并通过tpcm中的uefi接口发送给uefi；接收uefi部分返回给tpcm的待度量对象；tpcm内部的引擎进行相应的主动度量行为，根据度量策略及基准等生成度量结果，并结合控制策略给出与度量结果对应的控制动作或命令。tpcm部分作为度量行为的发起方和控制行为的发起方，是主动运行模式。
89.uefi部分通过uefi中的tpcm接口接收来自tpcm的度量请求等命令和发送uefi反馈信息；协议模块根据tpcm与uefi之间的协议命令，在进行解析后确定对应的tpcm需求执
行主体，并调用确定的tpcm需求执行主体；根据不同的度量内容执行不同的具体动作以实现tpcm所需。uefi部分可以从外部设备读取待度量资源oprom，将外部设备待度量资源发送给tpcm及对tpcm反馈的控制行为执行对应动作。
90.由于bios flash芯片上的uefi在其启动前已经被tpcm主动度量，故本实施例不需要针对uefi中代码段内容(uefi driver和framework等)进行重复度量，而是针对不在bios flash芯片上且没有被度量的内容进行度量，即度量osloader和oprom等外部存储上将被加载的内容。下面将根据图3中架构，分别针对架构中各核心模块进行描述：uefi中tpcm接口模块、协议模块、需求执行模块和控制响应模块。
91.如图4所示，为本技术实施例提供的tpcm接口。uefi通过tpcm接口与tpcm进行通信。tpcm接口包括设备驱动部分和收发接口功能抽象部分，设备驱动部分用于实现可信度量子系统与可信平台控制模块之间的通信，收发接口功能抽象部分用于屏蔽设备驱动部分中的不同硬件设备驱动的差异。
92.设备驱动部分根据tpcm的硬件接口适配对应的硬件设备驱动，tpcm可采用的硬件接口主要有pcie、spi、lpc、ipmb等方式，设备驱动部分负责实现uefi中与tpcm设备进行通信，数据将以二进制流的方式实现在uefi和tpcm之间的双向流动。
93.收发接口功能抽象部分屏蔽具体硬件设备驱动的差异，实现不同的tpcm硬件接口都可以采用相同的软件协议进行通信，负责形成统一的收发接口函数，当tpcm将度量请求发送给uefi时，uefi通过读取接收接口即可获取tpcm发送的内容；当uefi需要发送待度量内容给tpcm，则调用发送接口将对应数据填入即可。
94.如图5所示，为本技术实施例提供的协议模块。uefi通过协议模块处理uefi与tpcm间的通信协议。如图5所示，协议模块对tpcm输入的协议进行解析和对uefi的待反馈内容进行协议封包。在本技术的实施例中，协议解析具体可包括，但不限于：分析tpcm发送过来的协议结构，理解协议具体内容，校验对应的内容，并根据协议内容所需的资源，将需求分发到对应的执行单元；针对uefi执行完tpcm需求后需要返回对应待度量数据的情况，将待度量数据(比如osloader二进制文件)读取到内存，并将数据按照协议进行数据包的封装，调用tpcm接口的数据发送接口将内容发回给tpcm。
95.如图6所示，为本技术实施例提供的需求执行模块。需求执行模块用于获取所述电子设备中的待度量对象的待度量数据，执行tpcm所需的具体动作。tpcm通过协议发送其需要度量osloader的行为，需要uefi将osloader的二进制文件发送给tpcm，此时需求执行模块中的操作系统装载器子模块将初始化外部存储设备，比如硬盘，调用对应的文件系统，根据用户的设定从可启动电子设备中寻找对应的osloader文件，并将其拷贝到内存中，最终通过协议模块的执行反馈部分和协议封包部分进行协议封包和发送给tpcm。
96.需求执行模块包括多个执行子模块，具体子模块数量及内容根据uefi与tpcm之间的协议而定，比如tpcm需要度量智能网卡的option rom(其中，option rom源自pci/pcie规范，pci option rom又称pci expansion rom，是用于设备初始化和系统boot的code。pci option rom可以被保存在板卡上，或保存在bios的binary里面)，可以通过对应的协议命令发送该需求，而uefi中需要配备对应的读取智能网卡option rom的执行子模块，负责初始化智能网卡对应pcie总线，根据厂商id和设备id定位智能网卡设备，并分配内存和io资源，读取目标文件等。
variable存储标识比特等对是否支持tpcm进行设置；还可以通过检测tpcm硬件相关标记并判断电子设备是否需要运行在支持tpcm的模式。若uefi需支持tpcm功能，则运行tpcm uefi module(可信度量系统)，在该模块中进行tpcm相关初始化、配置、解析、执行与响应。否则，若uefi无需支持tpcm功能，按照传统uefi启动流程进行初始化和引导。
105.通过增加一个tpcm uefi module的形式对tpcm功能进行支持，对原有uefi功能架构及启动流程影响较小，且uefi有利于深度支撑tpcm。
106.在本技术的一个实施例中，电子设备的可信度量子系统通过可信度量子系统的可信平台控制模块接口接收可信平台控制模块的度量请求。具体地，可信平台控制模块接口的实现包括：电子设备的可信度量子系统初始化可信平台控制模块接口的设备驱动部分；建立可信平台控制模块与可信度量子系统的底层数据收发通道；基于底层数据收发通道，根据可信平台控制模块与可信度量子系统的协议特征确定收发接口功能抽象部分；封装收发接口功能抽象部分，得到待调用接口。
107.如图9所示，为本技术实施例提供的pcie设备驱动流程图。tpcm uefi module开始运行后，将开始初始化pcie设备驱动，为简化初始化pcie设备扫描操作，针对特定硬件平台可针对具体pcie插槽(slot)上device id和vendor id进行tpcm相关的pcie初始化，建立uefi与pcie tpcm设备的底层数据收发通道；建立底层数据通道后将根据tpcm与uefi之间的协议特征，确定tpcm功能驱动，tpcm功能驱动可以屏蔽底层设备驱动的差异，对上层形成功能调用接口；tpcm op protocol将封装tpcm功能驱动，采用标准协议的形式形成uefi_tpcm_send()和uefi_tpcm_receive()接口，供其他模块(例如，tpcm)调用；该部分实现将遵循uefi driver model实现有关开始接口(start)，停止接口(stop)，支持接口(supported)。
108.在本技术的一个实施例中，可信度量子系统可以通过可信度量子系统的协议模块对度量请求进行解析。具体地，可信度量子系统通过协议模块将待度量数据进行封包包括：判断可信度量子系统是否存在待处理协议；若存在待处理协议，根据待处理协议的来源判断对度量请求进行解析或将待度量数据进行封包。
109.如图10所示，为本技术实施例提供的协议处理流程图。为支持动态oprom的验证需求，协议模块以uefi运行时服务的方式运行。因对uefi osloader和oprom的度量时，实时性要求并不高，而且物理设备的访问延时时间也不固定，故可采用定期检查相关状态的方式检查是否存在待处理的协议数据，若无需处理则等待预设时间继续检测；若存在协议数据需要处理，则查看其来源，判断该协议数据的请求来源是tpcm(由tpcm发送给uefi，并需要uefi进行处理)或者uefi(由uefi反馈处理结果给tpcm)；若是tpcm发送给uefi的协议数据，则需要根据uefi与tpcm之间的协议解析tpcm的请求并对其分发，比如，若tpcm发送的cmd为0x0a，表示tpcm期望度量osloader；cmd为0x0b，表示期望度量riad option rom；cmd为0x0c，表示期望度量智能网卡option rom。当协议模块解析到tpcm发送的cmd为0x0a时，将调用需求执行模块中的操作系统装载器子模块部分；当协议模块解析到tpcm发送的cmd为0x0b时，将调用需求执行模块中的磁盘阵列oprom处理子模块部分。
110.若协议模块探测到是uefi需要反馈信息给tpcm时，则需要将待反馈的数据结合对应的类型进行信息准备(比如待反馈数据为oprom bin文件，对应类型为riad)，并封装数据包后调用uefi_tpcm_send()将内容反馈给tpcm。执行完对应的动作后，协议模块将重新进
入运行时服务检测与等待状态。
111.在本技术的一个实施例中，在通过确定的执行子模块根据待度量对象获取待度量数据之前，可信度量子系统执行度量准备任务。可信度量子系统通过可信度量子系统的需求执行模块调用确定的执行子模块；根据调用参数确定待度量对象的目标路径；根据目标路径加载待度量对象对应的驱动；基于待度量对象对应的驱动定位待度量对象；将待度量对象加载至电子设备的内存。在将待度量对象加载至电子设备的内存之后，可信度量子系统调用可信度量子系统的协议模块对待度量对象的待度量数据进行反馈。
112.如图11所示，为本技术实施例提供的osloader度量准备流程图。需求执行模块包括多个执行子模块，其中osloader处理功能为其中的一项执行子模块，如图11所示，需求执行模块的核心功能为定位osloader并将对应的内容读取到内存，以便将读取到的内容发送给tpcm。当osloader执行子模块被需求执行模块调用后，将根据调用参数确定osloader的device path，比如其路径为”\efi\boot\bootx64.efi”。随后需要根据osloader所在位置确认其对应的驱动是否已经加载，例如osloader文件位于网络磁盘上或外部usb设备或riad或hdd等，为访问对应物理外置，需要对应设备驱动的支持，若uefi中尚未加载对应驱动则应当先加载对应驱动才能定位osloader。随后需要将远端的osloader装载到系统内存中，此时可以才用uefi的标准服务uefi boot service gbs-》loadimage()加载(load)并重定位(relocation)到系统内存中。当osloader已经存在于本地内存中，则可以调用协议模块执行对应的信息反馈，将osloader bin文件发送给tpcm，并返回对应的状态给tpcm。
113.如图12所示，为本技术实施例提供的osloader执行响应流程图。tpcm完成度量后将根据其内部策略配合度量结果执行对应的控制策略，如果当度量结果遇到严重错误，则tpcm可以直接采取断电重启等强力控制手段；若需要uefi配合执行相应动作，则需要发送对应执行协议给uefi。如图12所示，在度量osloader完成后，需要uefi继续启动操作系统，则tpcm的行为响应模块将被调用，当接收到osloader执行需求后，行为响应模块从内存中匹配已经被gbs-》loadimage()加载(load)并重定位(relocation)的osloader，调用gbs-》startimage()运行osloader，由于osloader是一种特殊类型的应用，通常不会退出或返回；osloader会调用gbs-》exitbootservice()来把平台的控制权从固件交给操作系统，从而启动操作系统，因此在控制器转移前需要调用协议模块的执行反馈，将待启动的信息及osloader执行情况报告给tpcm。
114.本技术实施例中，主动度量由tpcm发起并执行，由uefi提供相应机制进行对应资源的供给并执行控制任务。
115.在本技术的一个实施例中，为兼容支持传统uefi和支持tpcm的uefi，因此在uefi setup增加设置页面，展示tpcm相关信息，及相关控制设置或相关配置。
116.如图13所示，为本技术实施例提供的电子设备的示意图。电子设备130包括存储器1301、处理器1302以及存储在存储器1301中并可在处理器1302上运行的计算机可读指令，例如可信度量程序。处理器1302执行计算机可读指令时实现上述可信度量方法实施例中的步骤。
117.本领域技术人员可以理解，示意图13仅仅是电子设备130的示例，并不构成对电子设备130的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如电子设备130还可以包括输入输出设备、网络接入设备、总线等。
118.所称处理器1302可以是中央处理单元(central processing unit，cpu)，还可以是其他通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现场可编程门阵列(field-programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器1302也可以是任何常规的处理器等，处理器1302是电子设备130的控制中心，利用各种接口和线路连接整个电子设备130的各个部分。
119.存储器1301可用于存储计算机可读指令，处理器1302通过运行或执行存储在存储器1301内的计算机可读指令或模块，以及调用存储在存储器1301内的数据，实现电子设备130的各种功能。存储器1301可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据电子设备130的使用所创建的数据等。此外，存储器1301可以包括硬盘、内存、插接式硬盘，智能存储卡(smart media card，smc)，安全数字(secure digital，sd)卡，闪存卡(flash card)、至少一个磁盘存储器件、闪存器件、只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)或其他非易失性/易失性存储器件。
120.电子设备130集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术实现上述实施例方法中的全部或部分流程，也可以通过计算机可读指令来指令相关的硬件来完成，计算机可读指令可存储于一计算机可读存储介质中，该计算机可读指令在被处理器执行时，可实现上述各个方法实施例的步骤。其中，计算机可读指令包括计算机可读指令代码，计算机可读指令代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读介质可以包括：能够携带计算机可读指令代码的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(rom)、随机存取存储器(ram)等。
121.本实施例还提供一种计算机存储介质，该计算机存储介质中存储有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的可信度量方法。
122.本实施例还提供了一种计算机程序产品，当该计算机程序产品在电子设备上运行时，使得电子设备执行上述相关步骤，以实现上述实施例中的可信度量方法。
123.另外，本技术的实施例还提供一种装置，这个装置具体可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使芯片执行上述各方法实施例中的可信度量方法。
124.其中，本实施例提供的电子设备、计算机存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。
125.通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成
以上描述的全部或者部分功能。
126.在本技术所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，该模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
127.该作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是一个物理单元或多个物理单元，即可以位于一个地方，或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
128.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
129.该集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本技术实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。
130.以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何在本技术揭露的技术范围内的变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以所述权利要求的保护范围为准。