简介： 汪少军：如何为Java业务提供秘密计算爱护？

写在后面

在信息世界里，数据存在三种状态： 存储态、传输态和计算态。存储在数据库或磁盘中的数据属于存储状态，在网络中传输的数据属于传输状态，正在被计算解决的数据属于计算状态。咱们须要从数据三种状态登程进行零碎的平安爱护，能力确保真正的数据安全。对于存储态和传输态数据安全问题，咱们能够利用被宽泛应用的数据加密技术进行无效爱护。对于计算态的数据安全爱护仍旧属于新的前沿畛域。

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

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

Java秘密计算Demo演示

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

筹备工作

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

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

mvn clean packagejava -jar spring-boot-0.0.1-SNAPSHOT.jar

构建SGX执行环境

  1. 首先登录到ECS实例；
  2. 在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
  1. 在Occlum容器中，创立一个enclave实体。该实例蕴含一个json配置文件和image镜像文件夹；
mkdir occlum_instancecd occlum_instanceocclum init
  1. 对Occlum.json文件进行批改，批改内容包含堆的大小、entry point和env环境变量等；
resource_limits.user_space_size = "1680MB"resource_limits.kernel_space_heap_size="64MB"resource_limits.max_num_of_threads = 64process.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零碎调用。

  1. 进入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运行起来后的根目录。

  1. 将Occlum容器环境下的libz.so.1文件拷贝到image/lib；
cp /usr/local/occlum/x86_64-linux-musl/lib/libz.so.1 image/lib
  1. 构建image秘密镜像；

occlum build

  1. 启动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.cint function(int a, int b) {    return a + b;}// host.cint 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.cint 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业务逻辑。次要有如下几个特点：

  1. 都属于Host-Enclave编程模型，Asylo在肯定水平上也反对Full-Feature编程模型；
  2. 开发难度大，Host-Enclave编程模型须要对应用程序做二分；
  3. 仅反对C/C++编程语言，无奈反对像Java/Go等高级编程语言；
  4. 不反对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秘密计算编程模型，易用性高、反对多种编程语言和简单的利用。这种解决方案次要存在以下问题:

  1. TCB增大，就义了肯定的安全性；
  2. 须要耗费更多的SGX硬件资源；
  3. 频繁的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秘密计算感兴趣或者有需要的开发者尝试咱们的计划，期待与大家进一步的交换。

原文链接
本文为阿里云原创内容，未经容许不得转载。