Re: [PATCH 1/9] random32: introduce random32_get_bytes() and prandom32_get_bytes()

From: Akinobu Mita
Date: Tue Oct 30 2012 - 07:12:30 EST


2012/10/30 Akinobu Mita <akinobu.mita@xxxxxxxxx>:
> 2012/10/30 Theodore Ts'o <tytso@xxxxxxx>:
>> 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?
>
> I agree with your suggestion. I'll rename them and try again.
>
> By the way, should we also rename the existing random32() and
> prandom32() in the future?
>
> Specifically, rename random32() to prandom32(), and prandom32() to
> prandom32_state(). As a result, it will cause a little confusion
> between old and new prandom32(). But the number of arguments will
> be changed from 3 to 2, so gcc can detect the misuse of prandom32().

Oops, I intended to say "the number of arguments of prandom32() will be
changed from 1 to 0". And I realized that the exisiting srandom32() also should
be renamed to sprandom32().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/