Use of --config=sgx-sim or enc-sim still supported on Asylo 0.6?
Opened this issue · 7 comments
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
Thanks, couple of follow ups:
-
Why do we still have the --config option for simulator in the tree? Since it's replaced by @com_google_asylo_backend_provider//:backend
-
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?
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.
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?
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.