lkml.org 
[lkml]   [2020]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v39 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
On Wed, Oct 07, 2020 at 08:08:32PM +0300, Jarkko Sakkinen wrote:
> On Wed, Oct 07, 2020 at 08:25:45AM -0700, Sean Christopherson wrote:
> > On Wed, Oct 07, 2020 at 10:39:23AM +0300, Jarkko Sakkinen wrote:
> > > On Tue, Oct 06, 2020 at 09:34:19PM -0700, Sean Christopherson wrote:
> > > > > Even if that was in place, you'd need to separate normal and interrupt.
> > > > > Tristate is useless here.
> > > >
> > > > Huh? You mean like adding SGX_INTERRUPT_EXIT and SGX_EXCEPTION_EXIT?
> > >
> > > OK, so I'll throw something.
> > >
> > > 1. "normal" is either exception from either EENTER or ERESUME,
> > > or just EEXIT.
> > > 2. "interrupt" is something where you want to tailor AEP path.
> >
> > Manipulating the behavior of the vDSO, as in #2, would be done via an input
> > flag. It may be related to the exit reason, e.g. the flag may also opt-in to
> > a new exit reason, but that has no bearing on whether or not a dedicated exit
> > reason is valuable.
>
> The fact is that AEP path is not actual right now.
>
> I'm not even interested to go further on discussing about feature that
> does not exist. Perhaps if/when it exist it turns out that we want a
> variable lets say 'exit_reason' to present something in that context.
>
> I'm neither against that or for it because it is all speculative.
>
> > > > I'm not arguing that any of the above is even remotely likely. I just don't
> > > > understand why we'd want an API that at best requires heuristics in userspace
> > > > to determine why the enclave stopped running, and at worst will saddle us with
> > > > an ugly mess in the future. All to save 4 bytes that no one cares about (they
> > > > literally cost nothing), and a single MOV in a flow that is hundreds, if not
> > > > thousands, of cycles.
> > >
> > > I don't care as much as saving bytes as defining API, which has zero
> > > ambiguous state variables.
> >
> > How is exit_reason ambiguous?
>
> I rather pick the word redundant:
>
> 1. 'leaf' exist anyway.
> 2. It can represent all the state we need right now.
> 3. It does not block anything.,
>
> I care deeply about wasting 4 bytes in a fixed size struct for
> absolutely nothing.

And I do care about what to pick for the struct size. My remarks on
that are lost somewhere in this thread. I absoutely do not have any
interest whether 'exit_reason' in some future situation is useful
or not.

/Jarkko

\
 
 \ /
  Last update: 2020-10-07 19:14    [W:0.122 / U:0.740 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site