From: Huang Ying <ying.huang@intel.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Akinobu Mita <akinobu.mita@gmail.com>,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
chris.mason@fusionio.com, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 2/9] uuid: use random32_get_bytes()
Date: Tue, 30 Oct 2012 09:49:58 +0800 [thread overview]
Message-ID: <1351561798.7817.352.camel@yhuang-dev> (raw)
In-Reply-To: <20121029205200.GD7098@thunk.org>
On Mon, 2012-10-29 at 16:52 -0400, Theodore Ts'o wrote:
> 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 uuid_le/be_gen() in lib/uuid.c has set UUID variants to be DCE,
that is done in __uuid_gen_common() with "b[8] = (b[8] & 0x3F) | 0x80".
To deal with random number generation issue, how about use
get_random_bytes() in __uuid_gen_common()?
> 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.
uuid_be complies RFC4122, it uses internet byte order. But EFI uses
little endian.
Best Regards,
Huang Ying
next prev parent reply other threads:[~2012-10-30 1:50 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 [this message]
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=1351561798.7817.352.camel@yhuang-dev \
--to=ying.huang@intel.com \
--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=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 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.