From: Kees Cook <keescook@chromium.org>
To: "Theodore Ts'o" <tytso@mit.edu>,
Kees Cook <keescook@chromium.org>,
Linux Kernel Developers List <linux-kernel@vger.kernel.org>,
ewust@umich.edu, zakir@umich.edu, nadiah@cs.ucsd.edu,
jhalderm@umich.edu, stable@vger.kernel.org
Subject: Re: [PATCH] random: only use gathered bytes from arch_get_random_long
Date: Sat, 7 Jul 2012 16:20:40 -0700 [thread overview]
Message-ID: <20120707232040.GE28340@outflux.net> (raw)
In-Reply-To: <20120707182316.GA3681@thunk.org>
On Sat, Jul 07, 2012 at 02:23:16PM -0400, Theodore Ts'o wrote:
> On Sat, Jul 07, 2012 at 10:11:22AM -0700, Kees Cook wrote:
> > While very unlikely, it is possible for arch_get_random_long() to fail
> > in the middle of the loop in xfer_secondary_pool(), which would mean
> > that the loop could stop with only part of u.hwrand populated, leading
> > to mix_pool_bytes() injecting uninitialized or already injected bytes
> > instead of fresh bytes. This changes the mix_pool_bytes() call to only
> > inject the successfully gathered bytes.
>
> I don't believe there is a major problem with injecting uninitialized
> or even known bytes into the pool; worst case we're wastiing a tiny
> amount of CPU in this unlikely case (versus the CPU costs of doing the
> multiplication each time). Not that I think really matters one way or
> the other...
>
> Is there a reason why you're particularly concerned about what might
> happen in the case where arch_get_random_long() fails mid-loop (which
> can happen if RDRAND returns an error for whatever reason, granted)?
Not really, but it seems like poor form to try to mix in data that wasn't
actually what you were expecting. I don't exactly see a problem with what
you've already got, but it seems like it's better to not have the bug at
all.
-Kees
--
Kees Cook
Chrome OS Security
next prev parent reply other threads:[~2012-07-07 23:20 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-06 22:44 [PATCH 00/12] /dev/random fixups Theodore Ts'o
2012-07-06 22:44 ` [PATCH 01/12] random: fix up sparse warnings Theodore Ts'o
2012-07-06 22:44 ` [PATCH 02/12] random: make 'add_interrupt_randomness()' do something sane Theodore Ts'o
2012-07-08 2:01 ` Ben Hutchings
2012-07-06 22:44 ` [PATCH 03/12] random: use lockless techniques in the interrupt path Theodore Ts'o
2012-07-06 22:44 ` [PATCH 04/12] random: create add_device_randomness() interface Theodore Ts'o
2012-07-06 22:44 ` [PATCH 05/12] usb: feed USB device information to the /dev/random driver Theodore Ts'o
2012-07-06 23:02 ` Jonathan Nieder
2012-07-06 23:18 ` Greg KH
2012-07-06 23:26 ` Theodore Ts'o
2012-07-07 1:08 ` Jonathan Nieder
2012-07-06 22:44 ` [PATCH 06/12] net: feed /dev/random with the MAC address when registering a device Theodore Ts'o
2012-07-06 22:44 ` [PATCH 07/12] random: use the arch-specific rng in xfer_secondary_pool Theodore Ts'o
2012-07-07 17:11 ` [PATCH] random: only use gathered bytes from arch_get_random_long Kees Cook
2012-07-07 18:23 ` Theodore Ts'o
2012-07-07 23:20 ` Kees Cook [this message]
2012-07-08 1:06 ` [PATCH 07/12] random: use the arch-specific rng in xfer_secondary_pool Ben Hutchings
2012-07-08 1:41 ` Theodore Ts'o
2012-07-08 2:06 ` Ben Hutchings
2012-07-06 22:45 ` [PATCH 08/12] random: add new get_random_bytes_arch() function Theodore Ts'o
2012-07-06 22:45 ` [PATCH 09/12] random: add tracepoints for easier debugging and verification Theodore Ts'o
2012-07-06 22:45 ` [PATCH 10/12] MAINTAINERS: Theodore Ts'o is taking over the random driver Theodore Ts'o
2012-07-06 22:45 ` [PATCH 11/12] rtc: wm831x: Feed the write counter into device_add_randomness() Theodore Ts'o
2012-07-06 22:45 ` [PATCH 12/12] mfd: wm831x: Feed the device UUID " Theodore Ts'o
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=20120707232040.GE28340@outflux.net \
--to=keescook@chromium.org \
--cc=ewust@umich.edu \
--cc=jhalderm@umich.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=nadiah@cs.ucsd.edu \
--cc=stable@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=zakir@umich.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox