2020年优秀毕业设计(一)| 针对可扩展内存完整性保护的设计与实现
发布于 2021-04-06 12:11
毕设背景
分析与思考
本文首先分析现有可信执行环境限制安全内存大小的根本原因在于其用于保护内存完整性的数据结构(Merkle Hash Tree)无法扩展,其保护的内存大小与完整性保护树的层数相关。受限于运行时的性能开销,完整性保护树的层数有严格的限制,从而导致了保护内存大小受限,相关的工作通过增加完整性保护树的扇出,使得在相同层数下能够保护更多的内存,但是并没有根本上解决保护内存受限的问题。在该论文中,我们通过结合内存访问的局域性,充分利用SoC上的空间资源,以及重构完整性保护树数据结构的方式,提出了一种针对云场景中TB级别内存数据完整性保护的设计方案,从而加强了云端数据的安全。
设计与优化
测试与评估
我们在GEM5模拟器上实现了MMT的原型并且采用了开源指令集RISC-V,并且和学术界最先进的VAULT和工业界最先进的SIT等工作进行了比较。通过测试我们发现,对于传统的页交换操作,当使用的内存超过了SoC上能够保护内存大小的时候,会带了极其严重的性能开销,在极端的场景下,能够达到近十倍的性能下降。而对于挂载(Mount)操作,在最严重的场景下,其开销不会超过1%,挂载带来的开销相较于完整性检查可以忽略不计。我们在SPECCPU上测试了SIT, VAULT, MMT, MMT+encrypt, 以及不做完整性检查原始的测试,从测试结果中我们可以发现,MMT的性能均优于SIT和VAULT,在mcf的测试中,SIT和VAULT 相较于没有完整性保护的程序分别会有2.05x和1.6x的开销,而MMT只有0.4x的开销,这部分的开销主要是完整性检查的开销;在其他的测试中例如GemsFDTD,SIT和VAULT相较于不做完整性检查的程序来说有高达7.5x和7.06x倍的性能开销,而MMT只有0.35x的性能的开销,在这种极限的场景下,挂载操作大幅减少了原有的页交换的开销,使得完整性保护性能得到了极大的提升。
本文来自网络或网友投稿,如有侵犯您的权益,请发邮件至:aisoutu@outlook.com 我们将第一时间删除。
相关素材