STATUS

Current Todo:
* Make a simple trampoline to set up a trusted stack and allow access to user
  argments - DONE
* Have the trampoline set up the trusted stack using the syscall calling
  convention. syscall already includes a stack switch and a way of getting 
  arguments from the host. We want mechanisms like copyin/copyout anyway, too.
  - DONE
* Make it possible to load PIC-compiled enclaves. This is needed 
  to do any kind of real remote attestation, but it's hard because of
  linker relocations.  - DONE
* Create a simple launch enclave that signs init tokens where the inittoken
  is passed in as argument 1.  - DONE
* Create a second enclave that does local attestation correctly with another
  enclave in the same user program - DONE
* Fix trampoline to call exception code, user exception code to eenter excepting
  enclave and then resume after it exits - PARTIALLY DONE
  * Software trampoline should check for recursing into the TCS and call 
    enclave exception code instead so we can't be corrupted that way - DONE
  + Longer-term the user-side AEP code may want to be able to recurse into the 
    enclave so it can handle exceptions. This will also require fixing
    register handling and the user and enclave side exception handling code - DEFERRED
* Use copyin, copyout, copyenc, and copyuser calls that check where the destination - DONE
  of the copy is.
  * Create checking code for in/out of enclave
  * Create copy routines
  * Switch existing enclaves over to use new copy routines
* Get more of SSL/TLS running in enclave space - PARTIALLY DONE
  * Polar SSL AES CMAC for launch token generation - DONE
  * Look into switching to libcrypto from boringssl - NO, boring ssl looks a bit of a mess 
  * Look into using s2n for TLS - Not going to do this for now since PolarSSL is working
  * RSA for quoting enclave signing - DONE (using PolarSSL)
* Switch to having one enclave per executable and having them run at a defined address to 
  deal with dynamic loading issues - DONE
* Switch to using stock mbedtls install - DONE
* Get GDB debugging working - DONE
* Get an actual quoting enclave running - DONE
* Create call in with two shared buffers and command structure for it - IN PROGRESS
  * Get basic enclave gate abstraction set - DONE
  * Get a buffer for output from enclaves that can support the equivalent of 
    printf - DONE
  * Add REPORT_REQ/REPORT_RESP egate events calls for bootstraping, where
    the user code proxies for the report - DONE
  * Add QUOTE_REQ/QUOTE_RESP egate events for enclaves to request quotes
    from user code
  * Finish debugging basic communication channel details, including making some more 
    test cases that test wrap-around and channel reset - DONE
--------------- DONE THROUGH HERE ---------------
+ Bootstrap code - IN PROGRESS
  * Parse options on startup
  * Create and save launch tokens
  * Switch to running enclave in its own thread - REJECTED as not doable in current qemu
  * Implement RDRAND in qemu so we can get an ephemeral key - DONE
  + Switch sgx-tool to use launch enclave to create launch tokens - DEFERRED
  - Fix RDRAND feature checking/setting in qemu 
  - Switch Makefile to have a bootstrap target and an all target
+ Miscellaneous suntime support/fixes - IN PROGRESS
  * Change the starting heap size to something decent
  - Get a real bootmem allocator in place 
- Socket/TLS support
  * Add a useful entropy source in enclaves (probably implement RDRAND instruction in
    qemu using /dev/urandom). Can't generate ephemeral keys reasonably without this!
  * Create a socket shim/proxy out of the enclave using sendto/recvfrom commands over the 
    shared buffer channel - DONE
  - Test/debug SSL/TLS communication primitives from enclaves 
- Test cases
  * Finish a simple test case that illustrates the remote attestation process 
    described in the intel paper
  - Create a simple test case that can talk to an openssl client
  - Create a simple test case illustrating the use of the various types of 
    keys
- Documentation
  - Document the Intel provisinging/sealing keys and how they're actually meant to be
    used usefully.
  - More general writeup ofthe challenges in programming here.
--------------- LONGER-TERM AFTER HERE ---------------
- Fix CSSA setup to actually set it to proper values and still sign correctly 
  in the emulator. Once this is done, we can turn on the exception handler 
  check in sgx-entry.S
- Switch tools, emulator, and libsgx to use SHA256 instead of SHA1 
- Fix SSA protections to guard enclave stack against overflow
- Add support for multiple TCSes
- Define an actualy sgx_exit that pulls the return address from the base of
  the stack to go to the right place, but for now still does sgx_exit(0) 
  given the emulator's strange behavior
- Add EAUG support for the heap
- Reintegrate many changes into GT tree, potentially as a separate runtime?
- Define a proper FSM for the enclave/proxy interface that generates the 
  exchange information, and can be proved safe.
- Create bootstrap code that includes the rest of the enclave code as a binary blob and
  dynamically loads it at runtime a la kernel loadable modules. Will break debugging support.
--------------- SPECULATIVE IDEAS AFTER HERE -----------
- Intel says they don't care about sidechannel attacks, but to place reasonable limits
  on the lifetime of secrets, we need to have some sense of how fast those sidechannel
  attacks can actually happen. With the OS able to transparently interrupt and resume the 
  enclave easily (e.g. using page table protections), there's a lot of information to gather.
  Is it reasonable top assume that hte code itself is hidden, and how much protection does
  this actually offer from sidechannel attacks?
- Making RPC and marshalling systems to automate the construction of libraries between the
  enclave and user that are also provably safe seems like a good idea (e.g. to automatically
  generate a lot of the boilerplate of the UNIX stubs). There has to have been something 
  done here already. How to safely optimize these transfers in a way that leverages shared
  memory is also interesting; some level of hashing/signing is probably necessary. Right now,
  there's a lot of copying going on, and it would be cool if you could avoid that.

***

Longer-term issues:
   - No multi-threading in qemu user-level guests (grrr)
   * How much actual sense of time will we have or need in the enclave?
     On real hardware, it's not clear we'll actually get rdtsc, which 
     leaves us only relative time as the host lets us run or whatever we 
     can glean from secure and trusted communication with the outside
     world. What's this mean to the enclave programmer?

****

Information on the original GT simulator:
   * The original GATech SGX user code does not define a seperate stack
     and relies on the EENTER setting the stack to a fixed location near 
     the enclave SSA. The hardware doesn't actually do that, so it's not 
     architecturally correct. 
   * The GATech SGX user doesn't define a proper calling convention between the 
     untrusted and trusted code on enclave entry. They rely on a 
     trampoline back to the user on entry to move arguments through their 
     send/recv trampoline mechanism.
   * The GATech user code doesn't have a way of running multiple enclaves -
     they hard load one defined by fixed linker sections, and assume it is 
     already signed by a launch key through an external mechanism. 
   * The Gatech code doesn't have any actual system call/BIOS suppport. They 
     don't do a ring check on ENCLS, and have the user code call 
     ECREATE/EADD/EINIT instead of having the kernel do this. It is done 
     through a (somewhat hackish sys_create_enclave() call they have in a 
     library.) 
   * The GATech trampoline uses a single stack per TCS, so an AEX/enter
     (which untrusted code could arrange) could potentially stomp on
     other stack data. It also places the SSA at a location that
     makes it hard to find the right location of the stack and will
     break with multiple TCSes.
   * THe GATech simulator changed EEXIT behavior to do an AEX save on
     EEXIT(ptr != 0), which can be resumed later. This makes EEXIT 
     directly a coroutine call, instead of doing this through a 
     trampoline and a separate resume TCS entry or something similar.
     YOu have to use EEXIT(null) and rely on the simulator eexit EIP
     saving to approximate standard EEXIT behavior. (Otherwise, EENTER
     will eventually fail when you run out of SSA entries.)

Launch Enclave Design - DONE
* User-space
  * load and set the intel key.
  * Initialize the launch enclave 
  * Create the inittoken, call the launch enclave with the inittoken
    as the address to get it signed
  * Save the inittoken
- Enclave space
  * Argument 1, the inittoken. 
  * Do a bunch of consistency checks on the inittoken 
  * Call EGETKEY to get the launch key
  * Compute the launch token MAC.
  * Save the signature in the initkey
  * return