Current status + Roadmap #1
Description
Current status - Compiling compiler toolchain:
I spent some time attempting to compile GCC to run on lind-wasm.
Since gcc doesn’t currently support running wasm, I tried to work around this by setting the --host=x86_64-linux flag during the configure phase, specifying lind-glibc path, and manually linking to lind-glibc. However, the build system still assumed it was targeting a native x86_64 ELF environment and ran host-specific tests, which caused the build to fail. While it’s technically possible to patch config.sub and provide fake files like config.host to force the build through, that approach goes against our portability goal, so I dropped gcc for now.
Clang compiles C source code to IR code first and then lowers it to wasm binary. Compilers like gcc are not designed to emit LLVM-IR and might be much harder to compile to lind-wasm. For this reason, I’d prefer to start with LLVM-based compilers like Clang and Rustc. I also found some existing projects for both that maybe helpful:
Rustc:
rubrc
status: target executables only for x86_64-unknown-linux-musl and wasm
Clang:
binji
status: doesn’t work anymore because stuff in fs
YoWASP
status: only support compiling wasm binary as wasm-clang output
Current status - Enarx:
Enarx is able to run wasm module
Challenge 1: Enarx requires all files to be pre-opened before execution.
Potential solution: this could be addressed by integrating IMFS, since all required files can be loaded into memory ahead of time.
Challenge 2: Switch from standard wasmtime to lind-wasm
Potential solution: Enarx currently uses wasmtime’s standard public APIs (such as Store, Linker, Engine, etc.) to execute a single wasm module (cage). In contrast, lind-wasm introduces POSIX-like process support by enabling coordination across multiple wasm modules. However, the actual execution still goes through a single entry function that launches the main executable module. One possible approach is to expose this execution function in lind-wasm as a public API, so that Enarx can directly invoke it instead of relying on the standard wasmtime execution flow.
Challenge 3: Enarx can only statically loading external third-party libraries.
We need to copy all wasmtime dependencies to enclave.
Not a blocker: rawposix, 3i, and other dependencies are part of the same workspace as lind-wasm, so as long as standard Wasmtime builds, these components should integrate cleanly.
Challenge 4: Networking Restrictions:
Not a blocker: networking is not required and can be blocked via 3i.
Challenge 5: Get the final binaries out of enclave
stream out standard I/O etc. for small project
mmap out
maybe a hash when send to transparent log...?
CLI
Next steps:
Deadline: 8/26 USNIEX Security
Total weeks: 13 weeks
- Compiler compile —> change to use clang + rustc ~ 2 weeks 6/9
- 3i integration to lind-wasm codebase (PR review needed) debugging + run compiler ~ 1 week 6/16
- Hard to estimate what kind of error I would face when running compiler toolchain, and not sure if those bugs would be related to runtime.
- Migrate lind-wasm to enarx ~ 1 week 6/23
- Potential blocks would be running lind-wasm in sgx. Still validating how mmap, sbrk, etc. interact with SGX
- IMFS implementation (implementation shouldn’t effect efficiency a lot for imfs) + Run compiler toolchain ~ 3 weeks 7/14
- Hardest part is to run the toolchain with IMFS, needs time debugging.
- Performance benchmarking + paper writing ~ 6 weeks 8/26
- Would love to hear suggestions from @marcelamelara which types of benchmarks we should use for evaluation tomorrow