关于java:当Java遇上机密计算又一段奇幻之旅开始了

简介：汪少军：如何为 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 package

java -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

3. 在 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 零碎调用。

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

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

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

7. 构建 image 秘密镜像；

occlum build

8. 启动 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 业务逻辑。次要有如下几个特点：

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 秘密计算感兴趣或者有需要的开发者尝试咱们的计划，期待与大家进一步的交换。

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