當Java遇上機密計算，又一段奇幻之旅開始了！

寫在前面

在資訊世界裡，資料存在三種狀态：存儲态、傳輸态和計算态。存儲在資料庫或磁盤中的資料屬于存儲狀态，在網絡中傳輸的資料屬于傳輸狀态，正在被計算處理的資料屬于計算狀态。我們需要從資料三種狀态出發進行系統的安全保護，才能確定真正的資料安全。對于存儲态和傳輸态資料安全問題，我們可以利用被廣泛使用的資料加密技術進行有效保護。對于計算态的資料安全保護仍舊屬于新的前沿領域。

基于硬體的機密計算技術(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項目：