linux-kernel - Re: [PATCH v28 21/22] x86/vdso: Implement a vDSO for Intel SGX enclave call

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 16 Mar 2020 09:57:28 -0400
From:   Nathaniel McCallum <npmccallum@...hat.com>
To:     Jethro Beekman <jethro@...tanix.com>
Cc:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        linux-kernel@...r.kernel.org, x86@...nel.org,
        linux-sgx@...r.kernel.org, akpm@...ux-foundation.org,
        dave.hansen@...el.com,
        "Christopherson, Sean J" <sean.j.christopherson@...el.com>,
        Neil Horman <nhorman@...hat.com>,
        "Huang, Haitao" <haitao.huang@...el.com>,
        andriy.shevchenko@...ux.intel.com, tglx@...utronix.de,
        "Svahn, Kai" <kai.svahn@...el.com>, bp@...en8.de,
        Josh Triplett <josh@...htriplett.org>, luto@...nel.org,
        kai.huang@...el.com, David Rientjes <rientjes@...gle.com>,
        cedric.xing@...el.com, Patrick Uiterwijk <puiterwijk@...hat.com>,
        Andy Lutomirski <luto@...capital.net>,
        Connor Kuehl <ckuehl@...hat.com>,
        Harald Hoyer <harald@...hat.com>,
        Lily Sturmann <lsturman@...hat.com>
Subject: Re: [PATCH v28 21/22] x86/vdso: Implement a vDSO for Intel SGX
 enclave call

On Mon, Mar 16, 2020 at 9:32 AM Jethro Beekman <jethro@...tanix.com> wrote:
>
> On 2020-03-15 18:53, Nathaniel McCallum wrote:
> > On Sat, Mar 14, 2020 at 9:25 PM Jarkko Sakkinen
> > <jarkko.sakkinen@...ux.intel.com> 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? Once the patches are merged it will
always be available. Then we also get to live with this interface
forever. I'd rather have a good, usable interface for the long term.

> I agree with Jarkko that everything should be kept small and simple. Calling a couple extra instructions is going to have a negligible effect compared to the actual time EENTER/EEXIT take.

We all agree on small and simple. Nothing I've proposed fails either
of those criteria.

> Can someone remind me why we're not passing TCS in RBX but on the stack?

If you do that, the vDSO will never be callable from C. And, as you've
stated above, calling a couple extra instructions is going to have a
negligible effect.