linux-sgx.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: linux-sgx@vger.kernel.org
Subject: Re: [PATCH for v24 v2 4/4] x86/sgx: add @count to &sgx_enclave_add_pages
Date: Fri, 8 Nov 2019 10:13:31 +0200	[thread overview]
Message-ID: <20191108081331.GB3370@linux.intel.com> (raw)
In-Reply-To: <20191106232030.GA13378@linux.intel.com>

On Thu, Nov 07, 2019 at 01:20:30AM +0200, Jarkko Sakkinen wrote:
> On Tue, Nov 05, 2019 at 02:52:23PM -0800, Sean Christopherson wrote:
> > On Tue, Nov 05, 2019 at 01:20:56PM +0200, Jarkko Sakkinen wrote:
> > > Add @count write the number of bytes added as there is not any good reason
> > > to overwrite input parameters.
> > 
> > I disagree, overwriting the params means userspace doesn't need to adjust
> > the values to restart the ioctl().  Ditto for printing out the failing
> > address if the ioctl() fails.
> 
> There is three redundant updates. At least only @length must be
> updated in order to remove this glitch.
> 
> As far as overwriting goes, it should be only done when there is
> requiring to do that.

What is obvious is that the current behaviour is wrong. You have
a *single value* to return and you encode the *same value* with
*three encodings*:

1. offset + count
2. length - count
3. src + count

And ironically none of the encodings give you the count of bytes
processed in unpacked form. It is something that must be readily
available as practically all common syscalls that can partially process
the input give that. There is a long history of that pattern and no
history at all with this weird pack of encodings.

/Jarkko

  reply	other threads:[~2019-11-08  8:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-05 11:20 [PATCH for v24 v2 1/4] x86/sgx: Destroy enclave if EADD fails Jarkko Sakkinen
2019-11-05 11:20 ` [PATCH for v24 v2 2/4] x86/sgx: Remove a subordinate clause Jarkko Sakkinen
2019-11-06 22:03   ` Jarkko Sakkinen
2019-11-05 11:20 ` [PATCH for v24 v2 3/4] x86/sgx: Detach sgx_encl_add_page() from struct sgx_enclave_add_pages Jarkko Sakkinen
2019-11-05 11:20 ` [PATCH for v24 v2 4/4] x86/sgx: add @count to &sgx_enclave_add_pages Jarkko Sakkinen
2019-11-05 22:52   ` Sean Christopherson
2019-11-06 23:20     ` Jarkko Sakkinen
2019-11-08  8:13       ` Jarkko Sakkinen [this message]
2019-11-05 22:58 ` [PATCH for v24 v2 1/4] x86/sgx: Destroy enclave if EADD fails Sean Christopherson
2019-11-06 23:26   ` Jarkko Sakkinen

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=20191108081331.GB3370@linux.intel.com \
    --to=jarkko.sakkinen@linux.intel.com \
    --cc=linux-sgx@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).