Intel SGX development
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Nathaniel McCallum <npmccallum@redhat.com>,
	Cedric Xing <cedric.xing@intel.com>,
	Jethro Beekman <jethro@fortanix.com>,
	Andy Lutomirski <luto@amacapital.net>,
	linux-sgx@vger.kernel.org
Subject: Re: [RFC PATCH 2/4] x86/vdso: x86/sgx: Rework __vdso_sgx_enter_enclave() API
Date: Thu, 27 Aug 2020 16:35:24 +0300	[thread overview]
Message-ID: <20200827133524.GC4674@linux.intel.com> (raw)
In-Reply-To: <20200826202029.GD21459@sjchrist-ice>

On Wed, Aug 26, 2020 at 01:20:29PM -0700, Sean Christopherson wrote:
> Andy,
> 
> Any thoughts on using a struct versus a plethora of params?  If you don't
> have a strong opinion, I'd like to push for the struct option as it fixes
> the -EFAULT weirdness, satisfies Nathaniel's request, and gives some
> flexibility for the future.  The code impact, both to the vDSO and to the
> caller, is largely a lateral move, i.e. it's different but in the end
> doesn't require any more or less work.

If we ended up ever considering eBPF idea that I throwed a while ago in
the air, most likely the same struct could be use as the context for the
BPF program and larger portion of the existing vDSO code would remain
intact.

I'm not trying gonzo market BPF.

I'm just pointing out that a struct is a great vessel to travel between
kernel and user space (e.g. a BPF program would be executed by the
kernel by using the vDSO provided context struct).

/Jarkko

  parent reply	other threads:[~2020-08-27 13:36 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-18  4:24 [RFC PATCH 0/4] x86/vdso: x86/sgx: Rework SGX vDSO API Sean Christopherson
2020-08-18  4:24 ` [RFC PATCH 1/4] x86/vdso: x86/sgx: Explicitly force 8-byte CMP for detecting user handler Sean Christopherson
2020-08-18 16:46   ` Jarkko Sakkinen
2020-08-20 11:13   ` Jethro Beekman
2020-08-18  4:24 ` [RFC PATCH 2/4] x86/vdso: x86/sgx: Rework __vdso_sgx_enter_enclave() API Sean Christopherson
2020-08-18 16:57   ` Jarkko Sakkinen
2020-08-20 11:23   ` Jethro Beekman
2020-08-24 13:36   ` Jethro Beekman
2020-08-24 19:49     ` Jarkko Sakkinen
2020-09-04 10:25       ` Sean Christopherson
2020-09-04 13:36         ` Jarkko Sakkinen
2020-09-04 16:01           ` Sean Christopherson
2020-08-24 23:54     ` Sean Christopherson
2020-08-25  7:36       ` Jethro Beekman
2020-08-25  7:38         ` Sean Christopherson
2020-08-25  7:41           ` Jethro Beekman
2020-08-26 20:16             ` Sean Christopherson
2020-08-26 19:27   ` Xing, Cedric
2020-08-26 20:15     ` Sean Christopherson
2020-08-26 23:26       ` Xing, Cedric
2020-09-04  9:52         ` Sean Christopherson
2020-08-27  8:58       ` Jethro Beekman
2020-08-26 20:20   ` Sean Christopherson
2020-08-26 20:55     ` Andy Lutomirski
2020-08-27 13:35     ` Jarkko Sakkinen [this message]
2020-08-18  4:24 ` [RFC PATCH 3/4] x86/vdso: x86/sgx: Introduce dedicated SGX exit reasons for vDSO Sean Christopherson
2020-08-18 16:58   ` Jarkko Sakkinen
2020-08-20 11:13   ` Jethro Beekman
2020-08-18  4:24 ` [RFC PATCH 4/4] x86/vdso: x86/sgx: Allow the user to exit the vDSO loop on interrupts Sean Christopherson
2020-08-18 17:00   ` Jarkko Sakkinen
2020-08-18 17:15   ` Andy Lutomirski
2020-08-18 17:31     ` Sean Christopherson
2020-08-18 19:05       ` Andy Lutomirski
2020-08-19 14:21     ` Jethro Beekman
2020-08-19 15:02       ` Andy Lutomirski
2020-08-20 11:20         ` Jethro Beekman
2020-08-20 17:44           ` Andy Lutomirski
2020-08-20 17:53             ` Jethro Beekman
2020-08-22 21:55               ` Andy Lutomirski
2020-08-24 13:36                 ` Jethro Beekman
2020-08-26 18:32                   ` Sean Christopherson
2020-08-26 19:09                     ` Xing, Cedric
2020-08-27  8:57                     ` Jethro Beekman
2020-08-20 11:13   ` Jethro Beekman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200827133524.GC4674@linux.intel.com \
    --to=jarkko.sakkinen@linux.intel.com \
    --cc=cedric.xing@intel.com \
    --cc=jethro@fortanix.com \
    --cc=linux-sgx@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=npmccallum@redhat.com \
    --cc=sean.j.christopherson@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox