From: "Theodore Ts'o" <tytso@mit.edu>
To: Akinobu Mita <akinobu.mita@gmail.com>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
ying.huang@intel.com, chris.mason@fusionio.com,
linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 2/9] uuid: use random32_get_bytes()
Date: Mon, 29 Oct 2012 16:52:00 -0400 [thread overview]
Message-ID: <20121029205200.GD7098@thunk.org> (raw)
In-Reply-To: <1351408746-8623-2-git-send-email-akinobu.mita@gmail.com>
On Sun, Oct 28, 2012 at 04:18:59PM +0900, Akinobu Mita wrote:
> Use random32_get_bytes() to generate 16 bytes of pseudo-random bytes.
>
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Since your patch is going to allow users to set the random seed, it
means that what had previously been a bad security bug has just become
a grievous security bug. If you are going to be generating UUID's
they _must_ use a truly random random generator, since the whole point
of uuid's is that they be unique. If someone can trivially set the
random seed of a prng, and thus cause the uuid generator to generate,
well, non-unique UUID's, the results can range anywhere from
confusion, to file system corruption and data loss.
Fortunately, there is only one user of lib/uuid.c, and that's the
btrfs file system.
Chris and the Btrfs folks --- my recommendation would be to ditch the
use of uuid_be_gen, "git rm lib/uuid.c" with extreme prejudice, and
use generate_random_uuid() which was coded over a decade ago in
drivers/char/random.c. Not only does this properly use the kernel
random number generator, but it also creates a UUID with the correct
format. (It's not enough to set the UUID version to 4; you also need
to set the UUID variant to be DCE if you want to be properly compliant
with RFC 4122 --- see section 4.1.1.)
The btrfs file system doesn't generate uuid's in any critical fast
paths as near as I can determine, so it should be perfectly safe to
use uuid_generate() --- I also would drop the whole distinction
between little-endian and big-endian uuid's, BTW. RFC 4122 is quite
explicit about how uuid's should be encoded, and it's in internet byte
order. This is what OSF/DCE uses, and it's what the rest of the world
(Microsoft, SAP AG, Apple, GNOME, KDE) uses as well.
Regards,
- Ted
next prev parent reply other threads:[~2012-10-29 20:52 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 [this message]
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 ` [PATCH 1/9] random32: introduce random32_get_bytes() and prandom32_get_bytes() Theodore Ts'o
2012-10-29 20:39 ` 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=20121029205200.GD7098@thunk.org \
--to=tytso@mit.edu \
--cc=akinobu.mita@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=chris.mason@fusionio.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ying.huang@intel.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.