> On Sep 27, 2018, at 7:21 AM, Jarkko Sakkinen
> <jarkko.sakki...@linux.intel.com> 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.
