当Java遇上机密计算，又一段奇幻之旅开始了！-阿里云开发者社区

头图.png

写在前面

在信息世界里，数据存在三种状态：存储态、传输态和计算态。存储在数据库或磁盘中的数据属于存储状态，在网络中传输的数据属于传输状态，正在被计算处理的数据属于计算状态。我们需要从数据三种状态出发进行系统的安全保护，才能确保真正的数据安全。对于存储态和传输态数据安全问题，我们可以利用被广泛使用的数据加密技术进行有效保护。对于计算态的数据安全保护仍旧属于新的前沿领域。

基于硬件的机密计算技术(TEE)，通过提供一个可信执行环境，在该环境下运行的代码和数据会得到硬件级的保护，任何软件包括内核和Hypervisor都无权限窥探该环境中的数据信息，从而实现对计算态数据的保护。

全球主流的芯片厂商都纷纷推出了各自的机密计算解决方案，比如Intel SGX和Arm TrustZone等。TrustZone主要用在终端领域，而SGX技术则可以应用于服务器领域。SGX技术能够提供极高的机密计算保护等级，但由于SGX技术在内存资源和编程模型上的限制，无法有效支撑Java生态的机密计算业务，不得不说是一个遗憾。随着阿里云神龙架构第七代ECS实例的发布，所搭载的Intel新一代SGX2技术，为我们构建基于Java生态的机密计算服务提供了条件。

Java机密计算Demo演示

现在，让我们通过一个具体的例子来演示如何为Java业务提供机密计算保护。该实例基于第三代神龙架构第七代ECS实例构建，在SGX2提供的机密计算可信执行环境内运行Java SpringBoot网络服务。

准备工作

申请一台支持SGX2的神龙架构第七代ECS实例，EPC内存规格不要过小24G；
下载LibOS: Occlum容器镜像
occlum/occlum：0.20.0-ubuntu18.04；
下载JDK: Alibaba Dragonwell11(Alpine)，Alibaba发布的基于Alpine平台Dragonwell11镜像版本；
下载SpringBoot源码: Demo，该Demo展示了一个基于SpringBoot框架构建的简单网络服务；

其中SpringBoot Demo源码下载到本地后，进入initial目录后进行编译打包，在target目录下会生成spring-boot-0.0.1-SNAPSHOT.jar，我们先在普通环境下运行jar包验证其功能：

mvn clean package

java -jar spring-boot-0.0.1-SNAPSHOT.jar

构建SGX执行环境

首先登录到ECS实例；
在ECS环境下，通过docker命令进入Occlum容器；

docker run -it --rm --privileged --network host \
            -v `pwd`:`pwd` \
    -v /dev/sgx_enclave:/dev/sgx/enclave \
    -v /dev/sgx_provision:/dev/sgx/provision \
    -v /var/run/aesmd:/var/run/aesmd \
    occlum/occlum:0.20.0-ubuntu18.04

在Occlum容器中，创建一个enclave实体。该实例包含一个json配置文件和image镜像文件夹；

mkdir occlum_instance
cd occlum_instance
occlum init

4. 对Occlum.json文件进行修改，修改内容包括堆的大小、entry point和env环境变量等；

resource_limits.user_space_size = "1680MB"
resource_limits.kernel_space_heap_size="64MB"
resource_limits.max_num_of_threads = 64
process.default_heap_size = "256MB"
process.default_mmap_size = "1400MB"
entry_points = [ "/usr/lib/jvm/java-11-alibaba-dragonwell/jre/bin" ]
env.default = [ "LD_LIBRARY_PATH=/usr/lib/jvm/java-11-alibaba- \   
dragonwell/jre/lib/server:/usr/lib/jvm/java-11-alibaba-dragonwell/jre/lib:/usr/lib/jvm/java-11- \
alibaba-dragonwell/jre/../lib" ]

运行Java需要配置更大的内存空间。entry_points选项表示Occlum LibOS里面JDK的放置路径。JDK的路径必须是xx/xx/jre/bin模式，而且需要设置LD_LIBRARY_PATH环境变量。由于目前的Occlum LibOS还不支持exec系统调用，因此JDK的路径需要满足一定条件，这样可以避免JVM虚拟机启动时出现exec系统调用。

进入image文件夹，在此目录下创建usr/lib/jvm/java-11-alibaba-dragonwell文件目录，用于放置Dragonwell11 Alpine JDK，注意将JDK压缩文件解压后的文件夹名重命名为jre，保证与.json配置文件一致；创建usr/lib/spring文件目录，用于放置之前准备的SpringBoot spring-boot-0.0.1-SNAPSHOT.jar文件。

注意，image文件目录将作为SGX LibOS运行起来后的根目录。

将Occlum容器环境下的libz.so.1文件拷贝到image/lib；

cp /usr/local/occlum/x86_64-linux-musl/lib/libz.so.1 image/lib

构建image机密镜像；

occlum build

启动SGX机密计算业务；

occlum run /usr/lib/jvm/java-11-alibaba-dragonwell/jre/bin/java -Xmx512m -XX:-   \
UseCompressedOops -XX:MaxMetaspaceSize=64m -Dos.name=Linux -jar /usr/lib/spring/spring- \
boot-0.0.1-SNAPSHOT.jar

SpringBoot启动完成后，使用命令curl localhost:8080请求SpringBoot服务，得到 "Greetings from Spring Boot!" 的回复，表示运行成功。其中，-XX:-UseCompressedOops参数是为了优化Java在Occlum下的启动时间；-Dos.name=Linux参数是为了告知JVM虚拟机LibOS的系统类型；

图(1) SpringBoot启动示意图

整个SpringBoot网络服务的运行过程都在机密计算环境下进行，ECS实例自带的底层软件没有权限对保护中的服务进行窥探，实现了云上服务的运行态数据保护。

神龙架构第七代ECS与Java机密计算

阿里云发布的神龙架构第七代ECS实例，其搭载的是Intel第三代至强可扩展处理器(代号为Ice Lake)。该处理器提供的下一代Intel SGX安全技术(SGX2)，在核数和EPC内存容量上皆有非常可观的提升，具体规格见图(2)所示。Ice Lake处理器在核数上提供了最多80物理核(160逻辑核)的处理能力，而第一代SGX可用处理器至多只有6个物理核；EPC内存容量则增加到了1TB，而第一代SGX EPC内存容量只有128M。用户可根据需求选择不同规格的核数和EPC内存容量。

图(2) SGX技术规格对比图

由于SGX1提供的EPC内存容量和核数太少，不适应Java这种比较重的编程语言。长期以来，只有基于C/C++这类native语言更适合在SGX1中运行。此外，SGX SDK定义的Host Enclave编程模型，需要将业务代码进行分割，对代码侵入性较大，进一步限制了SGX1的使用范围。由于SGX2技术在核数和EPC内存容量上的提升，使得我们可以突破Host Enclave编程模型的束缚，同时满足Java业务对硬件资源的要求，基于SGX部署Java机密计算业务成为了可能，可以预期公有云场景下的机密计算服务会迎来蓬勃发展。

机密计算模型

机密计算编程模型

机密计算主要有两种编程模型，如图(3)所示:

图(3) 机密计算编程模型

一种是Host-Enclave编程模型，该模型将整个应用分割成Host和Enclave两部分。Host运行在普通环境下，负责大部分应用逻辑处理，只将一些需要安全保护的业务逻辑(比如加解密等)放到Enclave环境中执行，通过ecall和ocall操作实现二者的切换和信息传递；这种编程模型下，用户需要将业务分割成Host和Enclave两部分进行编程，还需要编写ecall(ocall)代码实现Host和Enclave之间的切换和信息交互，编程难度较大，对存量业务进行改造也有一定困难。但优点是Enclave TCB足够小，安全等级较高。

// enclave.c

int function(int a, int b) {
    return a + b;
}

// host.c

int main() {
    ... ...
    enclave ec = create_enclave();
    int c = function(&enclave, 3, 5);
    destroy_enclave(ec);
    ... ...
    printf("sum is: %d\n", c);
}

另一种是Full-Feature编程模型，它将整个完整的应用都放到Enclave中运行，Host只负责Enclave的管理和ocall等操作，一般由底层框架的工具链提供，用户不用感知Host的存在；该编程模型与传统编程模型一致，无需进行分割，没有增加额外的编程难度，对已有业务代码进行改造也很容易。但该模型需要在Enclave中驻留一个功能强大的SDK或LibOS，才能支撑完整应用的正常运行，加上业务代码自身的体量，会导致Enclave中TCB较大，安全等级下降。

// App.c

int function(int a, int b) {
    return a + b;
}

int main() {
    int c = function(3, 5);  
    printf("sum is: %d\n", c);
}

两种机密计算编程模型各有利弊，用户需要在易用性和安全性两个指标上进行权衡。

机密计算需求模型

鱼和熊掌不可兼得，需要在易用性和安全性两个需求维度进行取舍。我们将机密计算业务需求按照安全等级进行分级，不同安全等级的需求，选择不同的编程模型，见图(4)所示。当业务中只有少量计算逻辑需要安全保护，且要求较高的安全等级时，可以选择Host-Enclave编程模型；当用户不希望对业务代码进行大量改造，同时可以接受相对较低的安全等级时，可以选择Full-Feature编程模型。

图(4) 机密计算需求模型

SGX机密计算软件生态

神龙架构第七代ECS实例提供的第二代SGX技术，在硬件能力上已不存在瓶颈。那么接下来的一段时期，围绕SGX技术软件生态的发展，将决定SGX技术是否能得到广泛使用，产生业务价值。

SGX SDK

Intel在发布第一代SGX技术之时，就推出了Intel SGX SDK，它定义了面向C/C++语言的SGX机密计算Host-Enclave编程模型，用.edl文件定义Host与Enclave之间的交互接口；之后微软云Azure推出了OpenEnclave，它是对Intel SGX SDK进行的功能扩展和平台抽象。可以在Enclave中运行更加复杂的业务，同时扩展了安全计算硬件平台的支持(SGX和TrustZone等)；Google云推出了Asylo编程模型，与OpenEnclave类似，同样是进行了平台抽象和功能扩展。Asylo最大的特点是将Encalve抽象成一种远端服务，与Host通过GRPC方式进行交互。可以让Host和Enclave两个模块在物理上分离，不必限制在一个芯片内部，而且还屏蔽了Host和Enclave的编程语言差异，使得Asylo编程模型更具灵活性，非常具有借鉴意义。

纵观Intel SGX SDK、OpenEnclave和Asylo的发展，不难看出OpenEnclave和Asylo是对Intel SGX SDK的继承和发展，上述三种SDK满足了部分机密计算应用场景，比如使用C/C++语言编写且只有少量计算需要安全保护的业务场景。又由于Enclave SDK能力限制，无法支持复杂Enclave业务逻辑。主要有如下几个特点：

都属于Host-Enclave编程模型，Asylo在一定程度上也支持Full-Feature编程模型；
开发难度大，Host-Enclave编程模型需要对应用程序做二分；
仅支持C/C++编程语言，无法支持像Java/Go等高级编程语言；
不支持Full-Feature编程模型，无法满足易用性要求高的业务场景；

SGX LibOS

SGX运行环境与普通运行环境有许多不同之处，是否可以在Enclave中引入一个OS屏蔽掉SGX执行环境的差异，让应用程序感知不到SGX的存在，就像在普通环境下运行一样呢? 业界有很多这样的先行者，目前比较知名的SGX LibOS项目有Occlum、Graphene和SGX-LKL等。其中Occlum是由蚂蚁自研的开源TEE-OS系统，采用Rust编程语言，功能较完善，已支持多种编程语言，同时还具备高性能和内存安全等特点。

SGX LibOS的目的是让整个应用方便的运行在SGX Enclave中，符合Full-Feature机密计算编程模型，易用性高、支持多种编程语言和复杂的应用。这种解决方案主要存在以下问题:

TCB增大，牺牲了一定的安全性；
需要消耗更多的SGX硬件资源；
频繁的ecall和ocall操作（比如IO）影响业务性能；

Alibaba Dragonwell机密计算

SGX1存在核数和EPC大小等的限制，如果将内存需求量大、逻辑复杂的应用部署在LibOS平台上，必然会出现频繁的EPC内存swap和ecall(ocall)切换，导致业务性能下降严重，很难投入实际的生产环境。因此SGX1硬件条件决定了它只能支持C/C++编程语言实现的简单Enclave业务场景。随着神龙架构第七代ECS实例的发布，来到SGX2时代后，得益于核数和EPC内存大小的提升，基于Java编程语言的机密计算服务具备了实用的条件。

Java机密计算解决方案

阿里巴巴Java虚拟机团队推出的Java机密计算解决方案如图(5)所示。该方案采用Full-Feature编程模型，通过在Enclave中引入LibOS，支撑Alibaba Dragonwell11的运行，上层应用则对SGX环境无感知。

图(5) Java机密计算解决方案

Alibaba Dragonwell是阿里巴巴Java虚拟机团队开源的OpenJDK实现，目前支持8和11两个LTS版本。针对Alibaba Dragonwell11，发布了兼容glibc与musl两种libc的JDK版本，目的是为了让Alibaba Dragonwell11能适配更多的LibOS。由于musl相比glibc更轻量，代码易维护，在机密计算领域更受青睐，很多LibOS优先选择musl作为基础库进行支持(比如Occlum)。Alibaba Dragonwell11 musl版本不仅仅可以作为机密计算JDK的首选版本，而且还能用于构建Alpine容器镜像，有效减小容器镜像的大小。

Java机密计算性能评估

性能是绕不开的话题，运行在SGX2中的Java业务性能表现如何呢？我们对Java SpringBoot业务分别在SGX1/SGX2/Linux三种运行环境下的性能进行了压力测试。设置相同的测试压力（并发数400, 压测时间40s），从系统吞吐量（MB/秒）和RPS（请求数/秒）两个压测指标维度进行对比分析。压测结果如图(6)所示:

图(6) Java机密计算SGX压测性能对比图

在相同的测试压力下，Linux平台的吞吐量为26.91MB/秒、RPS为12.84K/秒；SGX2吞吐量为是18.53MB/秒、RPS为8.84K/秒；SGX1吞吐量为1.26MB/秒、RPS为602.10K/秒。可以看到SGX2相比SGX1获得了巨大的性能提升，但与Linux平台还存在一定差距。相信随着Alibaba Dragonwell11的持续优化，性能也会进一步提升。

总结

在阿里云发布神龙架构第七代ECS实例后，阿里巴巴Java虚拟机团队提出了面向Java语言的机密计算编程模型和解决方案，并进行了深入的实践，发布了用于Java机密计算的Alibaba Dragonwell11 JDK版本。从实践结果看，基于SGX2的Java机密计算解决方案，在性能上提升明显，可以支撑复杂的Java机密计算服务稳定运行。相信基于SGX2的Java机密解决方案将有力推动Java机密计算的发展，希望对Java机密计算感兴趣或者有需求的开发者尝试我们的方案，期待与大家进一步的交流。

开源项目链接：

阿里云神龙架构服务器：

https://www.aliyun.com/product/ebm?spm=5176.19720258.J_8058803260.1175.54212c4aeuLsLB

阿里云神龙架构第七代ECS SGX2实例列表：

https://help.aliyun.com/document_detail/108491.html#section-m7c-byy-0ye

阿里云神龙架构第七代ECS实例SGX云安全技术介绍：

https://help.aliyun.com/document_detail/208095.html?spm=5176.10695662.1996646101.searchclickresult.3c197e7bMb3JPN

Dragonwell11机密计算JDK项目：

https://github.com/alibaba/dragonwell11/releases

Intel SGX SDK项目：

https://github.com/intel/linux-sgx

OpenEnclave项目：