怎么用asp做网站,展馆展厅设计报价,WordPress免插件添加公告,住建局查询系统摘要
使用现代固态硬盘#xff08;SSD#xff09;的存储中计算使开发人员能够将程序从主机转移到SSD上。这被证明是缓解I/O瓶颈的有效方法。为了促进存储中计算#xff0c;已经提出了许多框架。然而#xff0c;其中很少有框架将存储中的安全性作为首要任务。具体而言…摘要
使用现代固态硬盘SSD的存储中计算使开发人员能够将程序从主机转移到SSD上。这被证明是缓解I/O瓶颈的有效方法。为了促进存储中计算已经提出了许多框架。然而其中很少有框架将存储中的安全性作为首要任务。具体而言由于现代SSD控制器没有可信执行环境被转移到SSD上的恶意程序可能会窃取、修改甚至破坏存储在SSD中的数据。在本文中我们首先调查了存储中计算可能进行的攻击。为了抵御这些攻击我们构建了一个轻量级的可信执行环境名为IceClave用于存储中计算。IceClave利用TrustZone扩展在存储中程序和包括闪存地址转换、数据访问控制和垃圾回收在内的闪存管理功能之间实现安全隔离。IceClave还通过对存储中DRAM的内存完整性验证实现了存储中程序之间的安全隔离而开销很低。为了保护从闪存芯片加载的数据IceClave在闪存控制器中开发了轻量级的数据加密/解密机制。我们使用完整的系统模拟器开发了IceClave。我们使用各种数据密集型应用程序如数据库对IceClave进行评估。与现有的存储中计算方法相比IceClave只引入了7.6%的性能开销同时以最小的硬件成本在SSD控制器中实现了安全隔离。IceClave仍然保持了存储中计算的性能优势比传统的基于主机的可信计算方法提供高达2.31倍的性能。
引言
存储中计算一直是加速数据密集型应用的一种有前景的技术尤其适用于大规模数据处理和分析[15、20、33、39、45、52、56、57、72、81]。它将计算移动到存储设备如基于闪存的固态硬盘SSD中存储的数据附近从而通过显著减少主机和存储设备之间传输的数据量来克服I/O瓶颈。
由于现代SSD在其控制器中采用了多个通用嵌入式处理器和大容量DRAM使得在存储中进行计算成为今天的现实。为了促进存储中计算的广泛采用已经提出了各种框架。例如Willow [72]通过RPC协议使开发人员能够将代码从主机机器转移到SSD上而Biscuit [39]则开发了一个支持多个存储中计算任务的存储中运行时系统遵循MapReduce计算模型。所有这些先前的工作都展示了存储中计算在加速数据处理方面的巨大潜力。然而它们中的大多数[19、33、34、52、56、57、72、82]都侧重于性能和可编程性很少有人将安全性作为设计和实现中的首要任务这对用户数据和SSD设备构成了巨大威胁并进一步阻碍了其广泛采用。
由于存储中处理器独立于主机机器运行并且现代SSD控制器未为在SSD内部运行的程序提供可信执行环境TEE它们对用户数据和闪存芯片构成严重的安全威胁。具体而言一段被转移到存储中的恶意代码可能会(1)篡改闪存传输层FTL中的映射表以破坏闪存芯片的数据管理(2)访问和破坏其他应用程序的数据(3)在运行时窃取和修改共存的存储中程序的内存。
为了克服这些安全挑战正如在现有存储中计算框架[39、72]中开发的那样我们可以通过在SSD控制器的DRAMSSD DRAM中维护特权信息的副本并强制对存储中程序进行权限检查来简化运行时系统。然而这种解决方案仍然存在许多安全漏洞。例如恶意的转移程序可以利用内存漏洞如缓冲区溢出[28、79、88]来提升权限以访问和修改SSD DRAM中FTL的缓存映射表对手可以通过物理攻击如冷启动攻击、总线窃听攻击和重放攻击[67、71、86]窃取和修改共存的存储中程序生成的中间数据和结果。另一种方法是采用英特尔的软件保护扩展SGX作为一种即插即用的解决方案。不幸的是现代存储中处理器架构不支持SGX技术。而且SGX方法仍然存在显著的性能开销[11、25、50、63、70、80]这是存储中计算和SSD控制器目前无法承受的。
因此为存储中计算提供安全、轻量级和可信执行环境是其广泛采用的重要一步。理想情况下我们希望在享受存储中计算的性能优势的同时能够在存储中程序、核心FTL功能和物理闪存芯片之间实现安全隔离如图1所示。
图1理想情况下的存储中计算安全隔离示意图。图示了连接到SSD控制器的主机机器其中包括存储中处理器、SSD DRAM和物理闪存芯片。存储中处理器运行存储中程序并与主机机器和闪存芯片进行通信。
为了解决这些安全挑战我们提出了一种轻量级的可信执行环境IceClave用于存储中计算。IceClave是一种专为现代固态硬盘SSD控制器和存储计算程序设计的可信执行环境TEE。与诸如SGX [25]等通用TEE解决方案不同IceClave专门考虑了闪存属性和存储计算负载特性。IceClave通过确保安全隔离包括以下方面的功能1一种新的内存保护方案以减少由闪存地址转换引起的上下文切换开销2一种优化技术通过利用大多数存储计算应用程序是读密集型的事实来保护存储计算程序的存储DRAM3一种用于安全传输存储处理器和闪存芯片之间数据的流密码引擎具有低性能开销和能量消耗4一种用于管理存储计算TEE生命周期的运行时系统。
具体而言为了实现存储计算程序和FTL图1中的1之间的安全隔离我们扩展了大多数SSD控制器中可用的ARM处理器的TrustZone。IceClave在安全世界中执行核心FTL功能例如垃圾回收和磨损均衡而在正常世界中运行卸载的程序以使卸载的程序无法干预闪存管理。为了以低开销保护FTL的映射表我们在正常世界引入了受保护的内存区域并将映射表放在其中以避免闪存地址转换的上下文切换。因此只有受保护的FTL函数才能更新映射表而卸载的存储计算程序只能通过强制执行的权限检查来读取映射表进行地址转换。
为了实现存储计算程序之间的安全隔离图1中的2**我们构建了存储计算TEE来托管卸载的程序并在数据通信和处理中强制执行数据加密和内存完整性检查。由于大多数存储计算工作负载是读密集型的IceClave主要需要对存储计算生成的中间数据和结果进行完整性检查这对存储计算程序的执行几乎没有性能开销。**为了保护存储在存储计算TEE中运行的存储器页面我们还将轻量级流密码引擎集成到具有最小硬件成本的SSD控制器中。总之我们在本文中做出了以下贡献
我们提出了一种用于存储计算的可信执行环境其中通过扩展TrustZone来保护核心FTL功能。我们通过为SSD DRAM启用轻量级内存加密和完整性验证支持存储计算程序之间的安全隔离。我们展示了IceClave所需的硬件和软件扩展是最小的并且在现代SSD控制器中可行。我们使用SSD FPGA板开发了一个系统原型以定量评估IceClave的开销并使用全系统模拟器进行敏感性分析。
我们使用全系统模拟器gem5 [37]实现了IceClave并将SSD模拟器SimpleSSD [38]和内存模拟器USIMM [21]集成到其中以支持安全的存储中计算。我们还使用真实的OpenSSD Cosmos FPGA板开发了一个系统原型用于验证IceClave的核心功能。我们使用了包括事务性数据库在内的各种数据密集型应用程序来评估IceClave的效率。与最先进的存储中计算方法相比IceClave对存储中运行时间的性能开销仅为7.6%同时对SSD控制器的面积和能源开销增加很少。我们的评估还表明IceClave能够通过提供平均性能提升2.31倍保持存储中计算的性能优势而这比传统的基于主机的计算方法要好得多。
背景
2.1 基于闪存的固态硬盘
快速缩小的工艺技术使得固态硬盘SSD能够提升性能和容量加速了它们在如今的数据中心等普通系统中的应用 [4, 43, 44]。我们在图2中展示了一个典型的SSD架构。一个SSD由三个主要组件组成一组闪存芯片组、一个带有嵌入式处理器和DRAM的SSD控制器以及闪存控制器 [23, 56]。闪存芯片组以层次结构的方式组织。每个SSD有多个通道每个通道被多个闪存芯片组共享。每个芯片组由多个闪存芯片组成。每个芯片有多个平面每个平面又被分成多个闪存块每个块包含多个闪存页。由于闪存的特性在一个空闲的闪存页被写入后该页在未来的写入操作中无法再使用直到该页被擦除。然而擦除操作只能以块为单位进行这是一项耗时的操作。因此写入操作会被发送到已经擦除的空闲页即就地写入而不是等待昂贵的擦除操作。垃圾回收GC稍后会清理SSD中的过时数据。由于每个闪存块的使用寿命有限块的均衡老化即磨损平衡非常重要。SSD采用就地写入、垃圾回收和磨损平衡等技术来克服SSD的缺点并维护用于索引逻辑地址与物理地址映射的间接寻址。所有这些都由SSD控制器中的闪存转换层FTL来管理。
2.2 存储中计算
我们早就意识到传统以CPU为中心的计算对于需要从存储中传输大量数据的数据密集型应用的低效率。应用程序的性能受限于主机和SSD之间低带宽的PCIe接口。为了应对这一挑战提出了各种存储中计算方法 [39, 52, 56, 72, 89]。通过利用SSD处理器和闪存芯片的高内部带宽我们可以处理数据。它们显著的性能优势表明存储中计算是一种有前景的技术。然而由于存储中的处理器是独立于主机运行的它给存储中计算的采用带来了安全挑战特别是在多租户环境中多个应用实例共享物理SSD的情况下 [49, 55, 74–76, 92]。
2.3 存储中的漏洞
当特定代码被迁移到存储中的处理器时特权信息的副本会被传输并保存在SSD控制器的DRAM中 [39, 72]。这种解决方案是在假设迁移的代码已经提前知道所访问数据的地址和大小的情况下开发的。然而攻击者可以利用存储中的软件和固件漏洞如缓冲区溢出 [28, 79, 88] 和总线窃听攻击 [71]实现特权提升。之后它们可以进行各种进一步的攻击。我们在下面列举了一些攻击方式。 • 恶意用户可以通过软件和物理攻击来操纵存储中程序生成的中间数据和输出导致计算结果错误。 • 恶意程序可以拦截SSD中的FTL闪存转换层功能如垃圾回收和磨损平衡并篡改闪存管理。这将导致数据丢失或设备损坏。 • 恶意用户可以通过物理攻击如总线窃听攻击窃取存储在闪存芯片中的用户数据当存储中的程序将数据从闪存芯片加载到SSD DRAM时。 为了防御这些攻击另一种解决方案是为存储中计算开发操作系统或虚拟化层。然而由于SSD控制器的资源有限运行一个完整的操作系统会给SSD带来显著的开销并增加攻击面因为操作系统的代码库庞大。此外这些技术并不足以防御前面提到的诸如板级物理攻击之类的攻击。随着计算越来越靠近存储设备为这种非传统计算范式提供一个轻量级的执行环境非常重要。由于SSD的设计假设是与主机隔离并纯粹用作存储而不是计算现代计算系统并不为存储中计算提供安全的运行环境。正如在第1节中讨论的那样一种直接的方法是采用类似SGX的解决方案 [25, 54]。然而这需要对硬件进行重大改变甚至需要替换现代SSD中的存储处理器。由于SGX是为主机机器开发的通用框架很难实现存储中程序的最佳性能。
3 威胁模型
在本工作中我们针对多租户场景即多个应用实例在共享的SSD上运行。遵循当今云计算的威胁模型 [1, 16, 26, 35]我们假设云计算平台已经为终端用户提供了一个安全通道使其能够将程序迁移到共享的SSD上。相关的代码迁移技术如安全RPC和库 [22, 39, 72]已经在云平台上部署 [1, 48, 91]。然而迁移到SSD上的程序可能包含隐藏的恶意代码。对于存储中计算我们信任SSD供应商他们使得迁移到SSD上的程序能够执行。我们假设硬件供应商没有在其设备中故意植入后门或恶意程序。然而由于我们在共享平台如公共云中部署这些计算性能的SSD我们不信任可能发起板级物理攻击的平台操作员比如总线窃听和中间人攻击或者利用主机机器来窃取或销毁存储在SSD中的数据。类似于SGX的威胁模型我们将软件侧信道攻击如缓存时间、页表侧信道攻击 [62] 和推测执行攻击 [51]排除在威胁模型之外因为这些攻击方法在现实中往往比较麻烦 [25]。我们依靠闪存控制器中提供的纠错码ECC[40, 83] 来确保闪存页的完整性。为了防御来自云计算平台或恶意主机操作系统的攻击通常鼓励用户在将数据存储到SSD之前对其进行加密。然而在存储中计算过程中数据仍然可能被泄露。因此我们对实现IceClave的安全目标采取了更为保守的设计。我们认为我们的威胁模型是现实的。首先作为系统范围的共享资源SSD已经被多个应用广泛使用。现有的存储中计算框架已经使终端用户能够将其程序迁移到SSD上。其次一旦程序被迁移到SSD上存储中程序将逃离主机操作系统的控制在新的执行环境中发起攻击。第三我们的威胁模型考虑了不受信任的平台操作员可能发起的物理攻击。据我们所知这是第一个面向存储中计算的TEE框架。它旨在防御三类攻击1针对共存的存储中程序的攻击2针对核心FTL功能的攻击3针对从闪存芯片加载的数据和存储中程序生成的数据的潜在物理攻击。
4 设计与实现
我们提出了一种用于存储中计算的TEE其性能和硬件成本都很低。我们在图3中展示了IceClave架构的概述。为了实现我们的目标我们提出了扩展ARM TrustZone的方法创建安全世界和普通世界以实现FTL中不同实体的安全隔离和保护同时使用内存加密引擎MEE进行内存加密和验证。
4.1 构建IceClave的挑战
为了开发IceClave我们必须克服三个挑战。 • 首先由于SSD被多个应用共享我们需要确保适当的安全隔离。具体来说我们需要在存储应用程序与FTL之间执行安全隔离并在应用程序与IceClave运行时之间执行隔离§4.2和§4.3。 • 其次为了在运行时保护存储中程序的数据安全IceClave需要确保用户数据在离开闪存芯片时的安全性§4.4。 • 第三SSD控制器的资源有限如DRAM容量和处理能力因此IceClave应该是轻量级的并且不会对存储应用程序的性能产生显著影响§4.5和§4.6。
在接下来的章节中我们将详细讨论如何解决这些挑战。
4.2 保护闪存转换层
由于FTL管理闪存块并控制用户数据映射到每个闪存页因此它的保护至关重要。如果任何恶意的存储应用程序控制了FTL它们可以读取、擦除或覆写其他用户的数据这可能导致严重后果如数据丢失和泄露。IceClave运行时管理着在SSD内初始化每个存储应用程序的方式并维护其元数据例如存储中程序的身份。如果任何存储应用程序能够访问元数据攻击者可以轻松破坏其他存储应用程序的安全性。为了保护FTL和IceClave运行时免受恶意存储应用程序的攻击我们需要确保SSD中不同实体的内存保护。具体而言我们必须确保卸载的应用程序无法访问FTL和IceClave运行时使用的内存区域。我们还需要确保卸载的应用程序在没有适当权限的情况下无法访问彼此的内存区域。为了实现这一点一种直接的方法是使用TrustZone创建安全世界和普通世界然后将FTL功能和IceClave运行时放置在安全世界中将所有存储应用程序放置在普通世界中。然而这将导致存储应用程序的显着性能开销。这是因为当应用程序每次访问一个闪存页时它需要切换到托管FTL和其地址映射表的安全世界。类似地使用类似SGX的方法我们可以将FTL和存储应用程序放置在不同的enclave中但这也会产生显着的性能开销因为我们必须频繁地从一个enclave切换到另一个enclave。为了解决这个挑战我们通过扩展TrustZone将整个物理主存空间划分为三个内存区域普通、受保护和安全。我们在图4中展示了这些内存区域。具体而言我们允许FTL和IceClave运行时在安全世界中执行。它们具有读/写权限以访问整个内存空间。这是必要的因为FTL的核心功能需要管理地址映射表而IceClave运行时需要管理每个存储应用程序例如TEE的创建和删除。我们将存储应用程序放置在普通世界中因此它们无法访问属于FTL或IceClave运行时的任何代码或数据区域。对于普通世界中的受保护内存区域我们使用它来托管共享的地址映射表以便存储应用程序只能读取地址转换的映射表条目而无需支付上下文切换的开销。图5展示了与FTL映射表在安全世界中的方案相比这种优化平均可以提高存储应用程序的性能21.6%。我们将在第4.6节中讨论闪存访问过程及其相关保护的详细信息。我们在图6中展示了内存区域属性的详细信息。根据ARMv8的MMU规范[9]我们使用非安全NS位来指示内存访问是使用安全权限还是普通权限进行的。我们利用访问控制标志AP[2:1]和保留位ES位在图6中来创建受保护的区域在该区域中IceClave向普通世界授予只读权限并向安全世界授予读/写权限。值得注意的是存储内存保护可以在旧版本的ARM处理器[7]中轻松实现只需指定访问控制标志AP[2:0]以及其他处理器如RISC-V请参见第4.7节中的讨论。
4.3 存储程序的访问控制
尽管每个存储程序在访问FTL的映射表时只具有读取访问权限但恶意的存储程序可以探测管理其他存储程序数据地址转换的映射表条目例如通过暴力破解。因此攻击者可以轻松访问其他程序的数据。为了解决这个挑战我们扩展了FTL的地址映射表。我们使用每个条目中的ID位每个条目为8字节来跟踪每个存储TEE的标识并使用它们来验证存储TEE是否具有访问映射表条目的权限。闪存访问的权限检查是通过专用进程执行的。它从存储应用程序接收闪存访问请求并在将请求发送到闪存芯片之前进行权限检查。该进程在普通世界中独占访问闪存芯片防止恶意的存储程序进行未授权的闪存访问。我们默认使用四个位作为ID这会对映射表引入小的存储成本6.25%。IceClave将在其运行时内为新创建的TEE重复使用ID并在TEE创建时设置映射表中的ID位详见第4.6节的详细信息。每个存储程序只能访问FTL的地址映射表和已分配的内存空间。对其他内存位置的访问将导致内存管理单元中的故障。为了进一步增强存储程序的内存保护我们还启用了内存加密和验证功能。
4.4 保护存储DRAM 存储程序将数据从闪存芯片加载到SSD DRAM中进行数据处理。为了隐藏从闪存芯片读取的数据IceClave通过在数据在内部总线上传输之前对访问的数据进行加密来保护数据传输过程。现代SSD已经采用了专用的加密引擎[31]但它主要用于全盘加密。在这项工作中我们在SSD控制器中开发了一个轻量级的流密码引擎用于保护从闪存芯片到存储处理器的数据传输详见第5节的实现细节。尽管我们在SSD DRAM和闪存控制器之间传输数据时启用了数据加密但用户数据包括原始数据、中间数据和生成的结果在运行时仍然可能泄漏。为了解决这个挑战IceClave同时启用了内存加密和完整性验证。
内存加密。内存加密的目标是保护内存访问中的任何数据或代码不被泄漏。为了实现这一目标一种常见的方法是在将缓存行写入内存时对其进行加密。目前最先进的工作通常使用分割计数器加密[12, 80, 90]。它通过使用伪一次性密码OTP对缓存行进行异或来加密缓存行而OTP是通过对计数器进行块密码如AES加密生成的。在每次写回后计数器增加以确保时间上的唯一性。它被编码为主计数器和次计数器的串联。当次计数器溢出时主计数器递增并且所有其他次计数器被重置。相关的内存块也需要重新加密。因此这种加密方案具有显著的性能开销。对于存储计算来说这不是一个太大的问题因为它以读取为主。我们对典型的存储应用程序进行了研究见表4并在运行它们时进行了内存访问次数的剖析见第6.1节的实验设置。我们观察到大多数应用程序在内存写入方面只有很小的部分见表1。这些写入通常是由存储程序在运行时产生的中间数据引起的。基于这个观察我们设计了混合计数器方案。 混合计数器方案的关键思想是我们只对只读页面使用主计数器对可写页面使用传统的分割计数器方案。只要页面是只读的次计数器就不会改变因此我们不需要只读页面的次计数器。在这种情况下我们可以缓存存储更多的计数器对于只读页面每个缓存行可以有八个计数器来提高存储应用程序的缓存性能。混合计数器方案维护两种类型的计数器块用于可写页面的分割计数器块和用于只读页面的主计数器块如图7所示。我们使用两个完整性树分别存储这两种类型的计数器块。尽管这需要稍微多一些内存空间占4GB DRAM容量的0.01%[1]来存储完整性树并且需要两个处理器寄存器来存储两个根消息认证码MAC以进行完整性验证但与当前的分割计数器方案相比混合计数器方案平均提高了43%的性能见图8。**由于在IceClave中使用了混合计数器方案我们利用页表条目中的读/写权限位来决定应访问哪些计数器块。我们还支持IceClave中每个内存页面的动态权限更改。**具体而言对于只读页面其对应的计数器存储在主计数器树中。当页面变为可写并进行更新时其对应的主计数器递增并复制到分割计数器树中的相应条目中同时初始化该条目中的次计数器。同时使用新的分割计数器条目重新加密页面以供以后访问使用。当可写页面变为只读时其对应的主计数器递增并被复制回主计数器树中。存储计算程序可以使用ARM处理器提供的内存保护机制见图6来更新内存页面的权限。例如对于用于存储存储程序输入的内存区域其页面被设置为只读对于分配用于存储中间数据的内存区域其页面被设置为可写。 内存完整性验证。为了确保处理器接收到的内容与最近写入内存的内容完全相同每个内存块都生成一个消息认证码MAC通过对其数据和加密计数器进行散列计算得到。在每次内存访问时使用数据和加密计数器重新计算MAC并与存储的MAC进行比较以便检测到数据或计数器的任何更改。完整性树还防止了可以将数据和MAC回滚到其旧版本的重放攻击。如图7所示完整性树以层次结构组织MAC并且父MAC确保其子MAC的完整性。树的根安全地存储在处理器芯片中。当缓存行写回到内存时Merkle树将更新从数据块到根的所有节点的路径上的节点。在IceClave中我们采用了Bonsai Merkle TreeBMT[65]。它通过对计数器块而不是数据块进行散列计算来生成其第一级MAC。正如前面讨论的IceClave维护两棵Merkle树但与传统的BMT相比额外的内存成本是可以忽略的。对于4GB DRAMIceClave需要0.5MB用于图7(a)中使用的Merkle树以及4MB用于图7(b)中使用的Merkle树。
4.5 IceClave运行时
在本节中我们讨论了IceClave运行时如何促进存储中的可信执行环境TEE的执行。它提供了管理存储中的TEE所需的基本功能如TEE设置、TEE生命周期和元数据管理以及与安全世界的交互。IceClave运行时还与部署在主机机器上的IceClave库进行交互。需要注意的是IceClave库只向最终用户提供基本的卸载接口如RPC。这不仅减小了可信计算基础还简化了存储中程序的开发。我们在表2中列出了IceClave的API。IceClave允许用户使用两个API与SSD进行交互OffloadCode和GetResult。一旦程序被卸载到SSD上IceClave运行时将执行CreateTEE()来创建一个新的TEE。同时它将调用SetIDBits()来设置FTL中相应地址映射表条目参见§4.3的ID位访问权限其中包含由存储中程序指定的逻辑页面地址列表。根据我们对流行的存储中程序的研究它们的代码大小为28-528KB。然而对于一个大小超过SSD DRAM可用空间的卸载程序TEE的创建将失败。在执行存储中程序期间将调用ThrowOutTEE()来处理程序异常情况。IceClave运行时将中止这些情况下的TEE包括1违反访问控制、2TEE内存或元数据损坏以及3存储中程序抛出异常。一旦存储中程序完成IceClave运行时将调用TerminateTEE()来终止TEE的执行。在TrustZone的帮助下IceClave支持在每个TEE内进行动态内存分配。为了避免内存碎片化IceClave将预分配一个大的连续内存区域默认为16MB。在删除TEE时IceClave运行时将释放预分配的内存区域。
4.6 将所有内容整合起来
我们在图9中说明了使用IceClave运行存储中程序的整个工作流程。与现有的存储中计算框架[39, 72]类似IceClave库具有基于PCIe的主机到设备通信层允许用户在主机和SSD之间传输数据。如§3所讨论的我们利用现代云计算平台中开发的安全通道来实现主机与共享SSD之间的交互。调用§4.5中描述的OffloadCode API1来卸载程序。其参数bin表示以机器代码形式预编译的程序lpa是卸载程序所需的数据的逻辑页面地址LPAs列表。它使用任务IDtid作为索引来标识卸载的过程。IceClave运行时将使用CreateTEE2为卸载的程序创建一个新的TEE。在创建时IceClave运行时将从正常内存区域为TEE分配内存页而TEE元数据将在安全内存区域中进行初始化和维护。IceClave还执行SetIDBits以设置LPAs的地址映射表中的访问权限。TEE不依赖FTL来获取物理页面地址参见§4.2因为它可以访问受保护内存区域中的映射表3。然而存储中程序可能偶尔遇到缓存未命中即访问的LPA的映射条目未缓存在SSD DRAM中。在这种情况下TEE必须通过ReadMappingEntry4将地址转换请求重定向到FTL。这时TEE将被暂停并切换到安全世界以便FTL加载缺失的映射表页5更新受保护内存区域中的缓存映射表并将PPA返回给TEE。为了避免存储中程序探测SSD的整个物理空间我们强制执行访问控制参见§4.3。通往TEE的数据路径上的任何数据都会使用流密码引擎进行加密6。需要注意的是鼓励用户加密其数据以防范恶意主机操作系统的攻击。他们将随着卸载的程序一起发送解密密钥到TEE并在TEE中的运行时对数据进行解密。一旦存储中程序在TEE中准备就绪IceClave运行时将调用TEE。IceClave运行时不断监视启动的TEE的状态保护内存区域并确保映射表权限的保护。如果有任何前述完整性受到损害将抛出异常。在整个TEE的生命周期中将强制执行§4.4中描述的硬件保护机制以防止物理内存攻击。IceClave还将在TEE和FTL之间实施强隔离。§4.2中描述的内存保护也将在现有的TrustZone内存控制器TZASC[8]中实施。当达到TEE程序的末尾时在终止TEE并回收已使用资源之前结果将被复制到TEE的元数据区域8。IceClave将使用NVMe中断发起DMA传输请求表示结果的就绪状态。结果通过IceClave库中提供的GetResult7返回到主机内存中。总之IceClave可以以低开销保护存储中计算免受软件和物理攻击1它可以对SSD DRAM进行低开销的内存加密和验证2它可以在正常世界和安全世界之间进行频繁的上下文切换保护共享FTL3它可以通过SSD控制器中高效的流密码引擎保护从闪存芯片到SSD DRAM的数据传输。
4.7 讨论与未来工作
在本文中我们利用ARM处理器中的TrustZone技术实现了存储中程序与FTL函数之间的内存保护。这是因为现代SSD控制器中广泛采用了ARM处理器。由于设备供应商也考虑在其控制器中采用开源的RISC-V架构[32, 41, 73]IceClave的关键思想也可以用新型处理器实现。具体而言RISC-V定义了三个特权级别包括应用级别、监管级别和机器级别[36]。我们可以将正常的、受保护的和安全的内存区域参见§4.2分别映射到RISC-V的不同内存区域中。除了使用ARM和RISC-V处理器进行存储中计算外最近的研究还在SSD控制器中部署了硬件加速器[13, 24, 45, 46, 56, 57, 87]。然而它们还不支持存储中TEE的功能。作为未来的工作我们希望将IceClave扩展到这些存储中的硬件加速器上。
5 实现细节 完整系统模拟器。我们使用基于SimpleSSD [38]、Gem5 [37]和USIMM [21]模拟器开发的计算SSD模拟器来实现IceClave。这使我们能够使用不同的SSD配置进行研究而这在真实的SSD板上很难进行。我们使用SimpleSSD来模拟现代SSD及其存储操作。我们在表3中展示了SSD的配置。为了在模拟器中实现存储中计算我们利用Gem5来模拟SSD控制器中的乱序ARM处理器。我们还在集成模拟器中实现了流密码以便在存储中的应用程序从闪存芯片加载数据时进行数据加密/解密。我们使用CACTI 6.5 [61]估计其硬件成本并发现密码引擎仅对一款现代SSD控制器如Intel DC P4500 SSD引入1.6%的面积开销。由于IceClave将在SSD DRAM中实现内存验证我们利用USIMM来模拟SSD中的DRAM。我们在USIMM模拟器中实现了Bonsai Merkle树BMT并使用混合计数器模式参见§4.4作为内存加密方案。正如讨论的那样完整性树的根存储在安全的芯片上寄存器中。计数器缓存大小为128KB。为了实现内存加密和完整性验证我们强制要求每个内存访问都会触发MAC和完整性树的验证和更新。由于我们使用Gem5开发了一个完整的系统模拟器我们运行真实的数据密集型工作负载比如事务数据库以评估IceClave的效率。真实系统原型。为了验证IceClave的核心功能包括TEE的创建/删除、FTL和流密码引擎我们还使用具有双ARM Cortex-A9处理器的OpenSSD Cosmos FPGA板实现了IceClave [84]。我们测量了它们的开销并在表5中显示了它们。我们在图10中展示了流密码引擎的架构。其密钥初始化模块接受对称密钥和任意初始化向量IV作为输入用于初始化密码。IceClave将密钥存储在安全寄存器中而IV可以是公开的。一旦初始化流密码每个周期生成64个密钥流位。生成的密钥流按位与从闪存芯片读取的数据进行异或运算以生成加密数据。解密使用相同的密钥和IV来解码加密数据。IV由时间上唯一的随机数和空间上唯一的地址位构成。这种正交唯一性强制确保在一定时间段内不会重复使用相同的IV值。我们使用的流密码算法是Trivium [30]。为了为不同的闪存页面提供唯一性我们通过将物理页面地址PPA和伪随机数生成器PRNG的输出连接起来来构造IV。
6 评估
我们的评估结果表明 1IceClave对存储中的工作负载引入了最小的性能开销同时在SSD控制器中实施安全隔离§6.2和§6.3 2随着我们增加SSD的内部带宽IceClave可以提高存储中应用程序的性能§6.4 3IceClave可以使不同访问延迟的各种SSD设备受益§6.5 4在变化存储中计算能力的情况下IceClave仍然显著优于传统的基于主机的计算并提供安全隔离§6.6和§6.7 5IceClave可以在低性能开销的情况下实现多个存储中程序的并发执行§6.8。
6.1 实验设置 我们使用一组合成工作负载和真实应用程序对IceClave进行评估如表4所示。在合成工作负载中我们使用数据库系统中的几个基本操作符包括算术、聚合和过滤操作。至于真实应用程序我们运行来自TPC-H基准测试的真实查询。具体而言我们使用TPC-H查询1、3、12、14和19其中包括多个连接和聚合操作的组合。除了这些工作负载我们还运行写入密集型工作负载TPC-B、TPC-C和Wordcount以进一步评估IceClave的加密和完整性验证开销。在所有这些工作负载中我们将它们的数据集表扩展到32GB的大小并将它们分布在SSD的通道中。
我们将IceClave与几种最先进的解决方案进行比较。特别地我们将IceClave与主机机器中可用的Intel SGX进行比较其中我们将数据从SSD加载到主机内存并在SGX中执行查询。对于此设置我们使用一台真实的服务器其配备了Intel i7-7700K处理器主频4.2GHz、16GB DDR4-3600 DRAM和1TB Intel DC P4500 SSD。为了公平比较我们遵循Intel DC P4500 SSD的规格来配置我们的SSD模拟器。
我们还将IceClave与当前不提供TEE用于卸载程序的存储中计算方法进行比较。它们列举如下
Host将数据从SSD加载到主机内存并使用主机处理器执行数据查询。主机机器和SSD设置如上所述。HostSGX在从SSD加载数据后在Intel SGX中运行数据查询。我们在实验中使用的SGX SDK版本是2.5.101。In-Storage Computing (ISC)使用SSD控制器中的ARM处理器运行数据查询以便利用SSD的高内部带宽。
6.2 IceClave的性能 我们在图11中展示了运行每个查询基准的规范化性能。我们以Host作为基准在其中我们在主机机器上运行查询工作负载同时从SSD加载数据集。如图11所示IceClave的性能分别比Host和HostSGX平均提高了2.31倍和2.38倍。这表明IceClave不会损害存储中计算的性能优势。由于这些数据查询工作负载受到存储I/O的限制主机机器上的SGXHostSGX会稍微降低工作负载的性能。与未启用安全隔离的存储中计算ISC相比IceClave引入了7.6%的性能开销这是由于在存储中的TEE中使用的安全技术。
为了进一步了解IceClave的性能行为我们还在图11中展示了性能细分情况。对于Host和HostSGX方案我们将它们的工作流程分为两个主要部分数据加载时间和计算时间。正如我们所见HostSGX平均增加了103%的计算时间这是由于SGX在主机机器上运行导致的。对于ISC和IceClave方案我们对其进行了性能剖析包括从闪存芯片加载数据的时间、使用存储中处理器执行数据查询的时间以及IceClave进行内存加密和验证所引起的开销。如图11所示IceClave和ISC在加载时间上需要的时间更少因为SSD的内部带宽高于其外部带宽。它们需要更多的时间平均提高2.47倍来执行数据查询。与ISC相比IceClave需要进行内存加密和验证。对于诸如Wordcount之类的写入密集型工作负载IceClave会稍微增加内存加密开销。这是因为Merkle树本质上支持并行更新并且我们的混合计数器设计默认保留了这个属性。然而对于大多数存储中的工作负载IceClave仍然显著优于基于主机的方法。
6.3 IceClave中的开销来源 我们还对使用IceClave运行存储中程序的整个工作流程进行了剖析。我们在表5中展示了IceClave的关键组件及其开销。IceClave分别需要95微秒和58微秒在实际的SSD FPGA板上测量来创建和删除SSD内部的TEE。安全世界和正常世界之间的上下文切换开销为3.8微秒。如§4.2中所讨论的IceClave在运行时有很少的上下文切换因为它将频繁访问的地址映射表放在受保护的内存区域中。上下文切换主要发生在受保护的内存区域中缺少映射表条目的情况下IceClave需要切换到安全世界从闪存芯片中获取映射表并在受保护的内存区域中进行更新。此外IceClave的内存加密和验证操作开销较小因为大多数存储中的工作负载是读密集型见§4.4和表1。每个内存加密和验证操作的平均执行时间分别为102.6纳秒和151.2纳秒。我们对内存加密和完整性验证中由于获取和溢出计数器而引起的额外内存访问进行了剖析见表6。我们在表6中显示了相对于不强制内存安全的常规内存访问的额外内存流量的百分比。平均而言内存加密使内存流量增加了20.26%验证操作使内存流量增加了14.51%。
我们还对从TEE请求的闪存地址转换数量进行了剖析并发现只有0.17%的这些地址转换在受保护的内存区域的缓存映射表中未命中。这表明存储中的程序不会频繁地引起从正常世界到安全世界的上下文切换表明IceClave对于存储中的工作负载来说是轻量级的。
6.4 SSD带宽的影响 我们现在评估IceClave在更改不同SSD参数时的性能敏感性。首先我们通过改变闪存通道的数量从4个变为32个来改变SSD的内部带宽。通过这样做聚合的内部I/O带宽呈线性增长而外部带宽受到PCIe带宽的限制[18, 52]。我们将IceClave与基于主机的方法Host进行比较并在图12中展示了归一化加速比。对于每个数据查询工作负载随着通道数量的增加IceClave的性能优势显著扩大。具体而言IceClave相比于Host将性能提速了1.7倍至5.0倍表明IceClave对存储中计算的性能影响可以忽略不计。对于涉及更复杂计算的存储中工作负载如TPC-B、TPC-C和Wordcount增加内部带宽可以带来1.2倍至1.8倍的性能提升而对于其他工作负载如合成工作负载和TPC-HIceClave获得了更多的性能优势1.9倍至6.2倍。值得注意的是IceClave甚至比HostSGX获得了更多的性能优势因为SGX引入了额外的开销参见图11和§6.2。而且IceClave为存储中的程序提供了TEE。当我们改变内部SSD带宽时我们还将IceClave与ISC进行了比较。如图13所示与ISC相比IceClave将应用程序的性能降低了最多28%平均为8.6%。随着通道数量的增加对于像TPC-C这样的复杂数据查询其额外的开销略有增加。这主要是由于内存加密和完整性验证的开销增加。然而IceClave为卸载的程序提供了TEE使我们相信这样的努力是值得的。
6.5 数据访问延迟的影响
为了了解数据访问延迟对IceClave性能的影响我们将从访问闪存页面的读取延迟从10微秒变化到110微秒模拟超低延迟的NVMe SSD [2, 6]到常规TLC闪存的SSD [60]。我们将写入延迟保持为300微秒因为大多数存储中的工作负载是读取密集型涉及较少的写入操作。我们在SSD中使用8个通道。我们在图14中展示了实验结果。如图14所示与受外部PCIe带宽限制的基于主机的计算方法相比IceClave在具有不同访问延迟的各种SSD设备上提供了性能优势1.8倍至3.2倍。对于需要更多计算资源进行哈希连接操作的TPC-B、TPC-C和TPC-H Q19查询工作负载在具有超低延迟的SSD上IceClave的性能优势较小因为主机机器中的处理器提供了更强大的计算资源。
6.6 计算能力的影响
利用嵌入式处理器来运行存储中的应用程序了解存储中计算能力如何影响IceClave的效率是很有意思的。我们通过使用不同型号的嵌入式处理器来改变此参数。我们使用存储中计算模拟器来模拟具有典型乱序OoOARM处理器A72和不同频率的顺序处理器A53并将其与基准的Host进行比较基准Host使用Intel i7-7700K处理器频率为4.2GHz。我们在图15中展示了归一化加速比。随着ARM处理器的CPU频率降低IceClave的性能下降了13.7%至33.4%。在相同的CPU频率下具有乱序处理器A72的性能略优于顺序处理器A53。这表明IceClave可以与不同类型的ARM处理器配合使用并提供合理的性能优势。
6.7 SSD中DRAM容量的影响
为了评估SSD中DRAM容量对IceClave性能的影响我们将SSD中的DRAM大小从4GB降低到2GB同时使用与表3中描述的相同配置。我们在图16中展示了实验结果。随着SSD中DRAM容量的减小ISC的性能下降了12%至44%因为它有限的内存空间无法存储其数据集。IceClave的性能也呈现相同的趋势。然而与ISC相比IceClave仍然引入了最小的性能开销。
6.8 多租户IceClave的性能
为了进一步评估IceClave的效率我们同时运行多个IceClave实例每个实例托管一个存储中工作负载如表4所述。我们将应用程序性能与独立运行每个存储中应用程序而不与其他实例共存的情况进行比较。如图17所示当我们将TPC-C实例与其他工作负载共存时存储中应用程序的性能下降了6.1%至15.7%。当我们增加共存实例的数量时参见图18它们的性能平均下降了21.4%。这主要是由于1共存的IceClave实例之间的计算干扰以及2受保护内存区域中缓存映射表的缓存未命中增加高达8.7%所导致的。然而这些存储中程序仍然比受限于SSD外部I/O带宽的基于主机的方法表现更好。
7 相关工作
存储中计算。存储中计算近年来得到了广泛的发展。研究人员一直在探索将其应用于数据库查询[33, 34, 47, 52]、键值存储[72]、MapReduce工作负载[39, 47]、信号处理[19]和科学数据分析[81, 82]等领域。为了在现代SSD中实现存储中计算这些前期工作开发了各种框架[39, 52, 66, 72]。然而大多数工作关注的是可编程性和性能方面。尽管在这些方面仍有改进的空间例如为存储中计算提供SSD阵列和文件系统支持[66]但我们必须克服存储中计算的安全挑战以便广泛部署它因为它对用户数据和闪存设备构成威胁。据我们所知我们是第一个提出为存储中计算构建可信执行环境的。
可信执行环境。为了保护应用程序免受恶意系统软件的攻击人们开发了可信硬件设备。一个典型的例子是Intel SGX [17]它可以为应用程序创建可信执行环境。由于启用了安全隔离SGX被扩展或定制以支持各种计算平台[5, 11, 27, 53, 78]和应用程序[14, 50, 63, 70]。具有TPM [3]的硬件设备利用了AMD和Intel等商用处理器中的可验证性以达到类似的目的[58, 59, 77]。对于常用于移动设备和存储控制器的ARM处理器它们提供了TrustZone可以在操作系统之外创建安全的隔离世界[42, 69]。不幸的是这些硬件设备都不能直接应用于存储中计算。最近的工作ShieldStore [50]和Speicher [14]将SGX应用于键值存储然而它们都不能保护存储中程序的执行。我们为存储中应用程序开发了专门的可信执行环境。
存储加密和安全性。随着计算越来越接近存储设备中的数据可信计算基础必然增加这对用户数据构成安全威胁。为了在实现近数据计算的同时保护敏感用户数据一种常见的方法是数据加密[64]。然而由于现代SSD控制器缺乏可信执行环境的支持数据泄露或丢失仍然可能发生在运行时。同时攻击者还可以发起物理攻击来窃取/破坏用户数据。另一种方法是在加密数据上进行计算[29, 93]。然而这种方法需要大量的计算资源而由于有限的资源预算[15, 39, 56, 85]现代SSD控制器无法满足这种需求。我们的IceClave提供了一种轻量级的方法可以为存储中应用程序提供安全隔离并防御物理攻击。
