Skip to main content

Podling Teaclave Report - October 2020

Mingshen Sun

Teaclave​

Teaclave is a universal secure computing platform, making computation on privacy-sensitive data safe and simple.

Teaclave has been incubating since 2019-08-20.

Three most important unfinished issues to address before graduating:​

  1. Improve project structure and documentation
  2. Grow the community (attracting more committers, contributors, users)
  3. Publish Apache releases (resolving logistics on Apache release)

Are there any issues that the IPMC or ASF Board need to be aware of?​

None.

How has the community developed since the last report?​

Since the last report, we received contributions from a new contributor. We also received many issue reports and questions regarding the usages, bugs, and roadmap of Teaclave. Also, we presented the Teaclave project in recent ApacheCon to the community and received some useful feedback.

How has the project developed since the last report?​

The main goal of development since the last report is to resolve logistics towards the first Apache release. This includes license checking, building system improvement, documentation and write-ups. On Oct 9th, the Teaclave community and incubator has passed 0.1.0 release voting.

How would you assess the podling's maturity?​

Please feel free to add your own commentary.

  • Initial setup
  • Working towards first release
  • Community building
  • Nearing graduation
  • Other:

Date of last release:​

2020-10-09

When were the last committers or PPMC members elected?​

We haven't started new committers or PPMC members elections yet. Currently, our work focuses on the first Apache release. We'll switch to community building in the next quarter. Currently, we already have potential candidates for the new PPMC members election.

Have your mentors been helpful and responsive?​

Yes. They have been helpful and very responsive for the first public release.

Is the PPMC managing the podling's brand / trademarks?​

We don't find any 3rd parties incorrectly using the podling's name and brand. The VP, Brand has approved the project name. (PODLINGNAMESEARCH-175)

Podling Teaclave Report - July 2020

Mingshen Sun

Teaclave​

Teaclave is a universal secure computing platform, making computation on privacy-sensitive data safe and simple.

Teaclave has been incubating since 2019-08-20.

Three most important unfinished issues to address before graduating:​

  1. Improve project structure and documentation
  2. Grow the community (attracting more committers, contributors, users)
  3. Publish Apache releases (resolving logistics on Apache release)

Are there any issues that the IPMC or ASF Board need to be aware of?​

No.

How has the community developed since the last report?​

Since the last report, we started to reach out to people using the project and collect suggestions and encourage them to join in the community. We have found four organizations and eight projects that are using either the Teaclave platform and Teaclave's Rust SGX SDK.

We also created a website for the project: https://teaclave.apache.org/, which contains project description, community, contributors, documentations and blog posts.

We started a thread to discuss the logo design, but haven't received any proposal for now. We will drive this issue in the next few weeks.

We observed more people posting feature suggestions and build/deployment issues. More than five new contributors begin to contribute bug fixes and introduce new examples.

We started preparing the first Apache release such as logistics on licenses of third-party libraries.

How has the project developed since the last report?​

Since the last report, we have completed the development roadmap towards the first public release (https://github.com/apache/incubator-teaclave/issues/121) proposed last year. We began to put more efforts on improving documents and building community.

We wrote many documents in recent weeks including:

  • Try: Tutorials on using the Teaclave platform.
  • Design: Some explanations of design choices we made.
  • Contribute: Documents on contributing to Teaclave, such as debugging tips and Rust development guideline.
  • Codebase: Documents for each sub-directory (i.e., libraries in Teaclave).
  • API Docs: Generated API documentations like APIs of Client SDK.

We also provided more examples to help beginners to understand the basic usages of the projects.

How would you assess the podling's maturity?​

  • Initial setup
  • Working towards first release
  • Community building
  • Nearing graduation
  • Other:

Date of last release:​

N/A

When were the last committers or PPMC members elected?​

We haven't started new committers or PPMC members elections yet. Currently, our work focuses on improving the documents to make the project more approachable for newcomers. Additionally, we see some regular contributors recently mainly focus on helping to improve examples, SDK, etc.

Have your mentors been helpful and responsive?​

Yes, our mentors help us with the website development and logo design. Also, our mentors provided valuable thoughts regarding Intel's recent security issues.

Is the PPMC managing the podling's brand / trademarks?​

We don't find any 3rd parties incorrectly using the podling's name and brand. The VP, Brand has approved the project name. (PODLINGNAMESEARCH-175)

Podling Teaclave Report - April 2020

Mingshen Sun

Teaclave​

Teaclave is a universal secure computing platform.

Teaclave has been incubating since 2019-08-20.

Three most important unfinished issues to address before graduating:​

  1. Improving project structure and documentation
  2. Grow the community (committers, contributors, users)
  3. Publish Apache release

Are there any issues that the IPMC or ASF Board need to be aware of?​

No.

How has the community developed since the last report?​

  • Since last report, one external contributor has became our regular contributor.
  • Compared to the last report, we have seen more pull request from external contributors.
  • We received emails from some companies which are interested in the project and willing to make some contributions for the secure computing community.
  • Since we are mainly working on GitHub, with the help of the INFRA team, we can sync the notifications of GitHub with our mailing list.

How has the project developed since the last report?​

  • Since last report, the whole project has been refactored to be more functional, as well as readable and approachable for new contributors.
  • We have rewrote the framework for implementing enclave services. Also, we have redesigned current services into seven core services including access control, authentication, execution, frontend, management, scheduler, and storage service. Communication protocols between services are defined in protobuf.
  • RPC between services has been redesigned to supported TLS-based attestation.
  • We have added DCAP attestation algorithm in the platform so that people can deploy the system in environments without Intel's attestation service.
  • Communication between app and enclave has been also redesigned with better APIs.
  • All updates is currently in the develop branch. We plan to merge into master when main refactoring is done.

How would you assess the podling's maturity?​

Please feel free to add your own commentary.

  • Initial setup
  • Working towards first release
  • Community building
  • Nearing graduation
  • Other:

Date of last release:​

N/A

When were the last committers or PPMC members elected?​

We haven't started new committers or PPMC members elections yet. Currently, our work focus on improving the design and documents to make the project more approachable for newcomers.

Have your mentors been helpful and responsive?​

Yes, our mentors help use to resolve the mailing list moderator issues.

Is the PPMC managing the podling's brand / trademarks?​

We don't find any 3rd parties incorrectly using the podling's name and brand. The VP, Brand has approve the project name. (PODLINGNAMESEARCH-175)

Podling Teaclave Report - January 2020

Mingshen Sun

Teaclave​

Teaclave is a universal secure computing platform.

Teaclave has been incubating since 2019-08-20.

Three most important unfinished issues to address before graduating:​

  1. Improving project structure and documentation
  2. Grow the community (committers, contributors, users)
  3. Publish Apache release

Are there any issues that the IPMC or ASF Board need to be aware of?​

No.

How has the community developed since the last report?​

  • Since last report, we planned to schedule an online meetup recently.
  • We have also received contributions of two new contributors.
  • We draft a roadmap RFC for discussion.
  • We use GitHub issues to track bugs, features, enhancements. Issues labeled with "good first issues" is more approachable for newcomers.

How has the project developed since the last report?​

  • Resolve all renaming issues of INFRA (INFRA-19532)
  • Refactor components: teaclave_utils, teaclave_config, teaclave_cli, teaclave_binder
  • Rewrite README.md to clearly explain the project's highlights in security, functionality, and usability.
  • Start to use protobuf for RPC definition
  • SGX SDK starts to use Intel SGX SDK v2.7.1

How would you assess the podling's maturity?​

  • Initial setup
  • Working towards first release
  • Community building
  • Nearing graduation
  • Other:

Date of last release:​

N/A

When were the last committers or PPMC members elected?​

We haven't started new committers or PPMC members elections yet. Currently, our work focus on improving the design and documents to make the project more approachable for newcomers.

Have your mentors been helpful and responsive?​

Yes. Last month, we changed name from MesaTEE to Teaclave. There are a lot of changes need to be done. The mentors and infra teams help us a lot on the transfer.

Is the PPMC managing the podling's brand / trademarks?​

We don't find any 3rd parties incorrectly using the podling's name and brand. The VP, Brand has approve the project name. (PODLINGNAMESEARCH-175)

Mitigation of Intel-SA-00219 in Teaclave SGX SDK

Yu Ding

Background​

Intel issued Intel SA-00219 on Nov 12, 2019, with CVE number CVE-2019-0117. Intel also published a guidance to instruct the developers/researchers. Then Intel released Intel SGX SDK v2.7.1, including new memory allocation primitives and corresponding patches in PSW enclaves.

This article is to help people understand Intel-SA-00219, and how Teaclave SGX SDK handles it.

The problem statement and my thoughts​

The only statement I found is on the Intel-SA-00219 page:

Organize the code/data within enclave memory to avoid putting sensitive materials in DWORD0 and DWORD1 of cache line. The effectiveness of this mitigation is dependent on the ability for the software to avoid the affected memory region. To assist the enclave application providers to modify their code, Intel is releasing SGX SDK update (Windows version 2.5.101.3, Linux version 2.7.101.3) with new memory allocation APIs to avoid the affected memory region. More details about the APIs can be found here.

Intel does not directly describe the vulnerability here. But it's clear that the 64-byte cache line would contain 8-byte or sensitive data, which can be keys protected by Intel SGX. So the following memory layout can be problematic in SGX:

 --------------------------------------------------------------------------------------
| attacker accessible data A | private key (inaccessible) | attacker accessible data B |
 --------------------------------------------------------------------------------------

It's equal to a vulnerable data structure like:

struct foo {
    uint64_t A;
    uint64_t secret;
    uint64_t B;
}

where foo.A and foo.B are accessible by design, while foo.secret is not.

If an attacker somehow can access either A or B, he probably will have first or last 8-byte of the "inaccessible" secret in cache line. Then something bad may happen.

So, the most straightforward mitigation is to insert additional "guard bytes" before and after the sensitive data:

 ----------------------------------------------------------------------------------------------
| attacker data A | 8-byte guard | private key (inaccessible) | 8-byte guard | attacker data B |
 ----------------------------------------------------------------------------------------------

It results in a modified structure like

struct foo {
    uint64_t A;
    (private) uint64_t _guard0;
    uint64_t secret;
    (private) uint64_t _guard1;
    uint64_t B;
}

Further investigation from Intel's code reveals that _guard1 is not required. So it can be:

     -------------------------------------------------------------------------------
    | attacker data A | 8-byte guard | private key (inaccessible) | attacker data B |
     -------------------------------------------------------------------------------

Intel's new allocator primitive​

Intel's guidance provides:

(1) A C++ template custom_alignment_aligned (2) A C function sgx_get_aligned_ptr and one of its parameter's type struct align_req_t (3) A dynamic memory allocator function sgx_aligned_malloc

After spending hours on Intel's code, I realized that these primitives are helping developers allocate a larger object which:

a) contains all fields of the original object. b) adds "guard bytes" before and after each "specified secret field". c) align each "specified secret field" on demand

Intel's patches on PSW enclaves​

The most easy to understand example is from psw/ae/pse_op/session_mgr.cpp:

@@ -417,7 +461,12 @@ pse_op_error_t pse_exchange_report(uint64_t tick,
 {
     pse_op_error_t status = OP_SUCCESS;
     sgx_dh_session_t sgx_dh_session;
-    sgx_key_128bit_t aek;
+    //
+    // securely align aek
+    //
+    //sgx_key_128bit_t aek;
+    sgx::custom_alignment_aligned<sgx_key_128bit_t, sizeof(sgx_key_128bit_t), 0, sizeof(sgx_key_128bit_t)> oaek;
+    sgx_key_128bit_t& aek = oaek.v;
     sgx_dh_session_enclave_identity_t initiator_identity;
     cse_sec_prop_t * pcse_sec = NULL;
     secu_info_t* psec_info = NULL;

The template generates a larger struct oaek. Size of sgx_key_128bit_t is 16 bytes, and sizeof(oaek) equals to 32. And the offset of oaek.v is 8.

And in the same file, another fix is:

--- a/psw/ae/pse/pse_op/session_mgr.cpp
+++ b/psw/ae/pse/pse_op/session_mgr.cpp
@@ -29,21 +29,65 @@
  *
  */

-
+#include <sgx_secure_align.h>
 #include "utility.h"
 #include "session_mgr.h"
 #include "pse_op_t.h"
 #include "sgx_dh.h"

 // ISV enclave <-> pse-op sessions
-static pse_session_t        g_session[SESSION_CONNECTION];
+//
+// securely align all ISV enclave - pse sessions' secrets
+//
+static sgx::custom_alignment_aligned<pse_session_t, 16, __builtin_offsetof(pse_session_t, active.AEK), 16> og_session[SESSION_CONNECTION];
+//
+// following allows existing references to g_session[index]
+// to not have to change
+//
+class CSessions
+{
+public:
+    pse_session_t& operator[](int index) {
+        return og_session[index].v;
+    }
+};
+static CSessions g_session;
 static uint32_t             g_session_count = 0;

It seems that the original global g_session array is vulnerabile to INTEL-SA-00219. So Intel created a new structure CSessions and reloaded the [] operator, and used custom_alignment_aligned template to create the array of guarded CSessions.

We can see some more complex samples in the same file, such as:

 // ephemeral session global variables
 static uint8_t              g_nonce_r_pse[EPH_SESSION_NONCE_SIZE] = {0};      // nonce R(PSE) for ephemeral session establishment
 static uint8_t              g_nonce_r_cse[EPH_SESSION_NONCE_SIZE] = {0};      // nonce R(CSE) for ephemeral session establishment
-static pairing_data_t       g_pairing_data;                       // unsealed pairing data
-eph_session_t               g_eph_session;                        // ephemeral session information
+
+//
+// securely align pairing data
+// Id_pse and Id_cse aren't secrets
+// I don't think pairingNonce is a secret and even if it is, we can't align
+// all of [mk, sk, pairingID, pairingNonce]
+//
+//static pairing_data_t       g_pairing_data;                       // unsealed pairing data
+static sgx::custom_alignment<pairing_data_t,
+    //__builtin_offsetof(pairing_data_t, secret_data.Id_pse), sizeof(((pairing_data_t*)0)->secret_data.Id_pse),
+    //__builtin_offsetof(pairing_data_t, secret_data.Id_cse), sizeof(((pairing_data_t*)0)->secret_data.Id_cse),
+    __builtin_offsetof(pairing_data_t, secret_data.mk), sizeof(((pairing_data_t*)0)->secret_data.mk),
+    __builtin_offsetof(pairing_data_t, secret_data.sk), sizeof(((pairing_data_t*)0)->secret_data.sk),
+    __builtin_offsetof(pairing_data_t, secret_data.pairingID), sizeof(((pairing_data_t*)0)->secret_data.pairingID)
+    //__builtin_offsetof(pairing_data_t, secret_data.pairingNonce), sizeof(((pairing_data_t*)0)->secret_data.pairingNonce)
+    > opairing_data;
+pairing_data_t& g_pairing_data = opairing_data.v;
+//
+// securely align pse - cse/psda ephemeral session secrets
+//
+//eph_session_t               g_eph_session;                        // ephemeral session information
+sgx::custom_alignment<eph_session_t,
+    __builtin_offsetof(eph_session_t, TSK), sizeof(((eph_session_t*)0)->TSK),
+    __builtin_offsetof(eph_session_t, TMK), sizeof(((eph_session_t*)0)->TMK)
+> oeph_session;
+//
+// this reference trick requires change to declaration
+// in other files, but still cleaner than changing
+// all references
+//
+eph_session_t& g_eph_session = oeph_session.v;

 /**
  * @brief Check the status of the ephemeral session

To understand it, let me expand struct pairing_data_t here:

/* Pairing blob unsealed and usable inside of enclave*/
typedef struct _pairing_data_t
{
    se_plaintext_pairing_data_t plaintext; // does not involved
    struct se_secret_pairing_data_t {
            SHA256_HASH         Id_pse;
            SHA256_HASH         Id_cse;
            SIGMA_MAC_KEY       mk;
            SIGMA_SECRET_KEY    sk;
            SIGMA_SECRET_KEY    pairingID;  // old_sk used for repairing check
            Nonce128_t          pairingNonce;
            EcDsaPrivKey        VerifierPrivateKey;
    } secret_data;
} pairing_data_t;

The patch seems to protect mk, sk, and pairingID, and all the other fields are commented out. What's more, this patch uses a undocumented template sgx::custom_alignment defined as:

    template <class T, std::size_t... OLs>
    using custom_alignment = custom_alignment_aligned<T, alignof(T), OLs...>;

Experiments on the undocument template​

To test how the undocumented template work, I write the following codes:

    struct foo {
        uint64_t secret1[5];       // offset = 0
    };

    typedef sgx::custom_alignment<foo, __builtin_offsetof(foo, secret1), sizeof(((foo*)0)->secret1)> AFOO;

    printf("=== Size of foo = %u ===\n", sizeof(foo));                               // 40
    printf("=== Size of bar = %u ===\n", sizeof(AFOO));                              // 64
    printf("=== offset of AROO.v = %u ===\n", __builtin_offsetof(AFOO, v));          // 8
    printf("=== offset of secret1 = %u ===\n", __builtin_offsetof(AFOO, v.secret1)); // 8

So we can see that the structure of AROO is:

struct AROO {
    uint64_t _padding_head[1]         // offset = 0, len = 8
    struct {
        uint64_t secret1[5];          // offset = 8, len = 40
    } v;
    uint64_t _padding_tail[2];        // offset = 40, len = 16

It seems the undocumented C++ template aligns AROO to the next level, and add 8-byte headings into it. If we add the second secret in foo like:

    struct foo {
        uint64_t secret1[5];       // offset = 0
        uint64_t secret2[1];       // offset = 40
    };

    typedef sgx::custom_alignment<foo,
                __builtin_offsetof(foo, secret1), sizeof(((foo*)0)->secret1),
                __builtin_offsetof(foo, secret2), sizeof(((foo*)0)->secret2)
            > AFOO;

    printf("=== Size of foo = %u ===\n", sizeof(foo));            // 48
    printf("=== Size of bar = %u ===\n", sizeof(AFOO));           // 64
    printf("=== offset of AROO.v = %u ===\n", __builtin_offsetof(AFOO, v));           // 8
    printf("=== offset of AROO.v.secret1 = %u ===\n", __builtin_offsetof(AFOO, v.secret1));           // 8
    printf("=== offset of AROO.v.secret2 = %u ===\n", __builtin_offsetof(AFOO, v.secret2));           // 48

we can see that the structure of AROO is:

struct AROO {
    uint64_t _padding_head[1]         // offset = 0, len = 8
    struct {
        uint64_t secret1[5];          // offset = 8, len = 40
        uint64_t secret2[1];          // offset = 48, len = 8
    } v;
    uint64_t _padding_tail[1];        // offset = 56, len = 8

If we increase secret2 to 16-bytes, it works well as usual. And the _padding_tail will have zero length. So does it means that only extra heading is required for mitigation? But it'll not compile if we make secret2 24-bytes, like:

    struct foo {
        uint64_t secret1[5];       // offset = 0
        uint64_t secret2[3];       // offset = 40
    };

    typedef sgx::custom_alignment<foo,
                __builtin_offsetof(foo, secret1), sizeof(((foo*)0)->secret1),
                __builtin_offsetof(foo, secret2), sizeof(((foo*)0)->secret2)
            > AFOO;

GCC would terminate on:

make[1]: Entering directory '/root/linux-sgx/SampleCode/Cxx11SGXDemo'
In file included from Enclave/TrustedLibrary/Libcxx.cpp:47:0:
/opt/sgxsdk/include/sgx_secure_align.h: In instantiation of 'struct sgx::__custom_alignment_internal::custom_alignment<ecall_lambdas_demo()::foo, 8ul, -1>':
Enclave/TrustedLibrary/Libcxx.cpp:125:53:   required from here
/opt/sgxsdk/include/sgx_secure_align.h:123:13: error: static assertion failed: No viable offset
             static_assert(LZ > 0, "No viable offset");
             ^
/opt/sgxsdk/include/sgx_secure_align.h:125:48: error: size of array is negative
             char __no_secret_allowed_in_here[LZ];
                                                ^
Makefile:255: recipe for target 'Enclave/TrustedLibrary/Libcxx.o' failed

Nothing changes if we switch to the original template sgx::custom_alignment_aligned. So I guess the template does not support structures:

  • contains secrets consecutively, and
  • the consecutive secrets' size is larger than a certain number (not sure yet)

If we break down secret1 and secret2 by inserting something in the middle, the template works:

struct foo {
  uint64_t secret1[5];       // offset = 0
  char     dumb;             // offset = 40
  uint64_t secret2[3];       // offset = 48
};

typedef sgx::custom_alignment<foo,
__builtin_offsetof(foo, secret1), sizeof(((foo*)0)->secret1),
__builtin_offsetof(foo, secret2), sizeof(((foo*)0)->secret2)
  > AFOO;

printf("=== Size of foo = %u ===\n", sizeof(foo));            // 72
printf("=== Size of bar = %u ===\n", sizeof(AFOO));           // 128
printf("=== offset of AROO.v = %u ===\n", __builtin_offsetof(AFOO, v));           // 24
printf("=== offset of AROO.v.secret1 = %u ===\n", __builtin_offsetof(AFOO, v.secret1));           // 24
printf("=== offset of AROO.v.secret2 = %u ===\n", __builtin_offsetof(AFOO, v.secret2));           // 72

Changes/Actions required​

From Intel's usage, we can learn that:

**Don't construct a sensitive data structure directly. Always allocate an aligned structure and fill it up later **

It means:

  • if you allocate something sensitive (e.g. keys in sgx_key_128bit_t) on stack/heap, you probably need to allocate another guarded structure first, and get a mutable reference to its inner data.
  • if you want to make sgx_key_128bit_t as the type of return value, you can choose between (1) return a guarded structure, or (2) takes an additional argument of caller-allocated, mutuable reference of sgx_key_128bit_t and fill it.

Rust SGX provided primitive​

  • We provided AlignBox as a replacement of Box

    • Box is somewhat tricky because it always "initialize on stack first and copy to heap later". copyless provides a novel primitive to solve it but it does not always effective. To this end, we created AlignBox which guarantees "on-heap initialization" without copying any bits. Usage:

      let heap_align_obj = AlignBox::<struct_align_t>::heap_init_with_req(|mut t| {
        t.key1 = [0xf0, 0xf1, 0xf2, 0xf3, 0xf4, 0xf5, 0xf6, 0xf7, 0xf8, 0xf9, 0xfa, 0xfb, 0xfc, 0xfd, 0xfe, 0xff];
        t.pad1 = [0x00; 16];
        t.key2 = [0xf0, 0xf1, 0xf2, 0xf3, 0xf4, 0xf5, 0xf6, 0xf7, 0xf8, 0xf9, 0xfa, 0xfb, 0xfc, 0xfd, 0xfe, 0xff];
        t.pad2 = [0x00; 16];
        t.key3 = [0xf0, 0xf1, 0xf2, 0xf3, 0xf4, 0xf5, 0xf6, 0xf7, 0xf8, 0xf9, 0xfa, 0xfb, 0xfc, 0xfd, 0xfe, 0xff];
        t.pad3 = [0x00; 16];
        t.key4 = [0xf0, 0xf1, 0xf2, 0xf3, 0xf4, 0xf5, 0xf6, 0xf7, 0xf8, 0xf9, 0xfa, 0xfb, 0xfc, 0xfd, 0xfe, 0xff];
        }, 16, &str_slice);
      assert!(heap_align_obj.is_some());

  • We provided aligned key type for each built-in key type. The layout are calculated by Intel's template.

    • sgx_align_key_128bit_t
    • sgx_align_mac_128bit_t
    • sgx_align_key_256bit_t
    • sgx_align_mac_256bit_t
    • sgx_align_ec256_dh_shared_t
    • sgx_align_ec256_private_t

We modified sgx_tcrypto, sgx_tse, and sgx_tdh and use the above primitives for enhancement, following the above required changes. One sample is from sgx_tcrypto:

+    let mut align_mac = sgx_align_mac_128bit_t::default();
+    let ret = unsafe {
+        sgx_rijndael128_cmac_msg(key as * const sgx_cmac_128bit_key_t,
+                                 src.as_ptr() as * const u8,
+                                 size as u32,
+                                 &mut align_mac.mac as * mut sgx_cmac_128bit_tag_t)
+    };

We allocate an aligned structure first, and then fill it up using Intel's crypto primitive later.

Aapache Incubation Proposal

The Teaclave PPMC
MesaTEE Apache Incubation Proposal

= Abstract =

MesaTEE is a framework for universal secure computing.

= Proposal =

MesaTEE is the next-gen solution to enable general computing service for
security-critical scenarios. It will allow even the most sensitive data to
be securely processed to enable offshore businesses without leakage.

The solution combines the advanced Hybrid Memory Safety (HMS) model and the
power of the Trusted Computing technologies (e.g., TPM) as well as the
Confidential Computing technologies (e.g., Intel SGX).

  * Code base:
    * https://github.com/mesalock-linux/mesatee
    * https://github.com/baidu/rust-sgx-sdk
  * Website: https://mesatee.org
  * Documentation: https://mesatee.org/doc/mesatee_sdk/

= Background =

The emerging technologies of big data analytics, machine learning, cloud/edge
computing, and blockchain are significantly boosting our productivity, but at
the same time they are bringing new confidentiality and integrity concerns. On
public cloud and blockchain, sensitive data like health and financial records
may be consumed at runtime by untrusted computing processes running on
compromised platforms; during in-house data exchange, confidential information
may cross different clearance boundaries and possibly fall into the wrong hands;
also not to mention the privacy issue arises in offshore data supply chains.

Although the consequences of data breaching have been extensively elaborated, we
should also note that proprietary computing algorithms themselves, such as AI
models, also need to be well protected. Once leaked, attackers can steal the
intellectual properties, or launch whitebox attacks and easily exploit the
weaknesses of the models.

Facing all these risky scenarios, we are in desperate need of a trusted and
secure mechanism, enabling us to protect both private data and proprietary
computing models during a migratable execution in potentially unsafe
environments, yet preserving functionalities, performance, compatibility, and
flexibility. MesaTEE is targeting to be, as we call it, the full "Universal
Secure Computing" stack, so it can help users resolve these runtime security
risks.

MesaTEE aims to promote the development of universal secure computing ecosystem
through open source and openness, to provide basic support for trust protection
for the productivity revolution brought by big data and AI, to completely solve
the data exchange or multi-party computing between departments/companies, to
enable privacy-crucial services such as financial and medical care using
blockchain/cloud services, and to convoy businesses that are closely related to
life and safety such as autonomous driving. MesaTEE has been working closely
with mainstream cloud computing/blockchain/chip vendors and
universities/research institutions to promote hardware TEE, software memory
safety, and versatile computing services to create an internationally protected
and flexible secure computing framework. MesaTEE’s open-source release will
greatly accelerate the development of the next generation of big data business
applications, and it is also of great importance to promoting AI in all business
areas.

= Rationale =

MesaTEE stack redefines future AI and big data analytics by providing a trusted
and secure offshore computing environment. The confidentiality and privacy of
data and models can be well protected with MesaTEE, even if data and model
originate from different parties with no mutual trust. Moreover, the computing
platform itself is not necessarily trusted either. The Trusted Computing Base
(TCB) can thus be largely reduced to MesaTEE framework alone. A detailed
description of target use-cases can be found at
https://github.com/mesalock-linux/mesatee/blob/master/docs/case_study.md.

We believe that Apache way of open source community empowers MesaTEE to attract
a diverse set of contributors who can bring new ideas into the project.

= Initial Goals =

  * Move the existing codebase, website, documentation, and mailing lists to an
    Apache-hosted infrastructure.
  * Integrate with the Apache development process.
  * Ensure all dependencies are compliant with Apache License version 2.0.
  * Incrementally develop and release per Apache guidelines.

= Current Status =

The MesaTEE project (and its sub-project Rust SGX SDK) has been designed and
developed at Baidu since 2017, and was open sourced under the Apache License,
Version 2.0 in 2019. The source code is currently hosted at github.com
(https://github.com/mesalock-linux/mesatee and
https://github.com/baidu/rust-sgx-sdk), which will seed the Apache git
repository.

== Meritocracy ==

We are fully committed to open, transparent, and meritocratic interactions with
our community. In fact, one of the primary motivations for us to enter the
incubation process is to be able to rely on Apache best practices that can
ensure meritocracy. This will eventually help incorporate the best ideas back
into the project and enable contributors to continue investing their time in the
project. We already have some guidelines to help external contributors:

  * https://github.com/mesalock-linux/mesatee/blob/master/docs/rust_guideline.md
  * https://github.com/mesalock-linux/mesatee/blob/master/docs/how_to_add_your_function.md
  * https://github.com/mesalock-linux/mesatee/blob/master/CODE_OF_CONDUCT.md

== Community ==

The MesaTEE community is fairly young. Since our sub-project (Rust SGX SDK) was
open sourced in 2017, we received many contributions from various companies and
individual researchers (https://github.com/baidu/rust-sgx-sdk/pulls). Our
primary goal during the incubation would be to grow the community and groom our
existing active contributors for committers.

== Core Developers ==

Current core developers work at Baidu. We are confident that incubation will
help us grow a diverse community in an open and collaborative way.

== Alignment ==

MesaTEE is designed as a framework for universal secure computing. This is
complementary to the Apache's projects, providing a trusted and secure computing
framework.

Our sincere hope is that being a part of the Apache foundation would enable us
to drive the future of the project in alignment with the other Apache projects
for the benefit of thousands of organizations that already leverage these
projects.

= Known Risks =

== Orphaned Products ==

The risk of abandonment of MesaTEE is low. MesaTEE has been incubated at Baidu
for over two years. Baidu is committed to the further development of the project
and will keep investing resources towards the Apache processes and community
building, during the incubation period.

== Inexperience with Open Source ==

Even though the initial committers are new to the Apache world, some have
considerable open source experience - Yu Ding, Yiming Jing, Mingshen Sun. We
have been successfully managing the current open source community, answering
questions, and taking feedback already. Moreover, we hope to obtain guidance and
mentorship from current ASF members to help us succeed in the incubation.

== Length of Incubation ==

We expect the project to be in incubation for 2 years or less.

== Homogenous Developers ==

Currently, the lead developers for MesaTEE are from Baidu. However, we have an
active set of early contributors/collaborators from Alibaba and other companies,
which we hope will increase the diversity going forward. Once again, a primary
motivation for the incubation is to facilitate this in the Apache way.

== Reliance on Salaried Developers ==

Both the current committers and early contributors have several years of core
expertise around designing trusted computing systems. Current committers are
very passionate about the project and have already invested hundreds of hours
towards helping and building the community. Thus, even with employer changes, we
expect they will be able to actively engage in the project either because they
will be working in similar areas even with newer employers or out of belief in
the project.

== Relationships with Other Apache Products ==

To the best of our knowledge, there are no directly competing projects with
MesaTEE that offer all of the feature set - memory safety, secure computing,
multi-party computation, etc. However, some projects share similar goals, e.g.,
OpenWhisk which provides a serverless cloud platform. We are committed to open
collaboration with such Apache projects and incorporating changes to MesaTEE or
contributing patches to other projects, with the goal of making it easier for
the community at large, to adopt these open source technologies.

== Excessive Fascination with the Apache Brand ==

The Apache Brand is very respected. We are very honored to have the opportunity
to join ASF, with the understanding that its brand policies shall be respected.
And we hope Apache can help us build the ecosystem around MesaTEE and attract
more developers.

= Documentation =

  * Detailed documentation: https://github.com/mesalock-linux/mesatee
  * MesaTEE SDK API documentation: https://mesatee.org/doc/mesatee_sdk/

= Initial Source =

The codebase is currently hosted on Github:

  * https://github.com/mesalock-linux/mesatee
  * https://github.com/baidu/rust-sgx-sdk

During incubation, the codebase will be migrated to an Apache infrastructure.
The source code of MesaTEE is under Apache version 2.0 License, while Rust SGX
SDK is under BSD 3-Clauses License.

= Source and Intellectual Property Submission Plan =

We will work with the committers to get ICLAs signed. We will provide a Software
Grant Agreement from an authorized signer per
https://www.apache.org/licenses/software-grant-template.pdf

= External Dependencies =

MesaTEE directly depends on these third-party Rust crates:

  * adler32, 1.0.3, BSD-3-Clause
  * aho-corasick, 0.7.4, Unlicense/MIT
  * array_tool, 1.0.3, MIT
  * assert_matches, 1.3.0, MIT/Apache-2.0
  * autocfg, 0.1.4, Apache-2.0/MIT
  * base64, 0.10.1, MIT/Apache-2.0
  * bincode, 1.1.4, MIT
  * bit-vec, 0.6.1, MIT/Apache-2.0
  * bitflags, 1.1.0, MIT/Apache-2.0
  * byteorder, 1.3.2, MIT/Unlicense
  * bytes, 0.5.0, MIT
  * cc, 1.0.37, MIT/Apache-2.0
  * cfg-if, 0.1.9, MIT/Apache-2.0
  * chrono, 0.4.7, MIT/Apache-2.0
  * color_quant, 1.0.1, MIT
  * crc32fast, 1.2.0, MIT
  * ctor, 0.1.9, Apache-2.0
  * deflate, 0.7.20, MIT/Apache-2.0
  * either, 1.5.2, MIT/Apache-2.0
  * env_logger, 0.6.2, MIT/Apache-2.0
  * erased-serde, 0.3.9, MIT
  * fnv, 1.0.6, Apache-2.0
  * getrandom, 0.1.6, MIT
  * ghost, 0.1.0, MIT/Apache-2.0
  * gif, 0.10.2, MIT/Apache-2.0
  * gzip-header, 0.3.0, MIT/Apache-2.0
  * half, 1.3.0, MIT/Apache-2.0
  * hashbrown, 0.3.1, Apache-2.0/MIT
  * heapsize, 0.4.2, MIT/Apache-2.0
  * hex, 0.3.2, MIT
  * http, 0.1.17, MIT/Apache-2.0
  * httparse, 1.3.4, MIT/Apache-2.0
  * humantime, 1.2.0, MIT/Apache-2.0
  * image, 0.21.0, MIT
  * inflate, 0.4.5, MIT
  * inventory, 0.1.3, MIT
  * inventory-impl, 0.1.3, MIT
  * iovec, 0.2.0, MIT/Apache-2.0
  * itertools, 0.8.0, MIT/Apache-2.0
  * itoa, 0.4.4, MIT
  * jpeg-decoder, 0.1.15, MIT
  * lazy_static, 1.3.0, MIT/Apache-2.0
  * libc, 0.2.59, MIT
  * linked-hash-map, 0.5.2, MIT/Apache-2.0
  * log, 0.4.7, MIT
  * lzw, 0.10.0, MIT/Apache-2.0
  * matrixmultiply, 0.2.2, MIT/Apache-2.0
  * md5, 0.6.1, Apache-2.0/MIT
  * memchr, 2.2.1, Unlicense/MIT
  * memory_units, 0.3.0, MPL-2.0
  * net2, 0.2.33, MIT/Apache-2.0
  * num, 0.2.0, MIT/Apache-2.0
  * num-bigint, 0.2.2, MIT/Apache-2.0
  * num-complex, 0.2.3, MIT/Apache-2.0
  * num-integer, 0.1.41, MIT/Apache-2.0
  * num-iter, 0.1.39, MIT/Apache-2.0
  * num-rational, 0.2.2, MIT/Apache-2.0
  * num-traits, 0.2.8, MIT/Apache-2.0
  * parity-wasm, 0.31.3, MIT/Apache-2.0
  * png, 0.14.1, MIT/Apache-2.0
  * proc-macro2, 0.4.30, MIT/Apache-2.0
  * profiler_builtins, 0.1.0, profiler_builtins
  * quick-error, 1.2.2, MIT/Apache-2.0
  * quote, 0.3.15, MIT
  * quote, 0.6.13, MIT
  * rand, 0.6.5, MIT/Apache-2.0
  * rand_core, 0.4.0, MIT/Apache-2.0
  * rand_hc, 0.1.0, MIT/Apache-2.0
  * rand_pcg, 0.1.2, MIT/Apache-2.0
  * rawpointer, 0.1.0, MIT/Apache-2.0
  * regex, 1.1.9, MIT/Apache-2.0
  * regex-syntax, 0.6.8, MIT/Apache-2.0
  * ring, 0.14.6, ISC-style
  * rulinalg, 0.4.2, MIT
  * rustls, 0.15.2, Apache-2.0/ISC/MIT
  * rusty-machine, 0.5.4, MIT
  * ryu, 1.0.0, Apache-2.0
  * sct, 0.5.0, Apache-2.0/ISC/MIT
  * serde, 1.0.94, MIT
  * serde_cbor, 0.10.0, MIT/Apache-2.0
  * serde_derive, 1.0.94, MIT
  * serde_json, 1.0.40, MIT
  * sha1, 0.6.0, BSD-3-Clause
  * sha2, 0.8.0, sha2
  * spin, 0.5.0, MIT
  * syn, 0.11.11, MIT
  * syn, 0.15.39, MIT
  * synom, 0.11.3, MIT/Apache-2.0
  * termcolor, 1.0.5, Unlicense
  * thread_local, 0.3.6, Apache-2.0/MIT
  * tiff, 0.3.1, MIT
  * toml, 0.5.1, MIT/Apache-2.0
  * typetag, 0.1.3, MIT
  * typetag-impl, 0.1.3, MIT
  * ucd-util, 0.1.3, MIT/Apache-2.0
  * unicode-xid, 0.0.4, MIT/Apache-2.0
  * unicode-xid, 0.1.0, MIT/Apache-2.0
  * utf8-ranges, 1.0.3, Unlicense/MIT
  * uuid, 0.7.4, Apache-2.0
  * wabt, 0.6.0, Apache-2.0
  * wasmi, 0.5.0, MIT/Apache-2.0
  * wasmi-validation, 0.1.0, MIT/Apache-2.0
  * webpki, 0.19.1, ISC-style
  * webpki-roots, 0.16.0, MPL-2.0
  * winapi, 0.3.7, MIT/Apache-2.0
  * winapi-i686-pc-windows-gnu, 0.4.0, MIT/Apache-2.0
  * winapi-util, 0.1.2, Unlicense/MIT
  * winapi-x86_64-pc-windows-gnu, 0.4.0, MIT/Apache-2.0
  * wincolor, 1.0.1, Unlicense/MIT
  * yasna, 0.3.1, MIT/Apache-2.0

Note that this is not an exhaustive dependency list and only direct
dependencies
of MesaTEE's trusted libs are included.

== Cryptography ==

MesaTEE uses following cryptographic libraries:

  * ring (https://github.com/briansmith/ring): a Rust crypto library based on
BoringSSL
  * rustls: a Rust TLS library
  * sgx_tcrypto in Intel SGX SDK (https://software.intel.com/en-us/sgx/sdk)

= Required Resources =

== Mailing lists ==

  * private@mesatee.incubator.apache.org (with moderated subscriptions)
  * dev@mesatee.incubator.apache.org
  * commits@mesatee.incubator.apache.org
  * user@mesatee.incubator.apache.org

== Git Repositories ==

Upon entering incubation, we want to transfer the existing repos from
https://github.com/mesalock-linux/mesatee and
https://github.com/baidu/rust-sgx-sdk to Apache organization in GitHub like:

  * https://github.com/apache/incubator-mesatee
  * https://github.com/apache/incubator-mesatee-rust-sgx-sdk

== Issue Tracking ==

MesaTEE currently uses GitHub to track issues. Would like to continue doing
so.

== Continuous Integration Service ==

MesaTEE currently uses self-hosted continuous integration (CI) service which can
help developers to automatically test commits. The CI service involves several
nodes which support Intel SGX. We would like to continue doing so.

= Initial Committers =

The list is sorted alphabetically:

  * Mingshen Sun <mssun at mesatee.org>
  * Pei Wang <wangpei at mesatee.org>
  * Rundong Zhou <rundongzhou at mesatee.org>
  * Tao Wei <lenx at mesatee.org>
  * Tongxin Li <litongxin at mesatee.org>
  * Yiming Jing <jingyiming at mesatee.org>
  * Yu Ding <d at mesatee.org>
  * Yulong Zhang <ylzhang at mesatee.org>
  * Zhaofeng Chen <zf at mesatee.org>

= Sponsors =

== Champion ==

  * Zhijie Shen <zjshen@apache.org>

== Nominated Mentors ==

  * Jianyong Dai <daijy@apache.org>
  * Luciano Resende <lresende@apache.org>
  * Matt Sicker
  * Furkan Kamaci

== Sponsoring Entity ==

The Incubator PMC