[PATCH] mkswap: generate UUID
Rob Landley
rob at landley.net
Thu Jun 18 22:24:04 UTC 2009
On Thursday 18 June 2009 14:56:53 Colin Watson wrote:
> On Thu, Jun 18, 2009 at 09:34:56PM +0200, Denys Vlasenko wrote:
> > On Thursday 18 June 2009 17:47, Colin Watson wrote:
> > > Many modern Linux installers use UUIDs rather than device names to
> > > identify devices. This works better if mkswap sets a UUID.
> > >
> > > Signed-off-by: Colin Watson <cjwatson at ubuntu.com>
> >
> > CC e2fsprogs/old_e2fsprogs/uuid/gen_uuid.o
> > cc1: warnings being treated as errors
> > e2fsprogs/old_e2fsprogs/uuid/gen_uuid.c: In function 'get_node_id':
> > e2fsprogs/old_e2fsprogs/uuid/gen_uuid.c:125: error: unused parameter
> > 'node_id' make[1]: *** [e2fsprogs/old_e2fsprogs/uuid/gen_uuid.o] Error 1
> > make: *** [e2fsprogs/old_e2fsprogs/uuid] Error 2
> >
> > With it fixed:
>
> Thanks for catching that; didn't happen here with defconfig.
>
> > One *kilobyte* to generate 16 byte random number?
> >
> > I propose this instead:
>
> Is this an identical algorithm to that used in libuuid? It doesn't look
> like it, and I'm not happy with increasing the probability that UUIDs
> might turn out not to be universally unique. If you apply it this way
> I'll certainly have to patch it out in the version I distribute ...
The probability that a 128 bit random number will not be unique is 2^128. I
_guarantee_ you have no conception of how _big_ that is or you wouldn't be
worrying about it.
For discussion of whether or not the output of a supernova produces enough
total energy if you captured every last photon of it to cycle a theoretically
perfectly efficient computer through all the combinations of a a 2^128 bit key
(for purposes of discussion, such a computer uses the transition state of a
single electron from least excited state of the innermost orbital of a
hydrogen atom to the next least excited state to check one combination), see
Bruce Schneier's "Applied Cryptography" (second edition) pages 157-158
("Thermodynamic Limitations").
Your concerns about the uniqueness of 2 different properly random 128 bit
numbers matching show that you have _no_ understanding of scale. The planet
you're standing on is way more likely to be hit by a comet that puts the
cockroaches in charge. If you set every computer on the planet in a loop
trying to reproduce it and then wait for it to happen _once_, there'd be more
than a 99% probability that the sun would run out of fuel first.
(You can argue that /dev/urandom isn't _truly_ random, so maybe there's only a
95% chance the the sun would run out of fuel first, but I really don't care.)
> Also, IMO it's pretty strange to have one piece of UUID generation code
> built into busybox's mkswap and another built into busybox's e2fsck,
> mke2fs, and tune2fs.
Busybox hasn't got an e2fsck anymore. It was removed. There's residue there
because we vaguely plan to write a new one. (Now that I'm back, it'll
probably wind up being my job...)
Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
More information about the busybox
mailing list