Build sgx_tstd as drop-in std replacement

[cschramm]

Motivation: There are two basic strategies to use teaclave with existing Rust crates:

• Opt into no_std (+ alloc). This restricts the usable crates to those with no_std support and patched ones that work without it if adapted accordingly and that is actually a huge restriction. Also, it just does not reflect the situation as sgx_tstd is a proper std, just not 100 % complete compared to std and using a different naming.
• Port all dependencies to explicit sgx_tstd support, mostly adding things like "use sgx_tstd as std;". This means manual work for everyting and especially a lot of maintenance hassle.

Strategy 3: Use sgx_tstd as a drop-in replacement for std. This turned out to work decently. With the current state you can build (note that I'm not saying "run" 😅) the current kitx main with just an extra rustc flag and one small patch (see below).

Steps taken:

• Rename the sgx_tstd lib to just std.
• Build a sysroot with it and its dependencies.
• Improve std-compatibility as far as necessary.

Building the sysroot is done by the build_sysroot.sh script, meant to be run in the sgx_tstd directory and taking the desired target path as an optional argument (../../sysroot otherwise). It leverages cargo's -Z build-std feature to build the core and alloc crates. panic_unwind could be added there as well but is currently included by adding the one from the sgx_panic_unwind directory as a dependency (I have no idea what the difference might be as there is no dependency on std anyway).

Enabled features for improved compatibility:

• thread and backtrace - they should be uncritical, thread is linked by a lot of crates, backtrace only marginally but at least anyhow expects it to be available in nightlies.
• net - is considered untrusted but will probably be inevitable. We will need to audit and monitor which dependencies use its API and what they do with it.
• untrusted_time and untrusted_fs - similar to net but we might not actually need their API. We will want to disable them in the long run, probably by patching dependencies or providing stub implementations of the affected API. I will gather a list of usages in current kitx dependencies to find a strategy for this.

Patches for improved compatibility:

• Re-export ::core::arch as arch
• Re-export some of the sync::Sgx* structures under their std names.
• Re-export thread::SgxThread as thread::Thread.
• Implement thread::Builder::stack_size - a pointless noop just for API compatibility.
• Implement stubs for process::{ChildStdin, ChildStdout, ChildStderr}. These will fail if they are actually called.
• Implement process::abort with the actual implementation from std.

Caveats:

• Obviously the provided std is incomplete. Most notably it does not have std::process (apart from the patches mentioned above).
• The sysroot does not have a proc_macro crate. kitx builds fine without it (however, do not try to e.g. cargo build -p proc-macro2).
• An explicit target is required when building, even if it's the default. Without a target, e.g. the syn crate's build.rs fails to build due to the missing std::process::Command. I do not get why this does not happen when providing a target, to be honest.
• At least the sgx-sdk nix package only has a static version of libsgx_tstdc and others in $SGX_SDK/lib, so building cdylibs will fail.

For the kitx workspace the last point means that you need to patch out crate-type cdylib from hyper's Cargo.toml (there is active work going on to remove it in general: hyperium/hyper#2685) but that is the only change necessary. It is also not possible to build the C and JNI binding crates for the same reason.

[cschramm]

Opening a draft PR for follow-ups and discussion.

Linked libraries and syscalls boil down to glibc linked from the libc crate and its syscall wrappers (plus other functions that use syscall (wrapper)s internally). The syscall wrappers referenced in the current libc_kitx.a:

bind
clock_gettime
close
connect
epoll_create1
epoll_ctl
epoll_wait
eventfd
fcntl
getpagesize
getpeername
getsockname
getsockopt
ioctl
listen
msync
pipe2
poll
read
recv
recvfrom
recvmsg
sched_getaffinity
send
sendmsg
sendto
setsockopt
shutdown
socket
socketpair
syscall

(The only usages of the indirect syscall seem to be for getrandom (see below).)

Code that uses them will obviously fail. To catch that we might want to use a libc crate or libc build that does not provide syscalls at all.

Syscallers via the libc crate:

• getrandom - indirect getrandom (there is https://github.com/mesalock-linux/getrandom-sgx)
• mio with "os-poll" - heavy fs (there is https://github.com/mesalock-linux/mio-sgx)
• ring - indirect getrandom (there is https://github.com/mesalock-linux/ring-sgx/)
• socket2 - heavy fs / net, used by hyper for TCP
• tokio - some stdio and process credentials, probably not relevant

(Side note: --target wasm32-unknown-unknown does not build any of them due to the wasm support in reqwest except getrandom which has wasm support as well)

We probably just want to leave untrusted_time enabled as we just need a time source and there is no trusted one. Also, it does not mean leaking data, just using untrusted input. Detected users:

• socket2 - timeout, not actually used
• chrono (there is https://github.com/mesalock-linux/chrono-sgx - uses the untrusted API)
• rustls (there is https://github.com/mesalock-linux/rustls - uses the untrusted API)

fs users via untrusted_fs:

• mio with "os-poll" - wakers and pipes (there is https://github.com/mesalock-linux/mio-sgx - base version did not have the fs references yet)
• ring with "udev_random_fallback" - reads /dev/urandom if the getrandom syscall fails (there is https://github.com/mesalock-linux/ring-sgx/ - does not have that feature in "default")
• rustls "logging" - well, logging (there is https://github.com/mesalock-linux/rustls - does not have that feature)
• zip - unpacks to fs - data leak ouch, we will need an in-memory replacement or use an SGX protected filesystem
• num_cpus - leaking in from dev-dependencies via tokio with "rt-multi-thread", not actually used