Use of --config=sgx-sim or enc-sim still supported on Asylo 0.6?

[asmprogrammer5]

I'm trying to compile hello_world on an Ubuntu 18.04 with the manual installation instructions provided in INSTALL.md. Is the config option still supported? I keep getting an error while compiling sgx_sdk. The only option to compile hello_world that works for me is if I remove --config=sgx-sim and use //asylo/examples/hello_world:hello_world_sgx_sim.

Question is whether --config=sgx-sim or --config=enc-sim still supported?

external/sgx_dcap/QuoteGeneration/common/src/se_thread.c: In function 'se_mutex_init':
external/sgx_dcap/QuoteGeneration/common/src/se_thread.c:67:2: error: #error no pre-defined RECURSIVE_MUTEX found.
 #error no pre-defined RECURSIVE_MUTEX found.
  ^~~~~
external/sgx_dcap/QuoteGeneration/common/src/se_thread.c:71:20: error: 'tmp' undeclared (first use in this function); did you mean 'tm'?
     memcpy(mutex, &tmp, sizeof(tmp));
                    ^~~
                    tm
external/sgx_dcap/QuoteGeneration/common/src/se_thread.c:71:20: note: each undeclared identifier is reported only once for each function it appears in
external/sgx_dcap/QuoteGeneration/common/src/se_thread.c: In function 'se_get_threadid':
external/sgx_dcap/QuoteGeneration/common/src/se_thread.c:89:63: error: '__NR_gettid' undeclared (first use in this function); did you mean 'SYS_gettid'?
 unsigned int se_get_threadid(void) { return (unsigned)syscall(__NR_gettid);}
                                                               ^~~~~~~~~~~
                                                               SYS_gettid
Target //asylo/examples/hello_world:hello_world_sgx_sim failed to build

or another run:

Execution platform: @local_config_platform//:host

Use --sandbox_debug to see verbose messages from the sandbox
external/linux_sgx/common/src/se_event.c:35:10: fatal error: linux/futex.h: No such file or directory
 #include <linux/futex.h>
          ^~~~~~~~~~~~~~~

The difference between --config=sgx-sim and _sgx_sim seems to be in the compiler/toolchain used:

--config=sgx-sim (fails)

bazel build --verbose_failures --config=sgx-sim //asylo/examples/hello_world:hello_world

  exec env - \
    PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin \
    PWD=/proc/self/cwd \
  external/com_google_asylo_toolchain/toolchain/bin/x86_64-elf-g++ -isystemasylo/platform/posix/include -isystemasylo/platform/system/include -isystemexternal/com_google_asylo/asylo/platform/posix/include -isystemexternal/com_google_asylo/asylo/platform/system/include -D__ASYLO__ -DCOMPILER_GCC3 -D__LINUX_ERRNO_EXTENSIONS__ '-std=gnu++17' -MD -MF bazel-out/k8-fastbuild-ST-b8b7b2b153c11a75e8c76309e6086217c874508e819ba2fc3c7ed5dc5a7e7e83/bin/external/sgx_dcap/_objs/quote_wrapper/qe_logic.pic.d

_sgx_sim (without --config options, succeeds)

bazel build -s --verbose_failures   //asylo/examples/hello_world:hello_world_sgx_sim

  exec env - \
    PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin \
    PWD=/proc/self/cwd \
  /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer '-std=c++0x' -MD -MF bazel-out/k8-fastbuild-ST-b8b7b2b153c11a75e8c76309e6086217c874508e819ba2fc3c7ed5dc5a7e7e83/bin/external/sgx_dcap/_objs/quote_wrapper/qe_logic.pic.d

[deeglaze]

The config option is not necessary in most common cases now. The new build concepts are discussed here https://asylo.dev/docs/concepts/building.html The config we used in the past changes the top level toolchain to the enclave toolchain, which will not normally work for the untrusted application part of the build. Before Bazel added the configuration transitions feature, we had to finagle the build system to bend over backwards to build the untrusted application with the appropriate toolchain (copy_from_host). I designed this new configuration, so if anything is unclear, please let me know and I’ll clarify in our documentation.

…

-Dionna

On Sun, Dec 13, 2020 at 14:42 asmprogrammer5 ***@***.***> wrote: I'm trying to compile hello_world on an Ubuntu 18.04 with the manual installation instructions provided in INSTALL.md. Is the config option still supported? I keep getting an error while compiling sgx_sdk. The only option to compile hello_world that works for me is if I remove --config=sgx-sim and use //asylo/examples/hello_world:hello_world_sgx_sim. Question is whether --config=sgx-sim or --config=enc-sim still supported? external/sgx_dcap/QuoteGeneration/common/src/se_thread.c: In function 'se_mutex_init': external/sgx_dcap/QuoteGeneration/common/src/se_thread.c:67:2: error: #error no pre-defined RECURSIVE_MUTEX found. #error no pre-defined RECURSIVE_MUTEX found. ^~~~~ external/sgx_dcap/QuoteGeneration/common/src/se_thread.c:71:20: error: 'tmp' undeclared (first use in this function); did you mean 'tm'? memcpy(mutex, &tmp, sizeof(tmp)); ^~~ tm external/sgx_dcap/QuoteGeneration/common/src/se_thread.c:71:20: note: each undeclared identifier is reported only once for each function it appears in external/sgx_dcap/QuoteGeneration/common/src/se_thread.c: In function 'se_get_threadid': external/sgx_dcap/QuoteGeneration/common/src/se_thread.c:89:63: error: '__NR_gettid' undeclared (first use in this function); did you mean 'SYS_gettid'? unsigned int se_get_threadid(void) { return (unsigned)syscall(__NR_gettid);} ^~~~~~~~~~~ SYS_gettid Target //asylo/examples/hello_world:hello_world_sgx_sim failed to build or another run: `Execution platform: @local_config_platform//:host Use --sandbox_debug to see verbose messages from the sandbox external/linux_sgx/common/src/se_event.c:35:10: fatal error: linux/futex.h: No such file or directory #include <linux/futex.h> ^~~~~~~~~~~~~~~ ` — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#62>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFL4HDBLYVJUTDDXNMPGNTSUU7ODANCNFSM4UZ3CYWQ> .

[asmprogrammer5]

Thanks, couple of follow ups:

1. Why do we still have the --config option for simulator in the tree? Since it's replaced by @com_google_asylo_backend_provider//:backend

2. If I needed to include system header files such as these below, what should I ensure?

#include <linux/types.h>
#include <linux/ioctl.h>

I am getting an error when I added some trial code in primitives/sgx/<file.cc>

 fatal error: linux/types.h: No such file or directory
 #include <linux/types.h>
          ^~~~~~~~~~~~~~~

Using external/com_google_asylo_toolchain/toolchain/bin/x86_64-elf-gcc. What is needed to include host usr/include files in this new backend model?

[deeglaze]

The Asylo enclave runtime environment does not provide a complete set of Linux APIs, so you will not be able to include all Linux system headers. We’ve added a few Linux extensions to our POSIX environment to allow for some performance improvements and added compatibility. The goal of Asylo is to be small and trustworthy, but still useful. Full Linux compatibility is an anti-goal of Asylo. If you need simple typedefs or macros, our suggestion is to copy the file into your project and depend on it explicitly.
Bazel toolchains are meant to make builds hermetic, so host system libraries will not be accessible unless explicitly depended on in the crosstool definition. The asylo/distrib/toolchain/install-toolchain script builds the Asylo toolchain and installs it with a crosstool definition with specific system header include paths (see _get_include_directories and added -isystem flags).
The --config flag is not replaced by the backend flag. The backend flag replaces the --define options (used by the --config definition), but it does not inherently change the default toolchain. The --define settings are deprecated but not yet removed due to a Bazel bug (I see it was closed last year) at the time of release and follow-up. The --config flag is still useful for building dependency libraries for enclaves that aren’t defined in a way that transitions the default toolchain to the Asylo toolchain, so we will continue to include it.

[asmprogrammer5]

Thanks, I get the point regarding the Asylo's need to be hermetic. Ok using -isystem can let me include some of these system headers.

For the backend flag, yes, I meant --config=sgx-sim that leads to SGX_SIM=1 value.

But going back to the Asylo's small and trustworthy goal, we still need the Intel's SGX SDK, that includes many of the system header files right? Is that ok or is there a plan to change that?

[deeglaze]

Asylo uses a small subset of the Intel SDK for creating the enclave execution context and some ecall/ocall handling. I wouldn’t say either Asylo or Intel SGX SDK use many linux system headers for building enclaves because we both have self-contained trusted runtimes. Including a header for type declarations is something we’ll do, and in some cases we’ll define declared symbols as immediate aborts just to be compatible at linking time. We do thorough testing to ensure execution paths we need do not end up calling the stubbed functions. The include paths and headers we provide are meant to ease porting efforts. Do you have pointers to headers we use or Intel SGX SDK uses transitively that are cause for concern?

…

On Thu, Dec 17, 2020 at 11:44 asmprogrammer5 ***@***.***> wrote: Thanks, I get the point regarding the Asylo's need to be hermetic. Ok using -isystem can let me include some of these system headers. For the backend flag, yes, I meant --config=sgx-sim that leads to SGX_SIM=1 value. But going back to the Asylo's small and trustworthy goal, we still need the Intel's SGX SDK, that includes many of the system header files right? Is that ok or is there a plan to change that? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#62 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFL4HEQK6YP7FXGWDECX63SVJNRTANCNFSM4UZ3CYWQ> .

[asmprogrammer5]

I guess we need to differentiate between what is part of the enclave runtime and what is built for the untrusted part. I'm looking at a few headers in linux_sgx/common/inc/internal

Not as much as a concern, but I wanted to ensure that my code is inline with what Asylo and the SGX SDK was designed for and not changing the security context.

[deeglaze]

I recommend reading our runtime documentation since there are some syscalls that will compile and link but fail due to unsupported flags for instance.

…

On Thu, Dec 17, 2020 at 13:31 asmprogrammer5 ***@***.***> wrote: I guess we need to differentiate between what is part of the enclave runtime and what is built for the untrusted part. I'm looking at a few headers in linux_sgx/common/inc/internal Not as much as a concern, but I wanted to ensure that my code is inline with what Asylo and the SGX SDK was designed for and not changing the security context. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#62 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFL4HCZ7CM64UAJWKS44B3SVJ2ETANCNFSM4UZ3CYWQ> .