From: "Theodore Ts'o" <tytso@mit.edu>
To: Kees Cook <keescook@chromium.org>
Cc: 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 14:23:16 -0400 [thread overview]
Message-ID: <20120707182316.GA3681@thunk.org> (raw)
In-Reply-To: <20120707171122.GD28340@outflux.net>
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)?
Regards,
- Ted
next prev parent reply other threads:[~2012-07-07 18:23 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 [this message]
2012-07-07 23:20 ` Kees Cook
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=20120707182316.GA3681@thunk.org \
--to=tytso@mit.edu \
--cc=ewust@umich.edu \
--cc=jhalderm@umich.edu \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nadiah@cs.ucsd.edu \
--cc=stable@vger.kernel.org \
--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 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.