> On Sep 27, 2018, at 7:21 AM, Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx> wrote: > >> On Wed, Sep 26, 2018 at 03:37:45PM -0700, Andy Lutomirski wrote: >> Yeah. Maybe like this: > > xorl %eax,%eax > eenter_insn: >> ENCLU[whatever] >> eenter_landing_pad: >> ret >> >> And the kernel would use the existing vdso2c vdso-symbol-finding >> mechanism to do the fixup. >> >>> >>> How would a syscall work, though? I assume we can't just enter the >>> enclave from ring0. >> >> My understanding of how AEX works is a bit vague, but maybe a syscall >> could reuse the mechanism? The vDSO approach seems considerably >> simpler. >> >> We do need to make sure that a fault that happens on or after return >> from an AEX event does the right thing. But I'm still vague on how >> that works, sigh. >> >> --Andy > > Returning from AEX does not differ from any other memory access event so > AFAIK it should be handled right with the proposed solution already. > For convenience I think we could have a fixed trampoline for AEX e.g. > this how it is implemented in the open source LE that I did: > > sgx_get_token: > push %rbx > mov $0x02, %rax > mov %rsi, %rbx > mov %rdx, %rsi > mov $sgx_async_exit, %rcx > sgx_async_exit: > ENCLU > pop %rbx > ret > > BTW, if I converted the in-kernel LE as a standalone test program, would > that be useful for basic testing of the series? > > Definitely. Especially if you stick it in selftests/x86 and make it exit cleanly (error code 0) on unsupported hardware.