Current status
gcc hello.c -o hello runs the full driver, cc1, as, ld chain inside a real SGX enclave and produces a working x86_64 ELF, byte-size identical to the non-SGX build.- tcc compiles hello world under SGX both standalone and under the IMFS grate.
- Still open: gcc under the IMFS grate on SGX hangs during the load of cc1 in a forked cage.
Each blocker faced along the way is mentioned as a sub-issue.
Open blocker
gcc under the IMFS grate hangs on SGX
The one remaining gap in the current issue is the composed case: gcc + IMFS grate + SGX. The run reaches execve of cc1 which is a 248 MB precompiled module in a forked cage, and the module load (Module::deserialize) never returns. Threads stay runnable at full CPU; a 30-minute run showed no progress.
What we have ruled out with a minimal fork/exec harness run under the identical configuration (IMFS grate, SGX, same 248 MB cc1, same argv, real compile output produced):
- fork itself (all checkpoints fire, child memory is correct)
- module size and deserialize in a forked cage (the harness loads the same cc1 in under a minute)
- IMFS I/O and pre-fork fd state
The same steps that hang under the real gcc driver pass in the harness every time, so the trigger is something specific to the gcc driver process, and we have not yet identified it.
Leading suspicion is memory pressure on the 2 GiB EPC, but our measurements so far cannot see enclave-internal memory, so this is unconfirmed.
Next steps we see: read real EPC counters (needs root), or measure the guest's own heap use at fork time
Current status
gcc hello.c -o helloruns the full driver, cc1, as, ld chain inside a real SGX enclave and produces a working x86_64 ELF, byte-size identical to the non-SGX build.Each blocker faced along the way is mentioned as a sub-issue.
Open blocker
gcc under the IMFS grate hangs on SGX
The one remaining gap in the current issue is the composed case: gcc + IMFS grate + SGX. The run reaches
execveof cc1 which is a 248 MB precompiled module in a forked cage, and the module load (Module::deserialize) never returns. Threads stay runnable at full CPU; a 30-minute run showed no progress.What we have ruled out with a minimal fork/exec harness run under the identical configuration (IMFS grate, SGX, same 248 MB cc1, same argv, real compile output produced):
The same steps that hang under the real gcc driver pass in the harness every time, so the trigger is something specific to the gcc driver process, and we have not yet identified it.
Leading suspicion is memory pressure on the 2 GiB EPC, but our measurements so far cannot see enclave-internal memory, so this is unconfirmed.
Next steps we see: read real EPC counters (needs root), or measure the guest's own heap use at fork time