This is is a (not yet comprehensive) list of differences/limitations when applications are executed with SGX-LKL. This should be provided as part of the SGX-LKL documentation:

1. There is no support for fork() and multiple processes. Currently SGX-LKL provides a pure single process abstractions (although multiple LKL kernel thread can function in the role of separate processes). There is ongoing work to provide partial support for the clone system call.

2. Given the above limitation, there is no support for IPC-related system calls between multiple processes. IPC-related system calls should work if they are being used for thread synchronisation only (e.g. a pipe between two threads, so epoll() can allow one to wake another up).

3. SGX-LKL cannot execute binaries that issue syscall assembly instructions directly, instead of going through the libc syscall wrapper macro. For example, the Go runtime is currently unsupported because it invokes syscalls directly bypassing libc. As a solution, SGX-LKL could emulate trapped syscall instructions in software, similar to rdtsc and cpuid.

4. There are certain limitations in SGX-LKL's mmap() support:
   a. SGX-LKL cannot map the same page multiple times.
   b. For memory-mapped files, SGX-LKL does not support transparent write back (since the enclave mmap implementation is not integrated with the Linux page cache). The lack of write-back may be possible to fix if SGX-LKL tracks where MAP_SHARED mappings came from and writes them back on exit, but multiple MAP_SHARED mappings of the same file range will not work. We could also hook the msync system call to explicitly write back.
   c. The address space exposes to the application is limited by the size of the enclave, and does not constitute a full 64-bit address space. This should largely be transparent to applications but affects some applications that use VMM tricks, such as WebAssembly.

5. Due to the non-preemptive scheduling, no asynchronous signals can be delivered to a pure userspace compute loop.

6. Currently (with SGX1), calls to mprotect() are untrusted, so applications (e.g. the Java Virtual Machine) that rely on getting signals for access violations can potentially be attacked this way.

7. Certain systems calls and signals (e.g., SIGXCPU) that are related to scheduling are not supported by LKL. Currently the lthread and LKL schedulers are not integrated, thus the LKL scheduler is mostly unaware of the execution of userspace lthreads.