IMA性能评估——论文《Quantitative Analysis of Measurement Overhead for Integrity Verification》

1. 摘要

随着云计算与自治计算的使用，系统中软件栈的完整性验证成为一个关键问题。本文我们分析了IMA的内部行为。IMA利用TPM度量了所有的可执行文件和他们的配置文件。我们的分析表明了IMA存在的两个问题：度量开销与不确定性。为了解决这些问题，我们给出两种新的技术，称为批量扩展（batch extend）与核心度量（core Measurement）。前者用来加速度量并批量地扩展PCR。后者只度量指定指定的可执行文件与配置文件，从而只验证验证者所感兴趣的部分。评估结果显示我们的方案将boot时间从122s减到23s，并且支持原有IMA的能力。

1. 背景

本文我们分析了IMA的内在行为并分析其性能。我们使用i7的计算机，附带有TPM1.2，安装ubuntu系统，内核版本为4.6.4，使用默认的IMA策略来进行完整性度量，并将信息写入PCR10。我们的分析表明了IMA的两个问题，其一是度量开销。当启动后，IMA总共度量2300条记录，启动时间为122s，大致是关闭IMA情况下的8倍。其二是在每次启动时，度量记录的数目并不是一致的，即使我们使用同一个版本同一个系统。这是由于一个启动序列会根据设备状态和调度策略来进行不同的控制流。我们把这个问题称之为度量的不确定性。这会导致每次启动时生成不同的ML，使得完整性度量变得更加复杂。

 

IMA的基本结构如下图所示，可以分为三层：度量目标，度量机制，以及度量结果。Appraisal机制支持本地验证与强制执行，其存储了一系列可执行文件的好的hash（通过扩展属性的方式，key为security.ima）。然后，在执行可执行文件之前，appraisal对该文件进行度量，并与存储的值进行对比，当且仅当值匹配时，才允许执行可执行文件，此外，还使用RSA签名来验证完整性与可认证性。EVM是另外一个支持本地元数据验证的扩展方案。

1. 动机

图二是有无IMA情况下的启动时间。开启IMA时间为122s，无IMA情况下的启动时间为14s。可以看出，IMA并不适合在生产环境中使用。这是本文的第一个动机。

除了启动时间外，我们还记录了启动序列所生成的度量记录的数目。图三显示了20次试验的结果。有趣的是，度量记录的数目每次基本都不一样。我们在进行进一步的分析后发现某些可执行文件只有在某些特定条件下才被执行，比如说当无线不可用时，相关的可执行文件就不会执行。这种不确定性导致了不同的ML。

1. 分析

本节我们首先讨论度量结果，然后根据它们的文件类型进行分类。之后再探究造成长时间度量时间的操作。

图4是度量结果的一个示例。每一行包括6项：序列号、PCR index、模板hash、模板名、内容hash、文件名。

我们使用linux的file命令来对这些度量文件进行分类。图五是分类结果。在2234条记录中，文本文件（如配置文件、xml文件）最多，占44.4%，共享链接库其次，占35.4%，ELF可执行文件、数据、内核模块、脚本分别占6.3%、5.4%、4.9%、2.2%。我们可以看到：1）相对于链接库与配置文件，可执行文件与内核模块比例较少，2）一些缓存文件与PNG文件也被度量了，尽管他们不需要完整性度量。

图六给出了IMA源码的调用关系。IMA建立了四个钩子来进行度量，包括ima_file_check\ima_brpm_check\ima_file_mmap\ima_post_read_file。这些钩子被一些系统调用所调用，如sys_open\sys_execve\init_module。图七给出了IMA的各个钩子的调用频率。调用最多的为ima_file_check，超过一半的共享对象通过ima_file_mmap所调用，而ima_post_read_file很难被调用。

基于此，我们将分析重心定位在ima_file_check上。其包含三个核心操作：计算hash、扩展ML、扩展PCR。图8给出了这三种操作的处理时间。其中PCR extend操作耗时最长，达27ms。这很显著地告诉了我们需要重点关注的操作。

1. 方案

   1. 批量扩展

图9给出了批量扩展方案。我们引入了一个新的控制变量batch_size。值为1时代表着原始的IMA。当设置为m时，代表着每m个才进行一次TPM的扩展。图10给出了batch_size为10的情况下的启动时间。

1. 核心度量

我们首先分析了IMA策略的影响，图11给出了在只启动一个IMA钩子情况下的启动时间以及度量计数器。图11的五根柱子分别代表没有IMA、只启动某一个钩子、启动所有钩子下的实验结果。File_check钩子发生的度量最多。为了解决不确定性问题，我们注意到有些缓存文件、PNG文件、颜色管理文件等是不需要进行度量的，因此，我们引入了新的接口，使得用户能够指定其感兴趣的可执行文件。图12给出了我们的核心度量机制下的度量记录数目，我们设定了只度量/bin、/sbin、/usr/bin、/usr/sbin、/etc、/lib/modules六个目录下的文件。其中前四个为可执行文件，第五与第六个分别为配置文件与内核模块。图12显示了我们的方案满足确定性。图13还给出了各个目录下的度量记录的数目。