All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jorge Ramirez-Ortiz, Foundries" <jorge@foundries.io>
To: "Jorge Ramirez-Ortiz, Foundries" <jorge@foundries.io>
Cc: Sumit Garg <sumit.garg@linaro.org>,
	Matt Mackall <mpm@selenic.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Jens Wiklander <jens.wiklander@linaro.org>,
	Arnd Bergmann <arnd@arndb.de>,
	ricardo@foundries.io, Michael Scott <mike@foundries.io>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	op-tee@lists.trustedfirmware.org,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
	<linux-crypto@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCHv2 2/2] hwrng: optee: fix wait use case
Date: Tue, 28 Jul 2020 12:05:55 +0200	[thread overview]
Message-ID: <20200728100555.GA2074@trex> (raw)
In-Reply-To: <20200724142305.GA24164@trex>

On 24/07/20, Jorge Ramirez-Ortiz, Foundries wrote:
> On 24/07/20, Sumit Garg wrote:
> > On Thu, 23 Jul 2020 at 14:16, Jorge Ramirez-Ortiz <jorge@foundries.io> wrote:
> > >
> > > The current code waits for data to be available before attempting a
> > > second read. However the second read would not be executed as the
> > > while loop exits.
> > >
> > > This fix does not wait if all data has been read and reads a second
> > > time if only partial data was retrieved on the first read.
> > >
> > > This fix also does not attempt to read if not data is requested.
> > 
> > I am not sure how this is possible, can you elaborate?
> 
> currently, if the user sets max 0, get_optee_rng_data will regardless
> issuese a call to the secure world requesting 0 bytes from the RNG
> 
> with this patch, this request is avoided.
> 
> > 
> > >
> > > Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
> > > ---
> > >  v2: tidy up the while loop to avoid reading when no data is requested
> > >
> > >  drivers/char/hw_random/optee-rng.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/char/hw_random/optee-rng.c b/drivers/char/hw_random/optee-rng.c
> > > index 5bc4700c4dae..a99d82949981 100644
> > > --- a/drivers/char/hw_random/optee-rng.c
> > > +++ b/drivers/char/hw_random/optee-rng.c
> > > @@ -122,14 +122,14 @@ static int optee_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
> > >         if (max > MAX_ENTROPY_REQ_SZ)
> > >                 max = MAX_ENTROPY_REQ_SZ;
> > >
> > > -       while (read == 0) {
> > > +       while (read < max) {
> > >                 rng_size = get_optee_rng_data(pvt_data, data, (max - read));
> > >
> > >                 data += rng_size;
> > >                 read += rng_size;
> > >
> > >                 if (wait && pvt_data->data_rate) {
> > > -                       if (timeout-- == 0)
> > > +                       if ((timeout-- == 0) || (read == max))
> > 
> > If read == max, would there be any sleep?
> 
> no but I see no reason why there should be a wait since we already have
> all the data that we need; the msleep is only required when we need to
> wait for the RNG to generate entropy for the number of bytes we are
> requesting. if we are requesting 0 bytes, the entropy is already
> available. at leat this is what makes sense to me.
> 
>

any further comments?

> > 
> > -Sumit
> > 
> > >                                 return read;
> > >                         msleep((1000 * (max - read)) / pvt_data->data_rate);
> > >                 } else {
> > > --
> > > 2.17.1
> > >

  reply	other threads:[~2020-07-28 10:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-23  8:46 [PATCHv2 1/2] hwrng: optee: handle unlimited data rates Jorge Ramirez-Ortiz
2020-07-23  8:46 ` [PATCHv2 2/2] hwrng: optee: fix wait use case Jorge Ramirez-Ortiz
2020-07-24 13:22   ` Sumit Garg
2020-07-24 14:23     ` Jorge Ramirez-Ortiz, Foundries
2020-07-28 10:05       ` Jorge Ramirez-Ortiz, Foundries [this message]
2020-08-05 13:49       ` Sumit Garg
2020-08-05 20:38         ` Jorge Ramirez-Ortiz, Foundries
2020-08-06  6:11           ` Sumit Garg
2020-08-06  6:30             ` Jorge Ramirez-Ortiz, Foundries
2020-08-06  6:57               ` Sumit Garg
2020-08-06  8:14                 ` Jorge Ramirez-Ortiz, Foundries
2020-08-06  9:15                   ` Sumit Garg
2020-08-05 13:34   ` Jorge Ramirez-Ortiz, Foundries
2020-07-24 13:24 ` [PATCHv2 1/2] hwrng: optee: handle unlimited data rates Sumit Garg

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=20200728100555.GA2074@trex \
    --to=jorge@foundries.io \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=jens.wiklander@linaro.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike@foundries.io \
    --cc=mpm@selenic.com \
    --cc=op-tee@lists.trustedfirmware.org \
    --cc=ricardo@foundries.io \
    --cc=sumit.garg@linaro.org \
    /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.