CN116737526A - 一种代码段动态度量方法、装置及电子设备 - Google Patents

Abstract

本申请提供了一种代码段动态度量方法、装置及电子设备，涉及计算机技术领域。该方法包括：对内核和/或用户态进程的内存中的代码段进行度量，以得到第一度量数据；判断第一度量数据和目标基线数据是否一致；在第一度量数据和目标基线数据一致时，对目标基线数据所占的内存区域进行哈希计算，以得到第一摘要值；判断第一摘要值是否能够完成解封；若第一摘要值能够完成解封，确定内核和/或用户态进程的内存中的代码段未被篡改，且目标基线数据未被篡改；若第一摘要值不能完成解封，确定目标基线数据被篡改。由此保证了动态度量时的基线数据的完整性和准确性。

Description

一种代码段动态度量方法、装置及电子设备

技术领域

本申请涉及计算机技术领域，尤其涉及一种代码段动态度量方法、装置及电子设备。

背景技术

近年来，随着数字经济和信息软件产业的不断发展，信息系统所面临的安全风险也日益增长。操作系统作为信息系统的基础，向下对接不同硬件平台接口，向上为应用程序提供运行环境。操作系统安全也是整个信息系统安全的基石，操作系统需要为信息系统的关键资产提供可用性、完整性和机密性的保障。操作系统运行大量的软件，部分软件不可避免地存在漏洞，如配置漏洞、编码漏洞、鉴权漏洞等，这些漏洞一旦被攻击者利用，可能会对系统业务造成严重的影响，如隐私数据泄露、核心机密窃取、业务不可用、造成严重的商业损失等。

绝大部分的软件攻击，都会伴随着系统完整性破坏，如恶意进程运行、配置文件篡改、后门植入等。因此业界提出了操作系统完整性保护技术，指的是从操作系统启动开始，对关键数据进行度量和校验，来保证关键数据不受篡改，从而保证系统运行可预期。当前业界已有的操作系统完整性保护技术有安全启动、度量启动、文件完整性保护等。其中，安全启动/度量启动是指在操作系统启动过程中对操作系统关键文件进行完整性检测；文件完整性保护是指在操作系统运行时对文件进行完整性保护。但这几种完整性保护技术均无法对进程运行时的内存数据进行保护。

发明内容

本申请提供了一种代码段动态度量方法、装置、电子设备、计算机存储介质及计算机程序产品，能够对进程运行时的内存数据进行保护。

第一方面，本申请提供一种代码段动态度量方法，方法包括：对内核和/或用户态进程的内存中的代码段进行度量，以得到第一度量数据；判断第一度量数据和目标基线数据是否一致；在第一度量数据和目标基线数据一致时，对目标基线数据所占的内存区域进行哈希计算，以得到第一摘要值；判断第一摘要值是否能够完成解封；若第一摘要值能够完成解封，确定内核和/或用户态进程的内存中的代码段未被篡改，且目标基线数据未被篡改；若第一摘要值不能完成解封，确定目标基线数据被篡改。

这样，在对内核和/或用户态进程的内存中的代码段进行度量进行动态度量时，基于度量数据和目标基线数据进行对比，并在两者一致时，计算目标基线数据所占的内存区域的摘要值，并通过seal/unseal机制进行保护，从而保证了动态度量时的基线数据的完整性和准确性。示例性的，用户态进程可以由预先设定的白名单数据中获取得到，其中，白名单数据主要用于指定需要进行代码段度量的进程。示例性的，对内核和/或用户态进程的内存中的代码段进行度量，可以理解为：对内核中的代码段进行度量，和/或，对用户态进程的内存中的代码段进行度量；内核和/或用户态进程的内存中的代码段未被篡改，可以理解为：内核中的代码段未被篡改，和/或用户态进程的内存中的代码段未被篡改。

在一种可能的实现方式中，方法还包括：当第一度量数据和目标基线数据不一致，且第一摘要值能够完成解封时，确定内核和/或用户态进程的内存中的代码段被篡改，且目标基线数据未被篡改；当第一度量数据和目标基线数据不一致，且第一摘要值不能够完成解封时，目标基线数据被篡改。

在一种可能的实现方式中，在第一度量数据和目标基线数据不一致时，生成第一度量日志；对第一度量日志进行哈希计算，以得到第一度量日志的摘要值；基于基准扩展值和第一度量日志的摘要值，更新基准扩展值。

在一种可能的实现方式中，方法还包括：响应于获取到的第一指令，第一指令用于指示对第一度量日志进行完整性检查；将第一度量日志逐条计算哈希值，并对得到的哈希值进行扩展计算，以得到第二扩展值；判断第二扩展值与基准扩展值是否一致；若第二扩展值与基准扩展值不一致，确定第一度量日志被篡改；若第二扩展值与基准扩展值一致，确定第一度量日志未被篡改。由此，以确保度量日志的完整性，避免度量日志被篡改的风险出现。

在一种可能的实现方式中，判断第一度量数据和目标基线数据是否一致之前，方法还包括：对用户态进程的内存中的代码段进行度量，以得到目标基线数据；对目标基线数据所占的内存区域进行哈希计算，以得到第二摘要值；基于第二摘要值执行封存操作。由此，以基于第二摘要值实现封存密钥的操作，从而可以使得后续进行解封操作。

在一种可能的实现方式中，还包括：获取用户态进程的静态基线数据；当目标基线数据和静态基线数据不一致时，确定进程的内存中的代码段被篡改，以及生成第二度量日志。示例性的，在获取静态基线数据时可以验证该数据的合法性，以避免该数据被篡改。

在一种可能的实现方式中，获取用户态进程的静态基线数据，具体包括：获取用户态进程对应的可执行文件；获取可执行文件的头信息，以及根据头信息获取可执行文件中包含代码段的目标段；根据头信息获取可执行文件中出现重定位的地址的目标地址列表；对可执行文件中包含代码段的段进行哈希计算，以及在计算过程中去除目标地址列表中的重定位地址对应的数据，以得到静态基线数据。由此，通过识别用户态进程中可能发生变化的代码数据，并跳过度量，提高动态度量技术的适用性。

在一种可能的实现方式中，对用户态进程的内存中的代码段进行度量，具体包括：获取用户态进程的内存中包含代码段的目标段；获取目标段中出现重定位的地址的目标地址列表；对目标段进行哈希计算，以及在计算过程中去除目标地址列表中的地址对应的数据，以得到度量结果(即度量数据)。由此，通过识别用户态进程中可能发生变化的代码数据，并跳过度量，提高动态度量技术的适用性。

在一种可能的实现方式中，对内核的代码段进行度量，具体包括：获取内核中代码段数据的第一起止地址，以及获取内核中发生变更的代码段的第二地址；对第一起止地址范围内的代码段数据进行哈希计算，以及在计算过程中去除第二地址对应的数据，以得到度量结果。由此，通过识别内核中可能发生变化的代码数据，并跳过度量，提高动态度量技术的适用性。

在一种可能的实现方式中，对用户态进程的内存中的代码段进行度量，具体包括：获取用户态进程的内存中包含代码段的M个目标段；针对M个目标段中的任一个目标段，确定任一个目标段对应的x个物理页；当x个物理页中存在脏页时，对任一个目标段进行度量；当x个物理页中不存在脏页时，对x个物理页的页帧号进行哈希计算，得到第一哈希值；判断第一数据结构中是否存在与第一哈希值相同的数据，第一数据结构至少用于存储目标物理页的页帧号的哈希值。目标物理页为已度量的目标段对应的物理页，第一数据结构为在对用户态进程的内存中的代码段开始度量时创建，且在对用户态进程的内存中的代码段结束度量时销毁；若存在，则不对该任一个目标段进行度量；若不存在，将第一哈希值添加至第一数据结构中，以及对任一个目标段进行度量。也即是说，在度量时，对于每个用户态进程，可以先获取该用户态进程的内存中的目标段，然后再针对获取到每个目标段，确定出该目标段对应的物理页，当该目标段对应的物理页中存在脏页时，则对该目标段进行度量，否则，则计算该目标段对应的物理页的页帧号的哈希值，并判断第一数据结构中是否存在该哈希值，若不存在，则对该目标段进行度量，并将计算得到的哈希值记录于第一数据结构中，若存在，则不对该目标段进行度量。由此，实现在对多个用户态进程执行内存度量时，首先根据物理页地址进行重复度量判断，避免冗余度量，可以大幅降低动态度量的消耗时间。

第二方面，本申请提供一种代码段动态度量装置，包括：至少一个存储器，用于存储程序；至少一个处理器，用于执行存储器存储的程序，当存储器存储的程序被执行时，处理器用于执行如第一方面中所提供的方法。

第三方面，本申请提供一种电子设备，该电子设备包括至少一个用于存储程序的存储器和至少一个用于执行存储器存储的程序的处理器。其中，当存储器存储的程序被执行时，处理器用于执行如第一方面中所提供的方法。示例性的，该电子设备可以但不限于为服务器。

第四方面，本申请提供一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，当计算机程序在电子设备上运行时，使得电子设备执行如第一方面中所提供的方法。

第五方面，本申请提供一种计算机程序产品，当计算机程序产品在电子设备上运行时，使得电子设备执行如第一方面中所提供的方法。

第六方面，本申请实施例提供了一种代码段动态度量装置，包括至少一个处理器和接口；至少一个处理器通过接口获取程序指令或者数据；至少一个处理器用于执行程序行指令，以实现第一方面中提供的方法。

可以理解的是，上述第二方面至第六方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

图1是本申请实施例提供的一种代码段动态度量方案的系统架构的示意图；

图2是本申请实施例提供的一种代码段动态度量方案的流程示意图；

图3是本申请实施例提供的一种代码段动态度量方案中构建阶段流程的示意图；

图4是本申请实施例提供的一种由ELF文件生成静态基线数据的流程示意图；

图5是本申请实施例提供的一种度量用户态进程代码段的流程示意图；

图6是本申请实施例提供的一种度量内核中代码段的流程示意图；

图7是本申请实施例提供的一种度量优化方法的流程示意图；

图8是本申请实施例提供的一种完整性证明的过程示意图；

图9是本申请实施例提供的一种代码段动态度量方案的实施过程示意图；

图10是本申请实施例提供的一种代码段动态度量方法的步骤示意图；

图11是本申请实施例提供的一种代码段动态度量装置的结构示意图。

具体实施方式

本文中术语“和/或”，是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。本文中符号“/”表示关联对象是或者的关系，例如A/B表示A或者B。

本文中的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一响应消息和第二响应消息等是用于区别不同的响应消息，而不是用于描述响应消息的特定顺序。

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或者两个以上，例如，多个处理单元是指两个或者两个以上的处理单元等；多个元件是指两个或者两个以上的元件等。

在对本申请实施例进行详细介绍之前，首先对本申请实施例涉及的名词进行解释。

(1)代码段

代码段是指应用程序文件(比如应用程序的可执行文件等)或内核中存放代码指令的部分，应用程序执行时，该部分可以被映射到内存中执行。

(2)动态度量

动态度量是指在系统运行时动态获取程序特征，并对特征使用一定方法计算得到一个可比较的数值，使其可以与基准值进行比较，从而确定系统是否被篡改。

(3)封存/解封(seal/unseal)

封存/解封(seal/unseal)：可信平台模块(trusted platform module，TPM)生成密钥后，支持通过额外的数据(如平台状态寄存器)对密钥进行进一步加密，该步骤称为封存(seal)；只有额外数据与封存(seal)相同时，密钥才能正常解封(unseal)。

(4)静态基线数据

静态基线数据是指在应用程序的二进制文件在发布时，通过提取文件中代码段并计算摘要获得的基准值数据。

(5)动态基线数据

动态基线数据是指在某一时刻提取当前系统中运行的应用程序内存中的代码段，并计算摘要获得的基准值数据。

(6)重定位

重定位是指把程序的逻辑地址空间变换成内存中的实际物理地址空间的过程。

接下来对本申请实施例中的技术方案进行描述。

一般的，如果攻击者利用一些手段修改进程的代码指令，这将可能导致进程被劫持或被植入后门，具有后果影响严重，隐蔽性高的特点。对于这种攻击手段，可以使用代码段动态完整性技术，即对进程的运行时内存中的代码指令数据进行完整性保护。但已有的代码段完整性保护技术往往存在以下短板：

1)对于被度量的内存数据，缺乏可靠的基准值。一方面，对于已有的度量模型，基准数据通常在运行时确定，并不能保证基准值的正确性；另一方面，如果攻击者同时将内存中的基准值进行篡改，可能导致度量对比结果不准确。

2)进程度量时需要计算进程内存代码段中的数据哈希值，当需要度量的进程较多时，会导致度量耗时增长，对用户业务进程的影响较大，同时无法配置较短的度量间隔，导致度量时间窗变长，安全性降低。

3)操作系统中本身存在许多代码段自修改场景，如Linux内核的static key机制、进程的加载时重定位等，对于这些场景，传统的完整性保护技术无法进行度量。

基于上述问题，本申请实施例提供了一种基于Linux操作系统的代码段动态度量方案，通过对内存中用户态进程、内核模块、内核的代码段进行度量，并与基准值进行比较，主动检测代码段篡改攻击。其在技术实现中，针对以上三个短板进行了补齐。具体可以包括以下三个方面：

第一、度量的基线数据在进程文件构建时确定，并需要签名验证合法性；同时在度量中引入基线数据监控模块，在内核处理基线数据时，将数据存放到指定的内存区域，然后由基线数据监控模块计算该内存区域的摘要值，通过TPM芯片的seal/unseal机制进行保护，以保证动态度量基线数据的完整性和准确性。

第二、在对多个用户态进程执行内存度量时，首先根据物理页地址进行重复度量判断，避免冗余度量，可以大幅降低动态度量的消耗时间。

第三、通过识别用户态进程、内核代码段中可能发生变化的代码数据，并跳过度量，提高动态度量技术的适用性。

示例性的，图1示出了一种代码段动态度量方案的系统架构图。如图1所示，该软件架构可以但不限于是基于Linux系统的软件架构。该软件架构可以包括软件层和硬件层。

软件层可以包括用户空间(user space)和内核空间(kernel space)。

用户空间中可以包括上层应用程序、用户态内核接口、静态基线生成工具和完整性证明接口等。示例性的，上层应用程序通过用户空间中的接口可以与内核空间中的DIMcore模块和DIM monitor模块等进行交互，以及与硬件层中的硬件进行交互。示例性的，静态基线生成工具可以在在业务进程构建阶段，构建管理员需要梳理编写度量的白名单，即指定需要进行代码段度量的进程(包括用户态进程、内核模块、内核)，并从构建完成的进程文件中提取代码段，计算摘要值并输出静态基线数据；其中，白名单数据和静态基线数据都包含执行度量功能所需的关键数据，为保证这些关键数据不受篡改，白名单数据和静态基线数据都需要进行签名。

内核空间中可以包括动态完整性度量(dynamic integrity measurement，DIM)核心(core)模块(DIM core模块)和DIM监控模块(DIM monitor模块)。示例性的，DIM core模块可以执行核心的动态度量逻辑，包括白名单解析、静态基线解析、动态基线建立、度量执行、度量日志记录、TPM芯片扩展操作等。DIM monitor模块可以执行对DIM core模块生成的基线数据的监控，实现对动态基线数据的完整性保护。DIM core模块和DIM monitor模块可以提供用户态接口，以由上层业务触发相关功能，也可以由内核定时器配置定时任务.

硬件层可以包括芯片，比如，TPM芯片、TCM芯片等。

继续参阅图1，首先，静态基线生成工具构建静态基线文件和白名单。接着，通过上层应用程序中的度量管理功能模块可以触发基线重建，此时，DIM core模块可以构建出基线数据。另外，通过上层应用程序中的度量管理功能模块可以触发动态度量，此时，DIMcore可以进行动态度量，生成度量日志记录等，以及通过与TPM芯片交互，以进行度量日志完整性保护。通过上层应用程序中的度量管理功能模块还可以进行DIM状态查询、配置(度量周期、启动参数等)等。此外，通过上层应用程序中的完整性证明模块还可以触发与硬件层交互，以基于TPM芯片的平台状态寄存器(platform configuration register,PCR)实现度量结果的完整性保护，通过TPM芯片的seal/unseal机制实现内存中基线数据的完整性保护。

下面基于图1中所示的系统架构，对本申请实施例提供的代码段动态度量方案进行介绍。

示例性的，如图2所示，图2示出了一种代码段动态度量方案的主要流程。如图2所示，该代码段动态度量方案主要包括：动态基线流程、动态度量流程和完整性证明流程。下面分别对这几个流程进行介绍。

(1)动态基线流程

该流程是执行度量功能的首个步骤，可以在度量功能开启时进行。在该流程中，首先，DIM core模块可以对预先构建的静态基线数据和白名单数据进行验签，并导入白名单数据和静态基线数据。接着，DIM core模块可以对白名单数据中指定的需要进行代码段度量的各个进程执行代码段度量，度量结果可以在内存中以动态基线形式存放，从而得到动态基线数据。接着，DIM core模块可以将动态基线数据和静态基线数据进行对比，并将对比结果记录为度量日志，其中，每个进程均可以关联有一个度量日志。接着，DIM core模块可以对分别对各个度量日志进行哈希计算，得到各个度量日志的摘要值，以及将这些摘要值扩展至PCR寄存器。示例性的，将各个度量日志的摘要值扩展至PCR寄存器的过程可以包括：DIM core模块可以将每个进程对应的度量日志的摘要值均传输至TPM芯片，然后，TPM芯片可以分别对其获取到的各个摘要值进行扩展计算，并将计算结果更新至PCR寄存器中。

另外，在DIM core模块生成动态基线数据后，DIM Monitor模块可以对该动态基线数据所占的内存区域进行哈希计算，得到该内存区域的摘要值(即图2中的计算动态基线摘要值的过程)，以及将该内存区域的摘要值发送至TPM芯片(即图2中将计算出的摘要值输出到TPM芯片的过程)。示例性的，该摘要值可以是以文件的形式发送至TPM芯片。TPM芯片获取到DIM core模块发送的内存区域的摘要值后，可以将该摘要值作为基准数据，并通过PCR寄存器执行seal操作，以封存密钥。

在一些实施例中，在该流程之前还可以包括构建阶段流程。在该流程中，主要是构建静态基线数据和白名单数据。如图3所示，在业务进程构建阶段，构建管理员需要梳理编写度量白名单数据，即指定需要进行代码段度量的进程(包括用户态进程、内核模块、内核)，并从构建完成的进程数据中提取代码段，计算摘要值并输出静态基线数据。白名单数据和静态基线数据都包含执行度量功能所需的关键数据，为保证这些关键数据不受篡改，白名单数据和静态基线数据都需要进行签名。通过对白名单数据和静态基线数据分别进行签名，即可以得到签名后的白名单数据和签名后的静态基线数据。示例性的，白名单数据中可以包括所需进行代码段度量的进程的文件路径，由此，通过进程的文件路径以指示所需进行代码段度量的进程。

(2)动态度量流程

该流程可以在动态基线流程执行完成后进行。在该流程中，DIM core模块可以对白名单数据中指定的需要进行代码段度量的各个进程执行代码段度量，并将度量结果(也可以称之为度量数据)与前述动态基线流程中获取到的动态基线数据(也可以称之为目标基线数据)进行对比。如果对比不一致，则说明各个进程的代码段和/或目标基线数据可能被篡改，此时可以将结果记录为度量日志，其中，每个进程均可以关联有一个度量日志；同时将对各个度量日志分别进行哈希计算，得到各个度量日志的摘要值，以及将这些摘要值扩展至PCR寄存器；如果对比一致，则说明白名单数据中指定的需要进行代码段度量的各个进程的代码段未被篡改。

(3)完整性证明流程

该流程可以在动态度量流程结束后进行。在该流程中，DIM monitor模块可以对动态基线流程获取到的动态基线数据(即目标基线数据)所占的内存区域进行哈希计算(即图2中的计算动态基线摘要值的过程)，以得到该内存区域的摘要值，以及将该内存区域的摘要传输至TPM芯片(即图2中将计算出的摘要值输出到TPM芯片的过程)。接着，TPM芯片可以使用该内存区域的摘要值和其内的PCR寄存器，执行unseal操作，以解封密钥。如果解封成功，则说明内存中的动态基线数据(即目标基线数据)没有被篡改；否则说明有篡改行为发生。

另外，TPM芯片还可以对前述动态度量流程获取到的每条度量日志的摘要值执行扩展计算，并将最终的扩展计算值与PCR寄存器对比，以检测度量日志的完整性，从而避免度量结果被篡改。

以上即是对本申请实施例提供的代码段动态度量方案的主要流程的相关介绍。在动态度量过程中，在用户态进程代码段、内核代码段中可能会出现发生变化的代码数据，本申请实施例中可以主动识别并跳过这些数据，从而提升动态度量技术的实用性和准确性。下面对用户态进程代码段和内核态代码段分别进行说明。

(1)对于用户态进程代码段

对于用户态进程文件(比如可执行文件、动态链接库等)的代码段，可能存在加载时重定位的场景，即二进制文件代码段中的相对地址数据在加载后需要替换为实际的内存地址。对于开启地址随机化的场景，最终的实际内存地址无法在构建时确定，因此直接度量会导致内存代码段度量值与二进制文件代码段度量值不一样的情况。为了支持这种度量场景，本申请在解析二进制文件生成静态基线数据，以及度量内存中的代码段时，会主动识别并跳过度量可能发生变化的地址数据。

示例性的，图4示出了一种由ELF文件生成静态基线数据的流程。如图4所示，解析可执行和可链接格式(executable and linking format，ELF)文件生成静态基线数据的流程可以包括：

1)解析ELF文件的头信息，获取ELF文件的段(segment)和节(section)信息。

2)遍历ELF文件的segments，获取属性为只读可执行，且类型为LOAD的segments，即代码段信息。

3)遍历ELF文件的重定位段(relocation sections)，获取重定位地址列表。

4)计算步骤2)获取的segments内容的摘要值，并在计算过程中跳过步骤3)获取的重定位地址对应的数据。计算结果即为该ELF文件的静态基线数据。

换言之，在获取静态基线数据时，可以先获取用户态进程对应的可执行文件。然后，可以获取可执行文件的头信息，以及根据头信息获取可执行文件中包含代码段的段；根据头信息获取可执行文件中出现重定位的地址的目标地址列表；对可执行文件中包含代码段的段进行哈希计算，以及在计算过程中去除目标地址列表中的地址对应的数据，以得到静态基线数据。示例性的，当用户态进程为多个时，这多个用户态进程可以对应一个静态基线数据，且该静态基线数据可以但不限于是由这多个用户态进程各自对应的静态基线数据得到。

示例性的，图5示出了一种度量用户态进程代码段的流程。如图5所示，度量用户态进程代码段的流程可以包括：

1)遍历所有用户态进程的内存空间的虚拟内存空间(virtual memory area，VMA)，获取属性为只读可执行，且为文件映射的VMA，即代码段信息。其中，用户态的进程在运行时，进程的代码段信息可以映射到VMA，因此，可以由VMA中获取到进程的代码段信息。

2)判断映射VMA的文件路径是否在白名单数据内，如果在，则执行后续度量动作，否则继续执行步骤1)的遍历。

3.)解析映射VMA的文件路径中的ELF文件的重定位段(relocation sections)，获取重定位地址列表。

4)计算步骤2)获取的VMA内容的摘要值，，并在计算过程中跳过步骤3)获取的重定位地址对应的数据。计算结果即为进程代码段数据的度量结果。

换言之，在度量时，可以获取每个用户态进程的内存中包含代码段的目标段(即前述的segment)；以及，获取目标段中出现重定位的地址的目标地址列表。最后，对目标段进行哈希计算，以及在计算过程中去除目标地址列表中的地址对应的数据，以得到度量结果(即得到度量数据)。

(2)对于内核代码段

对于内核代码段，部分地址的数据可能由于static keys机制的影响产生跳变，因此在度量内核代码段的过程中，需要解析跳变地址表(jump table)，并在计算时跳过可能发生变更的代码段地址。

示例性的，图6示出了一种度量内核中代码段的流程。如图6所示，度量内核代码段的流程可以包括：

1)获取内核jump table数据的起止地址，并解析获得jump table数组。示例性的，可以通过内核中的符号地址确定内核jump table数据的起止地址。

2)获取内核代码段数据的起止地址。示例性的，可以通过内核中的符号地址确定内核代码段数据的起止地址。

3)计算步骤2)获取的内核代码段数据的摘要值，并在计算过程中跳过步骤1)获取的jump table数组中定义的运行时可能发生变化的数据。计算结果即为内核代码段的度量结果。

举例来说，若内核代码段数据的起止地址为(1,2,3,4,5)，jump table数组中的地址为(2,4,6,7)，在计算时，可以计算地址(1,3,5)对应的内核代码段数据的摘要值，并将该摘要值作为度量结果。

换言之，在度量时，可以先获取内核中代码段数据的起止地址，以及获取内核中发生变更的代码段的第二地址。然后，对起止地址范围内的代码段数据进行哈希计算，以及在计算过程中去除第二地址对应的数据，以得到度量结果(即得到度量数据)。

以上即是对用户态进程代码段和内核态代码段进行度量的介绍。可以理解的是，上述度量过程可以应用在图2中所示的“度量进程代码段”中。

在一些实施例中，在动态度量过程中，对于通常的代码段度量执行逻辑，会遍历每个进程的vma，并对每个处于白名单内的进程和动态库执行度量。然而在这个过程中，可能导致一些重复的度量，原因如下：a)Linux存在写时拷贝机制，父子进程的虚拟内存实际对应的物理内存可能是相同的；b)对于动态库而言，系统中只有一个实例，通过虚拟地址映射到不同的进程地址空间中。

对多个进程执行度量时，实际度量的物理地址区间可能是相同的，这就导致了冗余的度量。针对这个问题，如图7所示，本申请实施例提出以下的优化方法：

1)每次度量开始前，初始化并维护一个用于存放数据的数据结构dig_list。

2)度量每个进程时，首先获取该进程对应的内存中包含代码段的M个目标段。然后，再针对M个目标段中的任一个目标段，获取到该任一个目标段对应的x个物理页。当x个物理页中存在脏页时，则认为可能有篡改行为发生，此时可以对该任一个目标段进行度量。当x个物理页中不存在脏页时，对x个物理页的页帧号进行哈希计算，得到第一哈希值dig_cal。当得到第一哈希值dig_cal后，可以从dig_list获取当前需要进行度量的目标进程对应的历史度量数据dig_ref。如果获取失败，则说明在本次度量过程中，该目标进程是首次度量，将与该目标进程关联的dig_cal插入到dig_list，并正常执行度量动作。如果获取成功，则对比与该目标进程关联的dig_cal和获取到的dig_ref是否相等，如果相等，则说明该目标进程对应的物理地址已经执行过度量，无需再进行度量，否则正常执行度量动作。

3)遍历完一个进程的各个目标段后，可以对下一个进程进行度量。

4)在度量结束后(即遍历完所有的进程后)，销毁dig_list。

在一些实施例中，在动态度量过程中，会将进程代码段的度量结果与内存中的动态基线数据进行对比，以检测是否发生了代码段篡改攻击。然而，如果攻击者在篡改代码段的同时修改了内存中的动态基线数据，就有可能导致此次攻击无法被DIM检测成功。

针对该攻击场景，本申请实施例中，通过引入DIM onitor模块，对内核中存储的动态基线数据的内存区域进行哈希计算，得到该内存区域的摘要值，并将该摘要值输出至动态基线摘要文件中，然后通过TPM芯片的seal/unseal机制进行完整性的基线和度量，从而避免了上述情况出现。

具体地，如图8所示，完整性证明流程是：在动态基线流程，首先，上层应用进程触发DIM core模块动态基线建立，完成后被度量的进程的动态基线数据将保留在指定内存区域中。接着，上层应用进程触发DIM monitor模块度量，DIM monitor模块对动态基线数据所在的内存区域进行哈希计算，得到该内存区域的摘要值，并输出摘要值至动态基线摘要文件中。最后，使用TPM芯片的seal机制生成、加密并封存密钥。

在动态度量流程，首先，上层应用进程触发DIM core模块动态度量，并查询度量日志获取度量结果。接着，上层应用进程触发DIM monitor模块度量，DIM monitor模块对动态基线数据所在的内存区域进行哈希计算，得到该内存区域的摘要值，并输出摘要值到输出至动态基线摘要文件中。最后，上层应用触发完整性证明，使用TPM芯片的unseal机制，只有此时获取到的动态基线摘要文件与seal步骤时的动态基线摘要文件一致，才能正常解封密钥，从而证明动态基线数据的完整性。

以上即是对本申请实施例提供的代码段动态度量方案的介绍。在该方案中，在软件构建阶段，可以对需要进行度量的文件生成静态基线数据，并打包在软件包中。其中，软件包安装过程中，可以在安装进程文件的同时，将静态基线数据放置到指定位置；以及，在软件包卸载/更新过程中，可以控制静态基线数据随进程文件同步卸载/更新。另外，如图9所示，在运行阶段，可以运行一个代码段度量管理进程，向下与DIM子系统和TPM芯片进行交互，进行代码段完整性度量动作，包括动态基线触发、动态度量触发、度量结果查询、完整性证明等；向上与用户界面进行交互，包括读取用户配置的度量参数，以及将度量结果上报回显。

接下来，基于上文所描述的代码段动态度量方案，介绍本申请实施例提供的一种代码段动态度量方法。可以理解的是，该方法是基于上文所描述的代码段动态度量方案提出，该方法中的部分或全部内容可以参见上文对代码段动态度量方案的描述。

请参阅图10，图10是本申请实施例提供的一种代码段动态度量方法的步骤示意图。可以理解，该方法可以通过任何具有计算、处理能力的装置、设备、平台、设备集群来执行。

例如，可以但不限于由服务器执行。如图10所示，该代码段动态度量方法可以包括以下步骤：

在S1001，对内核和/或用户态进程的内存中的代码段进行度量，以得到第一度量数据。

示例性的，可以通过前述图5中所描述的度量流程对用户态进程的内存中的代码段进行度量，以及通过前述图6中所描述的度量流程对内核中的代码段进行度量。示例性的，该步骤可以为前述图2中的动态度量流程中的一个步骤。

示例性的，在对用户态进程的内存中的代码段进行度量时，针对每个用户态进程，可以获取该进程对应的内存中包含代码段的M个目标段。然后，针对M个目标段中的任一个目标段，可以确定该任一个目标段对应的x个物理页。当x个物理页中存在脏页时，则对该任一个目标段进行度量。当该x个物理页中不存在脏页时，则对x个物理页的页帧号进行哈希计算，得到第一哈希值；以及判断第一数据结构中是否存在与第一哈希值相同的数据，第一数据结构至少用于存储目标物理页的页帧号的哈希值。目标物理页为已度量的目标段对应的物理页，第一数据结构为在对用户态进程的内存中的代码段开始度量时创建，且在对用户态进程的内存中的代码段结束度量时销毁。若存在，则不对该任一个目标段进行度量。若不存在，则将第一哈希值添加至第一数据结构中，以及对任一个目标段进行度量。也即是说，在度量时，对于每个用户态进程，可以先获取该用户态进程的内存中的目标段，然后再针对获取到每个目标段，确定出该目标段对应的物理页，当该目标段对应的物理页中存在脏页时，则对该目标段进行度量，否则，则计算该目标段对应的物理页的页帧号的哈希值，并判断第一数据结构中是否存在该哈希值，若不存在，则对该目标段进行度量，并将计算得到的哈希值记录于第一数据结构中，若存在，则不对该目标段进行度量。由此，实现在对多个用户态进程执行内存度量时，首先根据物理页地址进行重复度量判断，避免冗余度量，可以大幅降低动态度量的消耗时间。示例性的，该过程可以是图7中所描述的部分或全部流程。在一些实施例中，对用户态进程的内存中的代码段的度量可以包括对该用户态进程的内存中包含代码段的一个目标段的度量，或者，对该用户态进程的内存中包含代码段的多个目标段的度量，具体可根据情况而定。

在S1002，判断第一度量数据和目标基线数据是否一致。当两者一致时，可以执行S1003；否则，执行S1007。示例性的，目标基线数据可以为前述图2中的动态基线流程中进行度量后生成的动态基线数据。

在S1003，对目标基线数据所占的内存区域进行哈希计算，以得到第一摘要值。

在S1004，判断第一摘要值是否能够完成解封。在获取到第一摘要值后，可以使用第一摘要值执行解封(unseal)操作。当能够完成解封时，则执行S1005，否则，执行S1006。

在S1005，确定内核和/或用户态进程的内存中的代码段未被篡改，且目标基线数据未被篡改。

在S1006，确定目标基线数据被篡改。示例性的，S1003至S1005可以但不限于理解为是图8中所描述的部分或全部流程。示例性的，由于第一摘要值不能完成解封，所以可以确定出目标基线数据已被篡改。在一些实施例中，当前期已确定出内核和/或用户态进程的内存中的代码段未被篡改，但后期又判断出目标基线数据被篡改时，则可以确定前期的判断结果无效，此时可以直接确定出目标基线数据被篡改。在S1007，确定内核和/或用户态进程的内存中的代码段被篡改，和/或，目标基线数据被篡改。示例性的，当第一度量数据和目标基线数据不一致时，可以继续判断第一摘要值能否完成解封，其中，当第一度量数据和目标基线数据不一致，且第一摘要值能够完成解封时，可以确定内核和/或用户态进程的内存中的代码段被篡改，且目标基线数据未被篡改。当第一度量数据和目标基线数据不一致，且第一摘要值不能够完成解封时，确定目标基线数据被篡改。

这样，在对内核和/或用户态进程的内存中的代码段进行度量进行动态度量时，基于度量数据和目标基线数据进行对比，并在两者一致时，计算目标基线数据所占的内存区域的摘要值，并通过seal/unseal机制进行保护，从而保证了动态度量时的基线数据的完整性和准确性。

在一些实施例中，在第一度量数据和目标基线数据不一致时，还可以生成第一度量日志。然后，对第一度量日志进行哈希计算，以得到第一度量日志的摘要值。最后，基于基准扩展值和第一度量日志的摘要值，更新基准扩展值。示例性的，该过程可以理解是前述图2中所描述的动态度量流程中将度量日志扩展至TPM芯片中的部分或全部过程。示例性的，基准扩展值可以是将本次之前生成的度量日志扩展至TPM芯片后得到的值。

在一些实施例中，在获取到指示对第一度量日志进行完整性检查的指令后，可以将第一度量日志逐条计算哈希值，并对得到的哈希值进行扩展计算，以得到第二扩展值。然后，再判断第二扩展值与基准扩展值是否一致。其中，若第二扩展值与基准扩展值不一致，确定第一度量日志被篡改。若第二扩展值与基准扩展值一致，确定第一度量日志未被篡改。

在一些实施例中，在判断第一度量数据和目标基线数据是否一致之前，即在S1002之前，还可以对用户态进程的内存中的代码段进行度量，以得到目标基线数据，以及，对目标基线数据所占的内存区域进行哈希计算，以得到第二摘要值，并基于第二摘要值执行封存操作，由此以完成seal操作。示例性的，得到目标基线数据的过程可以是前述图2中所描述的动态基线流程中生成动态基线数据的过程，该目标基线数据也可以是前述图2中所描述的动态基线流程中生成的动态基线数据。

另外，在该过程中，还可以获取用户态进程的静态基线数据。然后，将静态基线数据与计算得到的目标基线数据进行对比。当目标基线数据和静态基线数据不一致时，可以确定用户态进程的内存中的代码段被篡改，以及生成第二度量日志。示例性的，静态基线数据可以是前述图2中动态基线流程中所描述的静态基线数据。示例性的，获取静态基线数据的过程可以是前述图4中所描述的度量流程得到。示例性的，当确定出用户态进程的内存中的代码段被篡改后，可以进一步的判断目标基线数据对应的摘要值是否能够完成解封，当能够完成解封时，则可以确定度量有效，此时可以确定代码段被篡改，且目标基线数据未被篡改。

基于上述实施例中的描述的方法，本申请实施例还提供了一种代码段动态度量装置。请参阅图11，图11为本申请实施例提供的一种代码段动态度量装置的结构示意图。如图11所示，代码段动态度量装置1100包括一个或多个处理器1101以及接口电路1102。可选的，代码段动态度量装置1100还可以包含总线1103。其中：

处理器1101可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器1101中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器1101可以是通用处理器、神经网络处理器(Neural Network Processing Unit，NPU)、数字通信器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

接口电路1102可以用于数据、指令或者信息的发送或者接收，处理器1101可以利用接口电路1102接收的数据、指令或者其它信息，进行加工，可以将加工完成信息通过接口电路1102发送出去。

可选的，代码段动态度量装置1100还包括存储器，存储器可以包括只读存储器和随机存取存储器，并向处理器提供操作指令和数据。存储器的一部分还可以包括非易失性随机存取存储器(NVRAM)。其中，该存储器可以与处理器1101耦合。

可选的，存储器存储了可执行软件模块或者数据结构，处理器1101可以通过调用存储器存储的操作指令(该操作指令可存储在操作系统中)，执行相应的操作。

可选的，接口电路1102可用于输出处理器1101的执行结果。

需要说明的，处理器1101、接口电路1102各自对应的功能既可以通过硬件设计实现，也可以通过软件设计来实现，还可以通过软硬件结合的方式来实现，这里不作限制。

应理解，上述方法实施例的各步骤可以通过处理器中的硬件形式的逻辑电路或者软件形式的指令完成。

可以理解的是，本申请的实施例中的处理器可以是中央处理单元(centralprocessing unit，CPU)，还可以是其他通用处理器、数字信号处理器(digital signalprocessor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现场可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、晶体管逻辑器件，硬件部件或者其任意组合。通用处理器可以是微处理器，也可以是任何常规的处理器。

本申请的实施例中的方法步骤可以通过硬件的方式来实现，也可以由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成，软件模块可以被存放于随机存取存储器(random access memory，RAM)、闪存、只读存储器(read-only memory，ROM)、可编程只读存储器(programmable rom，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)、寄存器、硬盘、移动硬盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者通过所述计算机可读存储介质进行传输。所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。

可以理解的是，在本申请的实施例中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本申请的实施例的范围。

Claims (14)

1.一种代码段动态度量方法，其特征在于，所述方法包括：

对内核和/或用户态进程的内存中的代码段进行度量，以得到第一度量数据；

判断所述第一度量数据和目标基线数据是否一致；

当所述第一度量数据和所述目标基线数据一致时，对所述目标基线数据所占的内存区域进行哈希计算，以得到第一摘要值；

判断所述第一摘要值是否能够完成解封；

若所述第一摘要值能够完成解封，确定所述内核和/或用户态进程的内存中的代码段未被篡改，且所述目标基线数据未被篡改；

若所述第一摘要值不能完成解封，确定所述目标基线数据被篡改。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

当所述第一度量数据和所述目标基线数据不一致，且所述第一摘要值能够完成解封时，确定所述内核和/或用户态进程的内存中的代码段被篡改，且所述目标基线数据未被篡改；

当所述第一度量数据和所述目标基线数据不一致，且所述第一摘要值不能够完成解封时，所述目标基线数据被篡改。

3.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：

在所述第一度量数据和所述目标基线数据不一致时，生成第一度量日志；

对所述第一度量日志进行哈希计算，以得到所述第一度量日志的摘要值；

基于基准扩展值和所述第一度量日志的摘要值，更新所述基准扩展值。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

响应于获取到的第一指令，所述第一指令用于指示对所述第一度量日志进行完整性检查；

将所述第一度量日志逐条计算哈希值，并对得到的哈希值进行扩展计算，以得到第二扩展值；

判断所述第二扩展值与所述基准扩展值是否一致；

若所述第二扩展值与所述基准扩展值不一致，确定所述第一度量日志被篡改；

若所述第二扩展值与所述基准扩展值一致，确定所述第一度量日志未被篡改。

5.根据权利要求1-4任一所述的方法，其特征在于，所述判断所述第一度量数据和目标基线数据是否一致之前，所述方法还包括：

对所述内核和/或用户态进程的内存中的代码段进行度量，以得到所述目标基线数据；

对所述目标基线数据所占的内存区域进行哈希计算，以得到第二摘要值；

基于所述第二摘要值执行封存操作。

6.根据权利要求5所述的方法，其特征在于，还包括：

获取所述用户态进程的静态基线数据；

当所述目标基线数据和所述静态基线数据不一致时，确定所述用户态进程的内存中的代码段被篡改，以及生成第二度量日志。

7.根据权利要求6所述的方法，其特征在于，所述获取用户态进程的静态基线数据，具体包括：

获取所述用户态进程对应的可执行文件；

获取所述可执行文件的头信息，以及根据所述头信息获取所述可执行文件中包含代码段的段；

根据所述头信息获取所述可执行文件中出现重定位的地址的目标地址列表；

对所述可执行文件中包含代码段的目标段进行哈希计算，以及在计算过程中去除所述目标地址列表中的重定位地址对应的数据，以得到所述静态基线数据。

8.根据权利要求1-7任一所述的方法，其特征在于，所述对用户态进程的内存中的代码段进行度量，具体包括：

获取所述用户态进程的内存中包含代码段的目标段；

获取所述目标段中出现重定位的地址的目标地址列表；

对所述目标段进行哈希计算，以及在计算过程中去除所述目标地址列表中的地址对应的数据，以得到度量结果。

9.根据权利要求1-8任一所述的方法，其特征在于，所述对内核的代码段进行度量，具体包括：

获取内核中代码段数据的第一起止地址，以及获取所述内核中发生变更的代码段的第二地址；

对所述第一起止地址范围内的代码段数据进行哈希计算，以及在计算过程中去除所述第二地址对应的数据，以得到度量结果。

10.根据权利要求1-9任一所述的方法，其特征在于，所述对用户态进程的内存中的代码段进行度量，具体包括：

获取所述用户态进程的内存中包含代码段的M个目标段；

针对所述M个目标段中的任一个目标段，确定所述任一个目标段对应的x个物理页；

当所述x个物理页中存在脏页时，对所述任一个目标段进行度量；

当所述x个物理页中不存在脏页时，对所述x个物理页的页帧号进行哈希计算，得到第一哈希值；

判断第一数据结构中是否存在与所述第一哈希值相同的数据，所述第一数据结构至少用于存储目标物理页的页帧号的哈希值。所述目标物理页为已度量的目标段对应的物理页，所述第一数据结构为在对所述用户态进程的内存中的代码段开始度量时创建，且在对所述用户态进程的内存中的代码段结束度量时销毁；

若存在，则不对所述任一个目标段进行度量；

若不存在，将所述第一哈希值添加至所述第一数据结构中，以及对所述任一个目标段进行度量。

11.一种代码段动态度量装置，其特征在于，包括：

至少一个存储器，用于存储程序；

至少一个处理器，用于执行所述存储器存储的程序，当所述存储器存储的程序被执行时，所述处理器用于执行如权利要求1-10任一所述的方法。

12.一种电子设备，其特征在于，包括：

至少一个存储器，用于存储程序；

至少一个处理器，用于执行所述存储器存储的程序，当所述存储器存储的程序被执行时，所述处理器用于执行如权利要求1-10任一所述的方法。

13.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，当所述计算机程序在电子设备上运行时，使得所述电子设备执行如权利要求1-10任一所述的方法。

14.一种计算机程序产品，其特征在于，当所述计算机程序产品在电子设备上运行时，使得所述电子设备执行如权利要求1-10任一所述的方法。