yuhala / montsalvat Goto Github PK

GraalVM's JIT compiler works with the default JVM as a plugin with the help of the JVM compiler interface (JVMCI), and thus requires a JDK which supports a graal-compatible version of JVMCI. You can find a compatible version in the montsalvat folder: openjdk-8u282+08-jvmci-21.1-b01-linux-amd64.tar.gz. Other compatible versions can be found here: jvmci releases.

Copy and extract this file in graal-sgx-root.

This tutorial will show you how to build a java application which can execute functionality in and out of an SGX enclave.

You begin by building your appication classes. In this sample application, we have 3 application classes: Contract.java, Asset.java and Peer.java, and the main class Main.java. These files should be all grouped into a folder which should be your application package. The latter should be added as a subfolder to substratevm and the APP_PKG variable in build.sh should be modified with the name of your app package. The application package for our example is smartc.

We provide the annotation SecurityInfo to specify security properties of your application classes. Annotate trusted classes with @SecurityInfo(security = "trusted") and untrusted classes with @SecurityInfo(security = "untrusted"). Your application main class should always be an untrusted class. The reason being we create special GC threads in the main method: threads cannot be created from within SGX enclaves.

Once your application has been correctly annotated, you run the build.sh script to build your app into an SGX application. During the build process, the application classes are transformed after compilation with javac. Two native images are built: a trusted image which will be linked to the trusted part of the SGX app and an untrusted image which will be linked to the untrusted part. For the trusted image build, static relay methods are added to each trusted class, for each class method, and all untrusted class methods are stripped and replaced with ocall transitions. During untrusted image building, the reverse happens.

As a result, every untrusted object created in the trusted runtime is simply a proxy for the real (mirror) copy/object in the untrusted runtime and vice versa. The mirror objects are stored in a registry together with the hash/id of the corresponding proxy in the opposite runtime. Thus each time a proxy calls an instance method a transition is done, the corresponding mirror object is located in the registry and the instance method is called on it. For static methods, the registry is not used; the corresponding method is simply called on the class. All this is done automatically by our bytecode transformer so the programmer need not worry about these technical details. All they need to do is annotate their classes accordingly or simply provide a list of trusted and untrusted classes.

Methods of unannotated classes (neutral classes) are compiled fully in any runtime if they are reachable there. For example JDK utility methods. As a result unannotated class objects will not have any proxy/mirror variants.

Primitive and object types can be passed as parameters. However we still have issues with object return types. Neutral objects are all serialized when passed across the enclave boundary and recreated at the other side.

Many other interesting things are done under the hood by our system, but are out of the scope of this simple tutorial. The full internal workings of the system will be described in a corresponding paper.

To build and test the sample application, CD into graal-tee directory and run the script: build.sh script.

The above script also leverages the native image agent tool to generate useful configurations files in case your application uses reflection, serialization etc.

The script builds two native images: main_in.o (trusted object) and main_out.o (untrusted object) which will be copied to the sgx module and linked to the trusted and untrusted runtimes respectively of the resulting Intel SGX application. The corresponding proxy routines and EDL files for SGX ecalls and ocalls are generated by the SGX Proxy Generator.

CD into the sgx module and run the script make clean && make to build the final enclave application.

In the event of linker errors with liblibchelper.a, remove the latter from sgx/Common folder and replace it with the one built during the build process above which can be found here: substratevm/mxbuild/linux-amd64/SVM_HOSTED_NATIVE/linux-amd64/liblibchelper.a

Rebuild the SGX program.