Forcing a more random uuid

Forcing a more random uuid

[Niccolo Rigacci]

My previous post was answered very quickly and with an optimal solution, 
but unfortunately I have a new question...

I'm writing a script to clone a disk with several md devices.

The raid1 volumes are created on the blank disk within a very quick loop, I 
think this is the reason why I get /dev/md5, /dev/md6, /dev/md7 
and /dev/md8 all with the same UUID!

Is there a way to force a more random UUID, or do I have to provide an 
--uid option on the command line?

-- 
Niccolo Rigacci
http://www.texnet.it/

Re: Forcing a more random uuid (random seed bug)

[Niccolo Rigacci]

> I get /dev/md5, /dev/md6, /dev/md7
> and /dev/md8 all with the same UUID!

It seems that there is a bug in mdadm: when generating the UUID for a 
volume, the random() function is called, but the random sequence is never 
initialized.

The result is that every volume created with mdadm has an uuid of:
6b8b4567:327b23c6:643c9869:66334873

See also Debian bug 292784 at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=292784

I fixed the problem adding the following patch to mdadm.c, but please bear 
in mind that I'm totally unaware of mdadm code and quite naive in C 
programming:

$ diff -u mdadm.c.orig mdadm.c
--- mdadm.c.orig        2004-11-02 06:11:06.000000000 +0100
+++ mdadm.c     2005-02-02 14:27:55.000000000 +0100
@@ -86,6 +86,15 @@
        ident.super_minor= UnSet;
        ident.devices=0;

+        int my_fd;
+        unsigned int my_seed;
+        if ((my_fd = open("/dev/random", O_RDONLY)) != -1) {
+            if (read(my_fd, &my_seed, sizeof(my_seed)) == sizeof(my_seed)) 
{
+                srandom(my_seed);
+            }
+            close(my_fd);
+        }
+
        while ((option_index = -1) ,
               (opt=getopt_long(argc, argv,
                                short_options, long_options,




-- 
Niccolo Rigacci
http://www.texnet.it/

Re: Forcing a more random uuid (random seed bug)

[linux]

+        if ((my_fd = open("/dev/random", O_RDONLY)) != -1) {

Please use /dev/urandom for such applications.  /dev/random is the
highest-quality generator, but will block if entropy isn't available.
/dev/urandom provides the best available, immediately, which is what
this application wants.

Also, this will only produce 2^32 possible UUIDs, since that's the
size of the seed.  Meaning that after you've generated 2^16 of them,
the chances are excellent that they're not UU any more.

You might just want to get all 128 (minus epsilon) bits from /dev/urandom
directly.

Re: Forcing a more random uuid (random seed bug)

[H. Peter Anvin]

Followup to:  <200502021433.42108.niccolo@texnet.it>
By author:    Niccolo Rigacci <niccolo@texnet.it>
In newsgroup: linux.dev.raid
>
> > I get /dev/md5, /dev/md6, /dev/md7
> > and /dev/md8 all with the same UUID!
> 
> It seems that there is a bug in mdadm: when generating the UUID for a 
> volume, the random() function is called, but the random sequence is never 
> initialized.
> 
> The result is that every volume created with mdadm has an uuid of:
> 6b8b4567:327b23c6:643c9869:66334873
> 
> See also Debian bug 292784 at
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=292784
> 
> I fixed the problem adding the following patch to mdadm.c, but please bear 
> in mind that I'm totally unaware of mdadm code and quite naive in C 
> programming:
> 

Please don't use (s)random at all, except as a possible fallback to
/dev/(u)random.

	-hpa

Re: Forcing a more random uuid (random seed bug)

[H. Peter Anvin]

Followup to:  <20050208140538.12557.qmail@science.horizon.com>
By author:    linux@horizon.com
In newsgroup: linux.dev.raid
>
> +        if ((my_fd = open("/dev/random", O_RDONLY)) != -1) {
> 
> Please use /dev/urandom for such applications.  /dev/random is the
> highest-quality generator, but will block if entropy isn't available.
> /dev/urandom provides the best available, immediately, which is what
> this application wants.

Not 100% clear; the best would be to make it configurable.

Either way you must not use read() in the way described.  Short reads
happen, even with /dev/urandom.
 
> Also, this will only produce 2^32 possible UUIDs, since that's the
> size of the seed.  Meaning that after you've generated 2^16 of them,
> the chances are excellent that they're not UU any more.
> 
> You might just want to get all 128 (minus epsilon) bits from /dev/urandom
> directly.

You *do* want to get all bits from /dev/urandom directly.

	-hpa