From: "Tobin C. Harding" <me@tobin.cc>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Theodore Ts'o <tytso@mit.edu>,
Linus Torvalds <torvalds@linux-foundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
Kees Cook <keescook@chromium.org>,
Anna-Maria Gleixner <anna-maria@linutronix.de>,
Andrew Morton <akpm@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Arnd Bergmann <arnd@arndb.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/3] random: Return nbytes filled from hw RNG
Date: Wed, 16 May 2018 07:17:06 +1000 [thread overview]
Message-ID: <20180515211706.GG10152@eros> (raw)
In-Reply-To: <20180515093705.03850c5a@gandalf.local.home>
On Tue, May 15, 2018 at 09:37:05AM -0400, Steven Rostedt wrote:
> On Tue, 15 May 2018 13:06:25 +1000
> "Tobin C. Harding" <me@tobin.cc> wrote:
>
> > Currently the function get_random_bytes_arch() has return value 'void'.
> > If the hw RNG fails we currently fall back to using get_random_bytes().
> > This defeats the purpose of requesting random material from the hw RNG
> > in the first place.
> >
> > There are currently no intree users of get_random_bytes_arch().
> >
> > Only get random bytes from the hw RNG, make function return the number
> > of bytes retrieved from the hw RNG.
> >
> > Signed-off-by: Tobin C. Harding <me@tobin.cc>
> > Acked-by: Theodore Ts'o <tytso@mit.edu>
> > Signed-off-by: Tobin C. Harding <me@tobin.cc>
> > ---
> > drivers/char/random.c | 16 +++++++++-------
> > include/linux/random.h | 2 +-
> > 2 files changed, 10 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/char/random.c b/drivers/char/random.c
> > index 031d18b31e0f..4b0ec597e783 100644
> > --- a/drivers/char/random.c
> > +++ b/drivers/char/random.c
> > @@ -1725,26 +1725,28 @@ EXPORT_SYMBOL(del_random_ready_callback);
> > * key known by the NSA). So it's useful if we need the speed, but
> > * only if we're willing to trust the hardware manufacturer not to
> > * have put in a back door.
> > + *
> > + * Return number of bytes filled in.
> > */
> > -void get_random_bytes_arch(void *buf, int nbytes)
> > +int __must_check get_random_bytes_arch(void *buf, int nbytes)
> > {
> > char *p = buf;
> > + int left = nbytes;
>
> Just a nit, but I know some kernel devs prefer "upside-down-xmas-tree"
> style of declarations. Which would make the above:
>
> int left = nbytes;
> char *p = buf;
Super specific coding style and rigorous code cleanliness is a big part
of why I love kernel dev. Thanks for pointing this one out.
While we are on these code lines, whats the typical kernel variable name
for a loop counter that is going to be counted down? 'left',
'remaining', 'to_go', 'still'???
> >
> > - trace_get_random_bytes_arch(nbytes, _RET_IP_);
> > - while (nbytes) {
> > + trace_get_random_bytes_arch(left, _RET_IP_);
>
> Nothing to do with this patch series, but I wonder if we should move
> the trace event below, and record how much was done.
I don't fully understand trace events, I just left this line in tact
and hoped for the best :(
/me adds 'trace events' to list of things to learn more about
> > + while (left) {
> > unsigned long v;
> > - int chunk = min(nbytes, (int)sizeof(unsigned long));
> > + int chunk = min_t(int, left, (int)sizeof(unsigned long));
> >
> > if (!arch_get_random_long(&v))
> > break;
> >
> > memcpy(p, &v, chunk);
> > p += chunk;
> > - nbytes -= chunk;
> > + left -= chunk;
> > }
> >
> > - if (nbytes)
> > - get_random_bytes(p, nbytes);
> > + return nbytes - left;
> > }
> > EXPORT_SYMBOL(get_random_bytes_arch);
> >
> > diff --git a/include/linux/random.h b/include/linux/random.h
> > index 2ddf13b4281e..f1c9bc5cd231 100644
> > --- a/include/linux/random.h
> > +++ b/include/linux/random.h
> > @@ -38,7 +38,7 @@ extern void get_random_bytes(void *buf, int nbytes);
> > extern int wait_for_random_bytes(void);
> > extern int add_random_ready_callback(struct random_ready_callback *rdy);
> > extern void del_random_ready_callback(struct random_ready_callback *rdy);
> > -extern void get_random_bytes_arch(void *buf, int nbytes);
> > +extern int __must_check get_random_bytes_arch(void *buf, int nbytes);
> >
> > #ifndef MODULE
> > extern const struct file_operations random_fops, urandom_fops;
>
> Other than that...
>
> Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Thanks for the review Steve, will spin again.
Tobin.
next prev parent reply other threads:[~2018-05-15 21:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-15 3:06 [PATCH v4 0/3] enable early printing of hashed pointers Tobin C. Harding
2018-05-15 3:06 ` [PATCH v4 1/3] random: Fix whitespace pre random-bytes work Tobin C. Harding
2018-05-15 3:06 ` [PATCH v4 2/3] random: Return nbytes filled from hw RNG Tobin C. Harding
2018-05-15 13:37 ` Steven Rostedt
2018-05-15 21:17 ` Tobin C. Harding [this message]
2018-05-15 21:35 ` Steven Rostedt
2018-05-15 22:26 ` Tobin C. Harding
2018-05-15 3:06 ` [PATCH v4 3/3] vsprintf: Use hw RNG for ptr_key Tobin C. Harding
2018-05-15 13:47 ` Steven Rostedt
2018-05-15 21:09 ` Tobin C. Harding
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=20180515211706.GG10152@eros \
--to=me@tobin.cc \
--cc=akpm@linux-foundation.org \
--cc=anna-maria@linutronix.de \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
/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.