谁来拯救存量SGX1平台？又一个内核特性合并的血泪史

作者 / 乾越  

编辑 / 伯瑜

出品 / 云巅论剑

 

前言

自从Intel内核开发人员Jarkko Sakkinen于2017年9月2日在intel-sgx-kernel-dev@lists.01.org邮件列表上发出v1版的SGX in-tree驱动以来，时间已经过去了3年多了。这期间这个驱动前前后后共修改了41个版本，终于在2020年11月13日，v41版本的补丁合入了5.11-rc1内核。Jarkko松了一口气，任务完成啦！不过，为什么合并一个普通的驱动模块会这么难？

事实上，由于SGX所代表的新的机密计算领域的特殊性，围绕着它的争议和讨论就从未停止过。甚至在最终的v41补丁中，也没能看到大佬们整齐划一的LGTM（社区黑话，Looks Good To Me的缩写，表示自己认可这个补丁），它依旧存在一些问题，同时还有人在不断提出修改建议。这不禁让人联想到另一个x86处理器特性FSGSBASE合入upstream时的命运多舛：后者的合入前后花了5年时间，甚至最后都不是Intel的人合入的（当然也不是AMD的人合入的😂，大家可以猜猜是谁）。

今天的故事主角，是一个被称为Flexible Launch Control（简称FLC）的SGX平台特性。对这个特性的争议，最终导致SGX in-tree驱动无法支持不具备FLC特性或关闭了FLC特性的所有SGX系统。大白话是啥意思呢？意思就是一批较早的支持Intel SGX的机器用Linux内核自带的官方驱动是无法加载和使用SGX的......纳尼！这个驱动竟然不向下兼容！哎，现在让我们先对FLC技术背景进行一个简单的介绍，然后再对其被社区抛弃的故事简单做个复盘，最后再给出我们的思考，以及我们的解决方案。

 

FLC的技术背景

友情提醒：想听故事不想了解技术细节的同学请直接跳到下一节。

在执行SGX EINIT指令初始化enclave的时候，被初始化的enclave必须通过Launch Control机制的检查，因此Launch Control是一种用于控制enclave能否启动的安全检查机制。

被初始化的enclave分为两类：Launch Enclave和普通enclave。Launch Enclave与普通的enclave的不同之处在于其SECS.ATTRIBUTES.EINITTOKEN_KEY == 1，即具有通过执行SGX EGETKEY指令派生出einit token key的权限。Einit token本质上是一个带有CMAC签名的token，其中的CMAC是Launch Enclave用einit token key生成的，意在对einit token本身提供完整性保护；在执行EINIT初始化普通enclave的时候，从Launch Enclave处返回的einit token需要作为输入参数的一部分，然后EINIT指令的微码会将einit token作为派生出einit token key的输入因子，最后用派生出的einit token key来验证输入的einit token中的CMAC，以确保einit token从生成到传给EINIT的过程中没有被篡改。

上面的流程中提到的einit token完整性检查适用于所有的普通enclave，而对于Launch Enclave，再执行EINIT初始化时有特殊处理。下面是在执行EINIT时完整的Launch Control流程：

（上面的流程图是对Intel SDM手册中关于EINIT指令在微架构层的执行流程进行的总结；其中Launch Enclave验证两次IA32_SGXLEPUBKEYHASH的逻辑应该是冗余的，但我们还是按照原始流程的逻辑把它给完整地画出来了）

可以简单地将上述流程总结为以下两点规则：

1.只要在初始化enclave时能提供合法的einit token, 就能通过Launch Control的检查