All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Andreas Dilger <andreas.dilger@intel.com>,
	Peng Tao <tao.peng@emc.com>,
	devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org,
	Nikita Danilov <nikita@clusterfs.com>
Subject: lustre: why does cfs_get_random_bytes() exist?
Date: Thu, 3 Oct 2013 12:39:08 -0400	[thread overview]
Message-ID: <20131003163908.GD31721@thunk.org> (raw)

I've been auditing uses of get_random_bytes() since there are places
where get_random_bytes() is getting used where something weaker, such
as prandom_u32() is quite sufficient.  Basically, if kernel code just
needs a random number which does not have any cryptographic
requirements (such as in ext[234]. which gets the new block group used
for inode allocations using get_random_bytes), then prandom_u32()
should be used instead of get_random_bytes() to save CPU overhead and
to reduce the drain on the /dev/urandom's entropy pool.

Typically, the reason for this is either for historical reasons, since
prandom_u32() hadn't existed when the code was written, or because
historical code was cut and pasted into newer code.

When I came across staging/lustre/lustre/libcfs/prng.c, I saw
something which is **really** weird.  It defines a cfs_rand() which is
functionally identical to prandom_u32().  More puzzlingly, it also
defines cfs_get_random_bytes() which calls get_random_bytes() and then
xor's the result with cfs_rand().  That last step has no cryptographic
effect, so I'm really wondering who thought this as a good idea and/or
necessary.

What I think should happen is that staging/lustre/lustre/libcfs/prng.c
should be removed, and calls to cfs_rand() should get replaced
prandom_u32(), and cfs_get_random_bytes() should get replaced with
get_random_bytes().

Does this sound reasonable?

Cheers,

						- Ted

             reply	other threads:[~2013-10-03 16:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-03 16:39 Theodore Ts'o [this message]
2013-10-03 17:26 ` lustre: why does cfs_get_random_bytes() exist? Greg KH
2013-10-03 19:34   ` Theodore Ts'o
2013-10-03 23:06     ` Dilger, Andreas
2013-10-03 23:45       ` Theodore Ts'o
2013-10-05  6:10         ` Dilger, Andreas
2013-10-05 14:21           ` Theodore Ts'o
2013-10-05 15:51             ` Christoph Hellwig

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=20131003163908.GD31721@thunk.org \
    --to=tytso@mit.edu \
    --cc=andreas.dilger@intel.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nikita@clusterfs.com \
    --cc=tao.peng@emc.com \
    /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.