On 2020-03-16 14:57, Nathaniel McCallum wrote: > On Mon, Mar 16, 2020 at 9:32 AM Jethro Beekman <jethro@xxxxxxxxxxxx> wrote: >> >> On 2020-03-15 18:53, Nathaniel McCallum wrote: >>> On Sat, Mar 14, 2020 at 9:25 PM Jarkko Sakkinen >>> <jarkko.sakkinen@xxxxxxxxxxxxxxx> wrote: >>>> >>>> On Wed, Mar 11, 2020 at 01:30:07PM -0400, Nathaniel McCallum wrote: >>>>> Currently, the selftest has a wrapper around >>>>> __vdso_sgx_enter_enclave() which preserves all x86-64 ABI callee-saved >>>>> registers (CSRs), though it uses none of them. Then it calls this >>>>> function which uses %rbx but preserves none of the CSRs. Then it jumps >>>>> into an enclave which zeroes all these registers before returning. >>>>> Thus: >>>>> >>>>> 1. wrapper saves all CSRs >>>>> 2. wrapper repositions stack arguments >>>>> 3. __vdso_sgx_enter_enclave() modifies, but does not save %rbx >>>>> 4. selftest zeros all CSRs >>>>> 5. wrapper loads all CSRs >>>>> >>>>> I'd like to propose instead that the enclave be responsible for saving >>>>> and restoring CSRs. So instead of the above we have: >>>>> 1. __vdso_sgx_enter_enclave() saves %rbx >>>>> 2. enclave saves CSRs >>>>> 3. enclave loads CSRs >>>>> 4. __vdso_sgx_enter_enclave() loads %rbx >>>>> >>>>> I know that lots of other stuff happens during enclave transitions, >>>>> but at the very least we could reduce the number of instructions >>>>> through this critical path. >>>> >>>> What Jethro said and also that it is a good general principle to cut >>>> down the semantics of any vdso as minimal as possible. >>>> >>>> I.e. even if saving RBX would make somehow sense it *can* be left >>>> out without loss in terms of what can be done with the vDSO. >>> >>> Please read the rest of the thread. Sean and I have hammered out some >>> sensible and effective changes. >> >> I'm not sure they're sensible? By departing from the ENCLU calling convention, both the VDSO >> and the wrapper become more complicated. > > For the vDSO, only marginally. I'm counting +4,-2 instructions in my > suggestions. For the wrapper, things become significantly simpler. > >> The wrapper because now it needs to implement all >> kinds of logic for different behavior depending on whether the VDSO is or isn't available. > > When isn't the vDSO available? When you're not on Linux. Or when you're on an old kernel. -- Jethro Beekman | Fortanix
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
