Road to the true sdk: Design Proposal

[clangenb]

The past few days, I could not get rid of these thoughts: What makes substrate so easy to expand and develop on? It is the frame concept, the aggregation of modules (called pallets) that are as individual crates loosely coupled through the frame_system::Config trait.

Using that concept as design guidelines, I believe it is feasible to implement a similar concept for the Integritee worker, which I call now frame_enclave/frame_worker. Instead of proxying the interactions of the worker and the enclave via a single Bridge, each enclave-pallet should contain all the information that is needed to set up the trusted/untrusted communication it needs.

Example

An example enclave-pallet could look as follows:

// enclave_frame_system::Config is the fundamental config that is an abstractrion over the
// basic things like FileAccess, RemoteAttestation, etc.

pub trait Config: enclave_frame_system::Config {
     // absraction of the sgx file IO.
     type SgxState: <Self as frame_system::Config>::StateAccess
}

declare_enclave_pallet! {
    // todo maybe decouple ocalls and ecalls
    struct Pallet<T: Config> {
            // ocalls

           // ecalls
    }
}

// some other functions and stuff.

Depending on environment, std or no_std, the declare_enclave_pallet! macro does the following;

no_std:

• ocall: only compile the ffi interface.
• ecall: compiles the full function,

std:

• ocall: compiles the full function
• ecall: only compile the ffi interface

the in the two main files we have the following:

//enclave/main.rs

struct Runtime;

iml frame_enclave_system::Config for Runtime {
    // dunno yet what we need there but
   // something we'd probably always want is
   type StateAccess = SgxState
}

// inject_runtime is inspired by substrates `construct_runtime!` but behaves a little bit different.
inject_runtime! {
    frame_enclave_system // fundamendal pallet that is probably always included.
    my_pallet_2
}

//worker/main.rs

pub struct Runtime;

iml frame_worker_system::Config for Runtime {
    // dunno yet what we need there
}
  
inject_runtime! {
    frame_worker_system, 
    my_pallet_2
}

Where the inject_runtime! macro does essentially two things:

• export the defined extern "C" function interfaces to top level such that the build process finds the ffi-definitions
• injects the concrete Runtime type, as we defined everything to be generic over T: Config in our pallets.

This macro is much less involved thatn substrate's construct_runtime!. For instance, it does not automatically create runtime metadata info, nor does it populate some genesis storage.

Build-Process

There is one problem; the .edl files. We want to avoid creating the edl files manually, even less if the definitions are scattered of all the enclave_pallets. Furthermore, I would like to be able to execute the whole build process with cargo build Hence, I propose the following:

• edl-gen: crate containing two proc-macros that creates an edl file containing the functions that are annotated with either #[ocall], or #[ecall] in that create.
• sgx-build-runner: To be executed in the build.rs of the worker and maybe the enclave. It does:
  • look for all the .edl files in dependencies and assembles one overarching .edl file.
  • executes the build (basically does all the things, we do in the make file). This consists of:
    • launching cc (natively supported by cargo)
    • launching the SGX_EDGER8R process
    • executes cargo build for the enclave and the worker with the appropriate flags.

[haerdib]

I guess now is the time to bring this up. @clangenb I kindly remind you hereby ;)