linux-kernel - Re: [PATCH v39 21/24] 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]

Message-ID: <20201007031402.GA143690@linux.intel.com>
Date:   Wed, 7 Oct 2020 06:14:02 +0300
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     Sean Christopherson <sean.j.christopherson@...el.com>
Cc:     Jethro Beekman <jethro@...tanix.com>, x86@...nel.org,
        linux-sgx@...r.kernel.org, linux-kernel@...r.kernel.org,
        Andy Lutomirski <luto@...capital.net>,
        Cedric Xing <cedric.xing@...el.com>, akpm@...ux-foundation.org,
        andriy.shevchenko@...ux.intel.com, asapek@...gle.com, bp@...en8.de,
        chenalexchen@...gle.com, conradparker@...gle.com,
        cyhanish@...gle.com, dave.hansen@...el.com, haitao.huang@...el.com,
        kai.huang@...el.com, kai.svahn@...el.com, kmoy@...gle.com,
        ludloff@...gle.com, luto@...nel.org, nhorman@...hat.com,
        npmccallum@...hat.com, puiterwijk@...hat.com, rientjes@...gle.com,
        tglx@...utronix.de, yaozhangx@...gle.com, mikko.ylinen@...el.com
Subject: Re: [PATCH v39 21/24] x86/vdso: Implement a vDSO for Intel SGX
 enclave call

On Tue, Oct 06, 2020 at 06:17:38PM -0700, Sean Christopherson wrote:
> On Wed, Oct 07, 2020 at 03:22:36AM +0300, Jarkko Sakkinen wrote:
> > On Tue, Oct 06, 2020 at 04:21:29PM -0700, Sean Christopherson wrote:
> > > On Tue, Oct 06, 2020 at 08:28:19PM +0300, Jarkko Sakkinen wrote:
> > > > On Tue, Oct 06, 2020 at 08:15:32AM -0700, Sean Christopherson wrote:
> > > > > On Tue, Oct 06, 2020 at 10:30:16AM +0200, Jethro Beekman wrote:
> > > > > > On 2020-10-06 04:57, Sean Christopherson wrote:
> > > > > > > On Sat, Oct 03, 2020 at 07:50:56AM +0300, Jarkko Sakkinen wrote:
> > > > > > >> +struct sgx_enclave_run {
> > > > > > >> +  __u64 tcs;
> > > > > > >> +  __u64 user_handler;
> > > > > > >> +  __u64 user_data;
> > > > > > >> +  __u32 leaf;
> > > > > > >
> > > > > > > I am still very strongly opposed to omitting exit_reason.  It is not at all
> > > > > > > difficult to imagine scenarios where 'leaf' alone is insufficient for the
> > > > > > > caller or its handler to deduce why the CPU exited the enclave.  E.g. see
> > > > > > > Jethro's request for intercepting interrupts.
> > > > > >
> > > > > > Not entirely sure what this has to do with my request, I just expect to see
> > > > > > leaf=ERESUME in this case, I think? E.g. as you would see in EAX when calling
> > > > > > ENCLU.
> > > > > 
> > > > > But how would you differentiate from the case that an exception occured in
> > > > > the enclave?  That will also transfer control with leaf=ERESUME.  If there
> > > > > was a prior exception and userspace didn't zero out the struct, there would
> > > > > be "valid" data in the exception fields.
> > > > > 
> > > > > An exit_reason also would allow retrofitting the exception fields into a
> > > > > union, i.e. the fields are valid if and only if exit_reason is exception.
> > > > 
> > > > Let's purge this a bit. Please remark where my logic goes wrong. I'm
> > > > just explaining how I've deduced the whole thing.
> > > > 
> > > > The information was encoded in v38 version of the vDSO was exactly this:
> > > > 
> > > > - On normal EEXIT, it got the value 0.
> > > > - Otherwise, it got the value 1.
> > > > 
> > > > The leaf, then embdded to struct sgx_exception but essentially the same
> > > > field got the value from EAX, and the value that EAX had was only
> > > > written on exception path.
> > > > 
> > > > Thus, I deduced that if you write $EEXIT to leaf on synchrous exit you
> > > > get the same information content, nothing gets overwritten. I.e. you
> > > > can make same conclusions as you would with those two struct fields.
> > > 
> > > And then a third flavor comes along, e.g. Jethro's request interrupt case,
> > > and exit_reason can also return '2'.  How do you handle that with only the
> > > leaf?
> > 
> > I'm listening. How was that handled before? I saw only '0' and '1'.  Can
> > you bring some context on that? I did read the emails that were swapped
> > when the run structure was added but I'm not sure what is the exact
> > differentiator. Maybe I'm missing something.
> 
> https://patchwork.kernel.org/patch/11719889/

Thank you.

There's aboslutely nothing that is blocking adding such support for such
AEP handling in the current implementation. SGX_SYNCHRONOUS_EXIT is just
another name for EEXIT. Even if that was in place, you'd need to
separate normal and interrupt. Tristate is useless here. As far as I'm
concerned, no bottlenecks have been created.

/Jarkko