All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Artem Bityutskiy <dedekind1@gmail.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
	akpm@linux-foundation.org, David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH 1/9] random32: introduce random32_get_bytes() and prandom32_get_bytes()
Date: Mon, 29 Oct 2012 16:39:37 -0400	[thread overview]
Message-ID: <20121029203937.GC7098@thunk.org> (raw)
In-Reply-To: <1351408746-8623-1-git-send-email-akinobu.mita@gmail.com>

On Sun, Oct 28, 2012 at 04:18:58PM +0900, Akinobu Mita wrote:
>  /**
> + *	prandom32_get_bytes - get the requested number of pseudo-random bytes
> + *	@state: pointer to state structure holding seeded state.
> + *	@buf: where to copy the pseudo-random bytes to
> + *	@bytes: the requested number of bytes
> + *
> + *	This is used for pseudo-randomness with no outside seeding.
> + *	For more random results, use random32_get_bytes().
> + */
> +
> +/**
> + *	random32_get_bytes - get the requested number of pseudo-random bytes
> + *	@buf: where to copy the pseudo-random bytes to
> + *	@bytes: the requested number of bytes
> + */

This naming scheme is going to be very confusing.  If the function is
going to return a pseudo-random number, it *must* have a "prandom"
suffix.  Otherwise some kernel developer, somewhere, will get confused
between get_random_bytes() and random32_get_bytes(), and the result
may be a very embarassing security exposure.

How about prandom32_get_bytes_state() and prandom32_get_bytes() instead?

						- Ted

WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Ts'o" <tytso@mit.edu>
To: Akinobu Mita <akinobu.mita@gmail.com>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	Artem Bityutskiy <dedekind1@gmail.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	David Woodhouse <dwmw2@infradead.org>,
	linux-mtd@lists.infradead.org
Subject: Re: [PATCH 1/9] random32: introduce random32_get_bytes() and prandom32_get_bytes()
Date: Mon, 29 Oct 2012 16:39:37 -0400	[thread overview]
Message-ID: <20121029203937.GC7098@thunk.org> (raw)
In-Reply-To: <1351408746-8623-1-git-send-email-akinobu.mita@gmail.com>

On Sun, Oct 28, 2012 at 04:18:58PM +0900, Akinobu Mita wrote:
>  /**
> + *	prandom32_get_bytes - get the requested number of pseudo-random bytes
> + *	@state: pointer to state structure holding seeded state.
> + *	@buf: where to copy the pseudo-random bytes to
> + *	@bytes: the requested number of bytes
> + *
> + *	This is used for pseudo-randomness with no outside seeding.
> + *	For more random results, use random32_get_bytes().
> + */
> +
> +/**
> + *	random32_get_bytes - get the requested number of pseudo-random bytes
> + *	@buf: where to copy the pseudo-random bytes to
> + *	@bytes: the requested number of bytes
> + */

This naming scheme is going to be very confusing.  If the function is
going to return a pseudo-random number, it *must* have a "prandom"
suffix.  Otherwise some kernel developer, somewhere, will get confused
between get_random_bytes() and random32_get_bytes(), and the result
may be a very embarassing security exposure.

How about prandom32_get_bytes_state() and prandom32_get_bytes() instead?

						- Ted

  parent reply	other threads:[~2012-10-29 20:59 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-28  7:18 [PATCH 1/9] random32: introduce random32_get_bytes() and prandom32_get_bytes() Akinobu Mita
2012-10-28  7:18 ` Akinobu Mita
2012-10-28  7:18 ` [PATCH 2/9] uuid: use random32_get_bytes() Akinobu Mita
2012-10-29 20:52   ` Theodore Ts'o
2012-10-30  1:49     ` Huang Ying
2012-10-30  4:48       ` Theodore Ts'o
2012-10-31  1:35         ` Huang Ying
2012-10-31  2:38           ` Theodore Ts'o
2012-10-31  3:06             ` Huang Ying
2012-10-28  7:19 ` [PATCH 3/9] mtd: mtd_nandecctest: use random32_get_bytes instead of get_random_bytes() Akinobu Mita
2012-10-28  7:19   ` Akinobu Mita
2012-10-28  7:19 ` [PATCH 4/9] mtd: nandsim: use random32_get_bytes Akinobu Mita
2012-10-28  7:19   ` Akinobu Mita
2012-10-28  7:19 ` [PATCH 5/9] ubifs: " Akinobu Mita
2012-10-28  7:19   ` Akinobu Mita
2012-10-28  7:19 ` [PATCH 6/9] mtd: mtd_oobtest: convert to use prandom32_get_bytes() Akinobu Mita
2012-10-28  7:19   ` Akinobu Mita
2012-10-28  7:19 ` [PATCH 7/9] mtd: mtd_pagetest: " Akinobu Mita
2012-10-28  7:19   ` Akinobu Mita
2012-10-28  7:19 ` [PATCH 8/9] mtd: mtd_speedtest: use random32_get_bytes Akinobu Mita
2012-10-28  7:19   ` Akinobu Mita
2012-10-28  7:19 ` [PATCH 9/9] mtd: mtd_subpagetest: convert to use prandom32_get_bytes() Akinobu Mita
2012-10-28  7:19   ` Akinobu Mita
2012-10-29 20:39 ` Theodore Ts'o [this message]
2012-10-29 20:39   ` [PATCH 1/9] random32: introduce random32_get_bytes() and prandom32_get_bytes() Theodore Ts'o
2012-10-30 11:01   ` Akinobu Mita
2012-10-30 11:12     ` Akinobu Mita
2012-10-31  3:29       ` Theodore Ts'o
2012-10-31  3:29         ` Theodore Ts'o
2012-10-31 11:53         ` Akinobu Mita

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=20121029203937.GC7098@thunk.org \
    --to=tytso@mit.edu \
    --cc=adrian.hunter@intel.com \
    --cc=akinobu.mita@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    /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.