题目： UniGuard: Protecting Unikernels Using Intel SGX

作者： Ioannis Sfyrakis, Thomas Gross

单位： School of Computing Science, Newcastle University, UK

出版： IC2E 2018

解决问题：

1. 云上威胁很多，不可信的管理员、不可信的特权软件，带缺陷的HV都会导致VM中的敏感信息泄露。
2. Unikernel在云上很火，其安全也存在问题。SCONE提供了容器级别安全，Graphene提供了LibOS级、Panoply提供了微容器级的安全保护，都使用SGX技术。很可惜这些技术都没有和虚拟化结合。虚拟化曾一度视为缩小攻击面的技术，减小租户与服务提供商的接口交互。
3. 本文使用UniGuard来保护虚拟化中Unikernel，对象是KVM之上的MirageOS。

贡献：

1. 新架构；
2. shim layer：对enclave unikernel和外部数据进行检查。
3. 评估。

背景：

• Unikernels小而轻，适合放到Enclave中。

设计trade-off：

1. 要包含什么什么功能，Haven功能强大，TCB很大；SCONE引入一部分libc。
2. Shield复杂度：依赖外部服务越多，shim的复杂度越大。
3. 支持程序的复杂度，SGX保护密码库最省力，支持需要各类系统调用的程序开发难度最大。
4. 如何划分程序：需要几个Enclave，如何配合。本文关注一个Enclave对应一个Unikernel。（**笔者注：多个协同Enclaves的工作还很少**）

方案：

见原文图3、4。

架构：

见原文图5。

工作量：

1. 修改ukvm，给solo5分配EPC。同时要在unikernel地址空间中创建用户态，然后再运行enclave。
2. 修改SGX SDK tRTS，编写Shim库，允许程序链接unikernel后生成enclave。

安全分析：

• 不使用QEMU，而用ukvm monitor，减小攻击面。

开销：

1. 启动时间：原生ukvm：11ms，enclave：27.5ms，UniGuard：33.1ms
2. 运行时：由于增加了模式切换，平均执行时间从9.28us变为10.1us，大约在10%。但我认为本文结果不全面，取决于unikernel程序内部如何分配可信/不可信组件（ocall是否多）以及对外部依赖情况（shim参数sanitize检查开销）。

体会：

1. 本文思路和SCONE十分类似，属于系统架构的迁移。
2. 我认为，给L4提供SGX支持更有好处，因为微内核的大部分组件运行在用户态，可以使用SGX对系统关键数据进行保护。

• Previous
  Tdb
• Next
  Jvpfs