Re: Forcing a more random uuid (random seed bug)
Followup to: <[EMAIL PROTECTED]>
By author:[EMAIL PROTECTED]
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
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Forcing a more random uuid (random seed bug)
Followup to: <[EMAIL PROTECTED]> By author:Niccolo Rigacci <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Forcing a more random uuid (random seed bug)
+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.
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Forcing a more random uuid (random seed bug)
> 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.orig2004-11-02 06:11:06.0 +0100
+++ mdadm.c 2005-02-02 14:27:55.0 +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/
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
