All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Tadeusz Struk <tadeusz.struk@intel.com>
Cc: jgg@ziepe.ca, linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] tpm: add support for partial reads
Date: Fri, 16 Nov 2018 03:33:41 +0200	[thread overview]
Message-ID: <20181116013341.GA26336@linux.intel.com> (raw)
In-Reply-To: <825f4c01-efb1-5034-ea90-9ea5ea8f5b45@intel.com>

On Thu, Nov 15, 2018 at 04:26:33PM -0800, Tadeusz Struk wrote:
> On 11/15/18 3:31 PM, Jarkko Sakkinen wrote:
> > You could drop these memset() calls and also one from
> > tpm_timeout_work(). The call could be done once in the beginning of
> > tpm_common_write() instead of having three different call sites.
> > 
> 
> Don't we want to clean the buffer as the response is read?
> When we will only memset it in write and if one would send
> just one command there will only be one response.
> The data will sit in the buffer until the next command.
> There will be a quite bit time window when the data can leak.

Point taken.

> > Naming becomes a mess and the comment for data_pending variable is
> > incorrect as it is also used for synchronous operation.
> > 
> > Maybe add a prepending commit to rename it as
> > 
> > 	/* Holds the resul of the tpm_transmit() last call. */
> > 	ssize_t transmit_result;
> 
> Agree, will do that.
> 
> > 
> > That is at least clear and obvious on what it contains.
> > 
> > The comment for partial_data is incorrect as the variable does not
> > contain any data.
> 
> Yes, I will change it.
> 
> > 
> > We could use declare:
> > 
> > 	/* Holds the count how much of the response is still unread. */
> > 	size_t response_pending;
> > 
> > Observe another remark from your commit: there is no reaso to ssize_t as
> > the type as the value should never be a negative number.
> 
> Yes, in fact now the priv->data_pending can also be only positive.
> I'll change it and send a new version soon.

Right you're correct. Then it should be simply called as response_size
(and be size_t) as it is then the most precise name for what it
contains.

> Thanks,
> -- 
> Tadeusz

/Jarkko

      reply	other threads:[~2018-11-16  1:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-15 20:42 [PATCH v3] tpm: add support for partial reads Tadeusz Struk
2018-11-15 23:31 ` Jarkko Sakkinen
2018-11-15 23:37   ` Jarkko Sakkinen
2018-11-16  0:26   ` Tadeusz Struk
2018-11-16  1:33     ` Jarkko Sakkinen [this message]

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=20181116013341.GA26336@linux.intel.com \
    --to=jarkko.sakkinen@linux.intel.com \
    --cc=jgg@ziepe.ca \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=tadeusz.struk@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.