From: Jonathan Nieder <jrnieder@gmail.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Linux Kernel Developers List <linux-kernel@vger.kernel.org>,
ewust@umich.edu, zakir@umich.edu, nadiah@cs.ucsd.edu,
jhalderm@umich.edu,
Linus Torvalds <torvalds@linux-foundation.org>,
stable@vger.kernel.org
Subject: Re: [PATCH 05/12] usb: feed USB device information to the /dev/random driver
Date: Fri, 6 Jul 2012 20:08:22 -0500 [thread overview]
Message-ID: <20120707010822.GA3097@burratino> (raw)
In-Reply-To: <20120706232659.GA28978@thunk.org>
Hi,
Theodore Ts'o wrote:
> On Fri, Jul 06, 2012 at 06:02:18PM -0500, Jonathan Nieder wrote:
>> Why cc: stable@? Does this fix a build error, oops, hang, data
>> corruption, real security issue, or other critical "oh, that's not
>> good" bug?
>
> All of the /dev/random patches in this patch series that were marked
> for the stable backports are to address a security issue. See:
> https://factorable.net/
Thanks for explaining. If there's occasion for a reroll (I'm guessing
there won't be) then it would be nice to mention this in the commit
messages.
[...]
> While these patches are designed to do as much as we can without
> assuming any fixes in userspace, and the weak kea vulnerabilities are
> much more obviously detectable in embedded devices with close to zero
> available entropy, ideally there are improvements that can and should
> be done in upstream userspace packages as well as in the packaging and
> installation scripts for more general-purpose server and workstation
> distributions.
>
> For example, ssh key generation should happen as late as possible;
> ideally, some time *after* the networking has been brought up.
[...]
> The same is true for the generation of remote
> administration keys for ntpd and bind.
Very much agreed. These patches look like an improvement but on
diskless systems without a hardware RNG it still seems possible for
someone with knowledge of the hardware configuration to predict the
generator state.
Except that patch 2 improves matters a lot.
Thanks for your work and kindness,
Jonathan
next prev parent reply other threads:[~2012-07-07 1:08 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 [this message]
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
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=20120707010822.GA3097@burratino \
--to=jrnieder@gmail.com \
--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=torvalds@linux-foundation.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 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.