From: Matt Mackall <mpm@selenic.com>
To: Adam Heath <doogie@debian.org>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
Bernard Normier <bernard@zeroc.com>,
linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>
Subject: Re: Concurrent access to /dev/urandom
Date: Fri, 10 Dec 2004 17:10:15 -0800 [thread overview]
Message-ID: <20041211011014.GX8876@waste.org> (raw)
In-Reply-To: <Pine.LNX.4.58.0412101821330.2173@gradall.private.brainfood.com>
On Fri, Dec 10, 2004 at 06:22:37PM -0600, Adam Heath wrote:
> On Fri, 10 Dec 2004, Matt Mackall wrote:
>
> > On Fri, Dec 10, 2004 at 04:28:15PM -0500, Theodore Ts'o wrote:
> > > On Fri, Dec 10, 2004 at 10:28:04AM -0800, Matt Mackall wrote:
> > > >
> > > > Fair enough. s/__add/mix/, please.
> > > >
> > >
> > > Why? Fundamentally, it's all about adding entropy to the pool. I
> > > don't have an strong objection to calling it __mix_entropy_words, but
> > > if we're going to change it, we should change the non-__ variant for
> > > consistency's sake, and I'd much rather do that in a separate patch if
> > > we're going to do it all. I don't see the point of the rename,
> > > though.
> >
> > I suppose I don't really care. The __add is no longer just add, and
> > mix was the word that came to mind. But it doesn't really describe it
> > well either.
> >
> > > Still, I'd feel better if we did initialize more data via
> > > init_std_data(), and then cranked the LFSR some number of times so
> > > that we don't have to worry about analyzing the case where a good
> > > portion of the pool might contain consecutive zero values. But yeah,
> > > we can save that for another patch, as it's not absolutely essential.
> > >
> > > Are we converging here?
> >
> > I'm gonna call this last iteration done. Repasted below for akpm's
> > benefit. Urgency: medium-ish.
>
> Actually, I think this is a security issue. Since any plain old program can
> read from /dev/urandom at any time, an attacker could attempt to read from
> that device at the same moment some other program is doing so, and thereby
> gain some knowledge as to the other program's state.
It is indeed a security issue. Some interesting non-tin-foil remote
attacks may even be possible, but they're still at the handwaving
stage. It should be fixed and soon, but I'm also aware that 2.6.10 is
imminent.
Unfortunately, the 2.6 development methodology is not well suited to
timely security fixes, unless we get serious about this 2.6.x.y
strategy.
--
Mathematics is the supreme nostalgia of our time.
next prev parent reply other threads:[~2004-12-11 1:11 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-27 20:45 Concurrent access to /dev/urandom Bernard Normier
2004-11-27 20:56 ` Jan Engelhardt
2004-11-27 21:15 ` Bernard Normier
2004-11-27 21:22 ` Jan Engelhardt
2004-11-28 20:58 ` Bernard Normier
2004-12-07 23:41 ` Bernard Normier
2004-12-08 1:28 ` Theodore Ts'o
2004-12-08 1:56 ` Bernard Normier
2004-12-08 19:21 ` Theodore Ts'o
2004-12-08 20:15 ` Bernard Normier
2004-12-08 21:56 ` Matt Mackall
2004-12-09 1:57 ` Theodore Ts'o
2004-12-09 2:46 ` andyliu
2004-12-09 4:55 ` Matt Mackall
2004-12-09 2:58 ` Matt Mackall
2004-12-09 21:29 ` Matt Mackall
2004-12-10 4:47 ` Matt Mackall
2004-12-10 16:35 ` Theodore Ts'o
2004-12-10 18:28 ` Matt Mackall
2004-12-10 21:28 ` Theodore Ts'o
2004-12-10 22:23 ` Matt Mackall
2004-12-11 0:22 ` Adam Heath
2004-12-11 1:10 ` Matt Mackall [this message]
2004-12-11 17:33 ` Theodore Ts'o
2004-12-11 19:58 ` Adam Heath
2004-12-11 20:40 ` Matt Mackall
2004-12-12 16:19 ` Pavel Machek
2004-12-11 0:19 ` Adam Heath
2004-12-09 3:10 ` David Lang
2004-12-09 4:52 ` Matt Mackall
2004-12-09 6:36 ` Theodore Ts'o
2004-11-29 22:47 ` Jon Masters
2004-11-29 23:14 ` Bernard Normier
2004-11-29 23:43 ` Sven-Haegar Koch
2004-11-30 2:31 ` David Schwartz
2004-11-30 4:14 ` Kyle Moffett
2004-11-30 8:23 ` Jan Engelhardt
2004-11-30 18:50 ` David Schwartz
2004-11-29 23:42 ` David Wagner
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=20041211011014.GX8876@waste.org \
--to=mpm@selenic.com \
--cc=akpm@osdl.org \
--cc=bernard@zeroc.com \
--cc=doogie@debian.org \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox