That seems like overkill to me. I'm just asking for one additional mov instruction. :) On Tue, Aug 18, 2020 at 11:06 AM Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx> wrote: > > On Tue, Aug 18, 2020 at 05:52:41PM +0300, Jarkko Sakkinen wrote: > > On Mon, Aug 10, 2020 at 03:23:17PM -0700, Sean Christopherson wrote: > > > > This can be done implicitly by wrapping the struct > > > > sgx_enclave_exception in another structure and then using techniques > > > > like container_of() to find another field. However, this is made more > > > > difficult by the fact that the sgx_enclave_exit_handler_t is not > > > > really using the x86_64 sysv calling convention. Therefore, the > > > > sgx_enclave_exit_handler_t MUST be written in assembly. > > > > > > What bits of the x86-64 ABI require writing the handler in assembly? There > > > are certainly restrictions on what the handler can do without needing an > > > assembly trampoline, but I was under the impression that vanilla C code is > > > compatible with the exit handler patch. Is Rust more picky about calling > > > convention? > > > > > > Side topic, the documentation for vdso_sgx_enter_enclave_t is wrong, it > > > states the EFLAGS.DF is not cleared before invoking the handler, but that's > > > a lie. > > > > If handler requires the use of setjmp/longjmp API for sudden exits, that > > is considered bad even with C++, as it is not compatible with stack > > unwinding. The handler has a lot of constraints for its environment, and > > is somewhat unappealing to use. > > > > That's why I started today thinking a possibility of using a bpf program > > as a middle-man. BPF programs can be used to execute code by the kernel > > in behalf of user in a domain defined sandbox. The execution context is > > just a buffer passed in R1 to the BPF interpreter. It can be defined by > > application. > > Something like > > 1. An exception is triggered. > 2. Kernel executes an eBPF program behalf of the caller, if one was > given. > 3. vDSO calls a fixed exit handler that based on the outcome calls > ERESUME/EENTER. > > Possibly an ioctl could be used to attach an eBPF program to an > enclave and vDSO would only get a context struct. > > /Jarkko >
