Scotch: Combining SGX and SMM to Monitor Cloud Resource Usage【TEE的应用】

作者：Kevin Leach, Fengwei Zhang, and Westley Weimer
发布：RAID
时间：2017

1、系统管理存在调度上的逻辑漏洞，导致资源分配失衡
2、SMM保证SGX在底层的信任以及透明跟踪（即不留痕迹）
3、Scotch把资源分配变得更加准确和透明，并不区分恶意和良性

摘要

对基于云的服务的日益依赖导致人们越来越关注云安全。云提供商必须处理客户对其云基础设施整体安全性的担忧。特别是，越来越多的云攻击以云环境中的资源分配为目标。例如，攻击者可以利用系统管理程序调度程序中的漏洞，有效地从同一系统管理程序上的其他良性guests窃取CPU时间。

在本文中，我们介绍了Scotch，一个在系统管理程序中透明、准确地核算资源消耗的系统。通过将基于x86的系统管理模式与Intel Software Guard Extensions相结合，我们可以确保会计信息的完整性，即使系统管理程序已被逃逸的恶意访客破坏。我们展示了我们可以计算每个任务切换和I/O中断的资源，为在系统管理程序上运行的每个guest提供了丰富详细的资源消耗信息。我们表明，使用我们的系统会产生较小但可管理的开销——每个任务切换或I/O中断大约1μs。我们进一步讨论了通过以随机间隔执行会计可以为我们提出的系统带来的性能改进。最后，我们讨论了这种方法对多种基于云的资源攻击的可行性。

引言

软件和基础设施即服务的日益普及导致了云计算市场的增长。2016年，云计算基础设施的支出预计将达到380亿美元[14]。同时，国家漏洞数据库显示，Xen中有226个安全漏洞，VMWare ESX有99个漏洞，KVM管理程序有98个漏洞[29]。因此，人们对云环境中的安全漏洞更加担忧[20，26]。

此类漏洞已经导致与云资源分配不当有关的漏洞利用。例如，资源释放攻击[35]允许恶意VM访客从受害VM获取一个资源（例如，更多的CPU时间）。类似地，系统管理程序调度器中的漏洞也有记录[32，49]。虚拟机监控程序漏洞可能允许恶意客户免费或以受害者为代价获取云资源。因此，云提供商需要保证使用其基础设施向客户提供服务水平和计费责任[24]。

云提供商利用虚拟化平台，如Xen系统管理程序[18]。资源分配由系统管理程序根据与客户的服务级别相对应的提供商的配置来执行。例如，云提供商可能会为支付更多资金的客户提供更多的CPU时间——这一策略将由系统管理程序的调度器强制执行。然而，利用虚拟机监控程序中漏洞的恶意客户可能能够规避此策略，从而获得比其服务级别所要求的更多的资源。

在本文中，我们介绍了Scotch（安全通信目标，透明云健康），这是一种利用两个x86功能来准确计算虚拟机消耗的资源的技术：系统管理模式（SMM）和软件保护扩展（SGX）。SMM允许对底层操作系统、系统管理程序和guest中的CPU寄存器和内存进行透明访问。SGX允许创建被称为飞地的加密区域，将关键执行与可能受损的系统管理程序或操作系统隔离开来。我们可以使用SMM来跟踪每个访客消耗的资源，以便1）潜在的恶意访客不知道，2）我们可以检测以前未检测到的资源计费攻击。当SMM异步测量资源使用情况时，可以使用SGX将这些信息安全地传递到单个用户空间飞地。SMM和SGX的这种新颖组合实现了一种在虚拟化环境中准确测量和安全通信资源使用信息的新方法。

我们评估了一个基于Xen系统管理程序的技术原型。我们展示了我们的技术大约需要1μs来检查每个上下文切换和中断期间的资源使用情况。我们还展示了如何通过随机选择检查资源消耗的间隔，在多个上下文切换和中断中分摊这种固定的1μs成本。接下来，我们将讨论恶意访客可能窃取的资源数量与我们的技术所产生的开销之间的权衡。最后，我们讨论了Scotch能够提供准确资源会计信息的攻击类型，而其他方法则无法提供。我们注意到，Scotch不会自动决定是否发生恶意活动；对这些技术进行直接的比较研究仍然是未来的工作。

贡献

一种准确透明地测量在系统管理程序下运行的guest虚拟机消耗的系统资源的技术
一种采用Xen所提出技术的原型实现
以及一种对所提出技术原型测量精度和开销的实验评估。

背景

在本节中，我们将讨论与我们提出的技术相关的三个主题。首先，我们介绍了系统管理模式，这是一种内置于基于x86的CPU中的特殊执行模式，允许透明、隔离的执行。其次，我们讨论了Xen虚拟机监控程序以及恶意客户可能利用其获取或滥用云资源的漏洞类型。第三，我们介绍了Intel Software Guard eXtensions（SGX），这是实现我们方法的另一组指令。

SMM

系统管理模式（SMM）是所有x86体系结构中可用的CPU模式。它类似于真实模式和保护模式。最初设计用于促进功率控制，最近的工作利用SMM进行系统自检[28，43]、调试[45]和其他安全任务[44，46]。简而言之，CPU在系统管理中断（SMI）时进入SMM。在SMM中，CPU执行系统管理处理器（SMI处理器），这是一段特殊的代码，从基本输入/输出系统（BIOS）固件加载到系统管理RAM（SMRAM）中，系统管理RAM是系统内存的一个隔离区域[6]。在完成SMI处理程序的执行后，CPU将在保护模式下恢复执行。

我们使用SMM作为一个可信赖的执行环境来实现我们的资源会计功能。自386以来，SMM已在所有x86平台上可用，因此它可广泛用于商品系统。此外，当SMI处理程序执行时，底层操作系统基本上是暂停的。这种孤立的执行为操作系统提供了透明度。我们信任SMM主要有两个原因：1）SMRAM可以被视为安全存储，因为它无法通过保护模式和真实模式访问；2）SMI处理程序只需要一个小的可信代码库，因为它存储在BIOS中，并且在正确配置后无法在引导后进行修改。

SMI处理程序作为BIOS的一部分存储。通常，供应商提供特定于其平台的SMI处理程序代码。系统通电后，BIOS在加载操作系统之前将SMI处理程序代码加载到SMRAM中。加载SMI处理程序后，BIOS通过锁定SMRAM来防止对SMI处理软件的进一步修改。在英特尔和AMD平台上，这是使用一次写入特定型号寄存器（MSR）实现的；在设置特定比特时，不能对SMRAM（或相关联的MSR）进行其他改变。因此，即使系统管理程序完全受损，执行资源核算任务的底层SMI处理程序也将保持不变。默认情况下，SMI处理程序加载到一个4KB的内存区域，称为ASEG段。或者，我们可以将SMI处理程序加载到另一个名为TSEG的内存段中，以分配更多的空间，通常高达8MB。

最后，由于SMRAM在硬件中是隔离的（即，除非CPU处于SMM中，否则MMU无法对其进行映射），因此假设的DMA攻击将无法破坏存储在SMRAM中的资源计费信息。

Xen Credit Scheduler与资源核算

Xen[18]是一个广泛部署的开源系统管理程序。Xen负责多路复用多个独立的客户虚拟机。在云环境中，客户可以根据支付的费用访问具有不同配置的客户虚拟机。例如，客户可能会为配置有更多内存、磁盘空间或标称CPU时间的VM向云提供商支付更多费用。

默认情况下，Xen使用Xen Credit Scheduler[1]来管理CPU时间。信用调度程序为每个需要CPU时间的虚拟CPU（VCPU）分配虚拟信用。根据支付的服务水平，每个VCPU可以获得更多或更少的积分。也就是说，调度器可以根据CPU时间的计费量，将更多的信用分配给一个客户的VCPU，而不是另一个客户。每次上下文切换，调度器都会部分基于VCPU当前拥有的信用数量来决定下一个运行哪个VCPU。虽然Xen还可以使用其他调度器运行（Cherkasova等人[13]提供了一个比较），但Credit调度器是最常用的调度器。

至关重要的是，Xen以一定的时间间隔运行一个助手函数（在sched-credit.cfile中burn_credits），从当前执行的VCPU中扣除信用。简而言之，此函数通过轮询当前执行的上下文来估计一段时间内CPU的使用情况。第7节中讨论的先前研究[24，32，49]已经探讨了与该近似值相关的漏洞。如果恶意访客知道执行burn_credits的间隔，那么访客可以精确地测量时间，并在计入信用之前产生CPU。这样一来，恶意攻击者可能会在不收取费用的情况下使用CPU时间。

此外，Xen在内存中维护每个客户的信用信息（和其他元数据）。逃离虚拟机[15]的访客可能会更改此类数据，从而产生不正确的记账（以及后来的计费）信息。例如，通过更快地从善意的受害者客人身上扣除积分，受害者的CPU消耗量可以超过其实际消耗量。

SGX

Intel SGX是另一组允许在用户空间中创建包围区的新指令集[23]。这些包围区是无法从包围区上下文外部访问的加密内存区域（代码和数据）。SGX允许安全地进行计算，即使操作系统或系统管理程序是恶意的。

SGX旨在确保本地计算的安全；I/O指令在飞地内是非法的。相反，基于SGX的应用程序必须调用（通过OCALL）切换到不受信任的操作系统代码，以代表飞地执行I/O。因此，SGX应用程序无法安全地监控系统上发生的其他活动（例如，通过共享内存或设备I/O）。在本文中，我们使用SMM来测量系统范围内的使用情况，然后通过SGX飞地应用程序将这些信息报告给最终用户。

威胁模型

在本节中，我们将讨论Scotch能够可靠应对的三种类型的攻击：1）调度程序攻击，2）资源干扰攻击，以及3）虚拟机逃逸攻击。这些攻击在表达能力和对系统管理程序的损害方面都有所增加。

Scheduler attacks

我们认为攻击者能够利用虚拟机监控程序调度程序中的漏洞，以牺牲受害虚拟机为代价，为恶意虚拟机获取系统资源。这种方法允许攻击者阻止受害者访问合法的资源，还允许攻击者免费执行昂贵的计算。

图1a显示了非攻击场景，即两个良性的CPU绑定虚拟机在一个物理CPU上竞争CPU时间的潜在时间表。guest 1和2都有相同的时间，当VMM评估要向哪个VM计费时，每个guest 都会被计费其CPU时间的公平份额。然而，如图1b中的攻击场景所示，当VMM试图评估哪个guest 正在运行时，恶意guest 可能会在精确的时间屈服，以避免发生这种情况。因此，恶意虚拟机可能看起来永远不会占用CPU时间。周等人[49]表明，在适当的条件下，这种攻击可以消耗绝大多数CPU时间。

Resource interference attacks

资源干扰攻击是通过利用虚拟机多租户进行的。也就是说，单个虚拟机管理程序上的所有虚拟机guest 都必须共享底层物理资源（例如只有一条系统总线）。聪明的攻击者虚拟机可以执行精确计算的工作负载，这些工作负载可能会影响其他受害者虚拟机的性能，或者只是提高其自身的性能。例如，资源释放攻击[35]通过强制受害者虚拟机释放资源供攻击者使用来工作。例如，受害者可能正在运行Web服务器，在这种情况下，攻击者可以向受害者发送大量请求，导致其阻塞I/O，并为攻击者释放CPU时间。在本文中，我们认为攻击者能够以这种方式降低受害者-访客的性能。

VM Escape attacks

虚拟化技术（如Xen）名义上将客户虚拟机彼此隔离。事实上，通过全硬件虚拟化，每个客户都相信自己可以控制整个系统。然而，漏洞不可避免地会进入管理程序，使恶意访客能够逃离虚拟化环境，并在管理程序上下文中执行任意代码[15，27]。自然，此类攻击可能会对云提供商产生毁灭性影响，可能会将私人或有价值的数据暴露给攻击者。在本文中，我们考虑了一个能够逃离来宾上下文并接管VMM的攻击者【我们假设攻击者在逃离来宾虚拟机环境后可以获得ring 0（即内核）权限】。

在本文中，我们不认为VM会逃脱完全禁用系统的攻击。例如，虚拟机转义攻击很可能会危及系统管理程序并停止执行所有guest，或者攻击者可能试图禁用SMI处理程序中与远程系统的网络通信。这类拒绝服务（DoS）攻击通常会在超时时被检测到，超出了这项工作的范围。相反，我们考虑的是escape攻击，即攻击者能够破坏与资源使用相关的数据结构。

架构

Scotch架构的目标是为云计算系统提供准确透明的资源核算。这是通过资源核算代码来完成的，该代码测量驻留在系统管理程序上的每个访客在每次任务切换和中断期间消耗的资源。我们利用硬件支持提供不可篡改的会计代码和数据存储，以及基于篡改事件的调用。

图2展示了我们的系统架构。我们的方法中有两个或多个系统。首先，一个或多个受保护系统运行虚拟机监视器（VMM）软件，该软件能够托管多个善意或恶意的VM访客。每个受保护系统都可靠地收集关于每个访客的资源消耗信息，并定期将这些信息报告给SGX飞地。SGX飞地存储受保护系统上虚拟机的所有资源消耗信息，以便以恶意访客、操作系统或系统管理程序无法读取或篡改的方式进行进一步处理或分析。在我们实现的Scotch原型中，我们考虑了一台带有一个SGX飞地的受保护机器。

Resource Accounting Workflow

图2中描述的受保护机器负责收集关于每个VM客户机的可靠且防篡改的资源消耗信息，无论是恶意的还是良性的。为了实现这一目标，我们将讨论受保护系统为确保资源会计信息的完整性而采取的五个步骤（图2中标记为1-5）。

在步骤1中，VMM由VM guest通过抢占或超级调用来为I/O请求提供服务。使用硬件支持（见第5节），我们捕获所有此类事件，并执行我们的自定义资源会计代码（表示为步骤2）。请注意，虚拟机客户可能是恶意的，也可能是善意的——我们的方法没有区别，因为我们只是计算准确和防篡改的资源核算，以便善意的客户最终被告知实际消耗的资源。

在上下文切换期间，步骤2调用SMI，导致我们的记帐代码在SMI处理程序中运行。使用进一步的硬件支持，我们可以将某些类型的I/O和事件中断转换为SMI。例如，当虚拟机的时间段过去时，计时器会引发一个中断，告诉VMM更换guest。在Scotch中，我们将这种中断改为调用SMI。调用SMI对于我们的系统提供的会计信息的持续可靠性至关重要。

在步骤3中，我们的记帐代码记录下一个VM guest将运行的VM，以及自上次执行代码（即上次上下文切换事件）以来经过的时间。这些信息记录在系统内存的一个隔离区域中，系统管理程序（或来宾）上下文无法访问该区域。对于I/O事件，我们记录有关正在执行的I/O类型的信息。为了记录CPU时间之外的资源消耗，捕获这些I/O事件可以让我们推断guest是在消耗磁盘还是网络。

在步骤4中，我们的会计代码完成执行并将控制权转回guest。我们不会将控制权交还给系统管理程序，因为受损的系统管理程序可能会更改任务切换事件的结果（参见检查时间到使用时间攻击）。例如，在上下文切换期间，系统管理程序调度程序将选择要运行的新guest 。如果在系统管理程序最终确定调度决策之前执行资源记帐，那么受损的系统管理程序可能会欺骗下一个将运行的guest，执行记帐，然后运行不同的guest。相反，在Scotch中，我们在控制权转移到guest之前调用资源会计代码。在我们的会计代码完成后，控制权直接流向正确的guest。

最后，步骤5表示偶尔完成的任务。逃到系统管理程序的恶意guest可能会损坏数据。特别是，如果这样的攻击者试图隐藏他们消耗的资源，他们可能会破坏我们用来测量每个guest消耗资源的时间的系统管理程序上的计时器。在这种情况下，我们可以使用SMI处理程序代码（步骤2）偶尔从受信任的远程服务器请求时间信息（参见Spectre[43]）。

Cost of Accounting

回想一下，我们的方法调用SMI来可靠地执行我们的资源会计代码。SMI的调用和资源核算代码本身都会在系统管理程序上产生开销。这反过来又会影响系统上guest的性能，即使没有恶意guest在运行。例如，假设一个CPU绑定的工作负载，其中所有guest都消耗了他们分配的所有时间量，添加我们的资源核算代码本质上增加了完成上下文切换所需的时间。因此，部署Scotch意味着接受相关的性能损失，以便获得高精度、防篡改的资源会计信息。

正如我们在第6节中所讨论的，我们还考虑了一种替代方案，通过在不同的时间间隔调用我们的代码来减轻性能影响。理想情况下，我们会在每个可能的任务切换和I/O中断事件上调用我们的记帐代码。然而，我们可以选择每x个这样的事件调用我们的代码，其中x是从1到某个最大间隔的某个随机间隔。从本质上讲，每次发生中断或任务切换时，我们都会掷硬币决定是否调用我们的资源会计代码。这需要将这样的决策代码添加到系统管理程序中，恶意的、转义的guest可能会注意到（或更改）这些代码。然而，我们提出这种方法是为了显著提高不同工作负载的性能。此选项允许云提供商权衡资源核算粒度和开销。

具体的部署和评估见论文

相关工作

在本节中，我们讨论了四个主要的相关工作领域：1）提出帮助云提供商为其客户保证特定服务级别的资源会计技术，2）基于SMM的系统保护技术，3）基于SGX的系统保护技巧，以及4）其他多租户虚拟化研究。

Resource Accounting

Chen等人[12]提出了Alibi，一种可验证的资源会计系统。它在服务提供商的软件平台下放置了一个参考监视器（即嵌套虚拟化）。Jin等人[24]提出了另一种可验证的资源核算机制，用于CPU和内存分配，即使在系统管理程序受损的情况下也是如此。与我们的系统类似，他们的方法也使用SMM作为可信的执行环境来计算资源使用情况。然而，我们的系统在以下方面与以前的工作不同：

1、 通过在每次上下文切换和中断时调用我们的资源核算代码，我们可以为每个guest导出一个细粒度的资源使用情况报告。这使得能够快速识别资源使用方面的差异。相比之下，Jin等人采用了一种轮询技术，该技术需要在得出结论之前运行很长一段时间的分析——如果攻击者试图通过窃取更少的资源来隐身，我们的方法可以用于更快地识别此类行为，可能在几次上下文切换内，具体取决于工作负载。

2、此外，调用资源记帐代码的方式保证了我们不会错过瞬态事件——其他使用轮询进行资源审计的技术可能会错过了解其轮询行为的恶意访客。例如，Wang等人[38]对基于轮询的SMM系统的逃避攻击（即瞬态攻击）进行了系统分析。在这种攻击中，对手可以通过研究其轮询行为来规避防御机制。使用Scotch，如果恶意客户想要CPU时间，控制权必须在某个时刻转移到它，此时我们的SMI处理程序将被调用。

然而，这种保证是以性能为代价的。如第6节所述，我们的资源核算代码在每个任务切换和I/O事件中会产生额外的1μs。我们可以根据最终用户的需求进行调整，而不是以随机间隔调用我们的代码来分摊1μs的成本。最终，1μs的成本对应于最坏情况下0.033%的额外开销，这对于大多数应用来说可能足够低。

3、Scotch不需要嵌套的虚拟化，并在SMM中保留了一个小型的可信代码库（TCB）。相比之下，Alibi[12]带来了更高的开销，大约6%的CPU和700%的I/O，其中大部分是由于嵌套虚拟化。此外，Alibi集成了KVM代码库，显著提高了TCB。

4、最后，Scotch能够在存在能够逃离虚拟化环境的恶意guest的情况下报告准确的会计信息。逃脱的访客可能能够更改系统管理程序记录的资源使用信息（例如，Xen调度器中消耗的信用，以隐藏消耗的CPU时间中的异常情况）。但是，当我们将这些信息存储在SMRAM中时，我们可以在不依赖于存储在系统管理程序中的数据结构的情况下导出资源使用情况的准确报告。

除了学术界的工作外，还引入了几个用于资源核算的工业系统[4，31，36]。例如，亚马逊AWS提供了一种名为CloudWatch[4]的工具，这是一种针对AWS云资源的监控服务，为云应用程序消耗的资源提供全系统的可见性。

基于SMM的方法

据我们所知，只有Jin等人[24]提出了一种基于SMM的云资源会计技术。他们的方法被称为硬件辅助资源会计（HRA）。这种技术受到其对随机轮询的依赖性的限制。通过对当前正在执行的VCPU（以及哪个VM来宾）进行采样，HRA依赖于大样本量来近似VM运行时间的甘特图。此外，HRA依赖于系统管理程序中的数据结构来粗略估计内存消耗。相反，通过测量每个上下文切换和中断的资源消耗，Scotch可以快速确定准确的资源消耗信息。

此外，还有其他几个基于SMM的系统没有直接用于安全报告系统管理程序资源消耗。相反，这些系统专注于检测恶意活动[43]，向操作系统隐藏击键[44]，并保护外围设备[46]。此外，HyperCheck[47]和HyperSentry[8]等系统已用于验证正在运行的系统管理程序的完整性。最后，MalT[45]提出了一个透明的远程调试框架，用于分析能够逃离虚拟机或扎根系统的隐形恶意软件或攻击。除了使用SMM进行防御外，攻击者还将其用于恶意目的，如实现隐秘的rootkit[19，33]。例如，美国国家安全局（NSA）使用SMM构建高级rootkit，如用于Dell的Deitybounce和用于HP Proliant服务器的Ironchef[2]。

基于SGX的系统

以前基于SGX的系统，如Haven[10]，将系统库和库操作系统移植到SGX飞地中，从而形成一个大型TCB。Arnatov等人[7]提出了SCONE，这是Docker的一种安全容器机制，使用SGX保护容器进程免受外部攻击。Hunt等人[21]开发了Ryoan，这是一种基于SGX的分布式沙盒，使用户能够在数据处理服务中对其数据保密。这两篇论文没有提出减少飞地内计算的攻击面或减少SGX寻呼带来的性能开销的技术。Schuster等人[34]开发了VC3，这是一个基于SGX的可信执行环境，用于在云中执行MapReduce计算。

其他VM多租户研究

张等人[48]提出了一类多租户云服务器中的内存拒绝服务攻击，表明恶意虚拟机可能会在基于存储和基于调度的资源中引起争用，从而导致受害虚拟机的性能显著下降。Bates等人[9]讨论了使用侧信道攻击来恢复关于共同驻留的VM guest的私人信息。类似地，Inci等人[22]利用侧信道信息从受害者客户那里获取RSA密钥。本文并没有解决这类攻击。相反，我们关注的是攻击者以牺牲受害者guest为代价，主动尝试为自己消耗更多资源的场景。

未来工作

在第3节中，我们讨论了三类攻击，其中Scotch可以提供准确的资源会计信息。然而，我们也讨论了移植攻击，在这种攻击中，逃逸的VM guest将恶意代码移动到受害者guest中，以便受害者代表恶意guest计算和访问资源。Scotch和类似的会计系统目前无法帮助检测此类攻击，也无法自动判断是否存在恶意攻击活动发生。即使有完全准确的资源消耗信息，在这种情况下，受害者虚拟机也会像正常情况一样消耗资源，因此受害者最终会因攻击者发起的工作而被收取费用。我们认为，此类攻击需要检测逃逸本身（即，检测导致guest逃离虚拟化环境的漏洞或利用漏洞），或者检测良性guest执行的正常工作负载的差异。未来，我们希望将这种检测方法纳入Scotch中。

此外，我们将Scotch视为开发一种保护中断和外围I/O的通用方法的种子。目前，SGX不支持飞地范围之外的任何形式的安全通信。现有的工作，如SGXIO[40]，已经调查了与外围设备的可信I/O路径。Scotch可以针对类似的应用程序——通过在SMM中与外围设备交互，我们有机会在潜在的恶意设备上验证固件，而SGXIO需要信任包含驱动程序的系统管理程序。我们打算探索使用Scotch的SMM和SGX组合来保护I/O。

结语

基于云的虚拟化服务越来越受欢迎，再加上管理程序中越来越多的安全漏洞，迫切需要准确透明的虚拟机资源核算。我们介绍了Scotch，它是一种在基于x86的系统上使用系统管理模式的体系结构，以一种不能被受损的guest或系统管理程序篡改的隔离方式执行资源核算和存储信息。通过计算每个任务切换和I/O中断处的资源，我们的系统在存在某些类型的攻击时是准确的，例如调度程序攻击和资源干扰攻击。Scotch产生的结果与实际情况不到2%，同时在指示性工作负载上产生了0.0016%的开销。由于SMRAM是孤立的，Scotch甚至可以在虚拟机逃避攻击时提供准确的信息。总体而言，Scotch为虚拟机来宾提供了透明、准确的资源核算。