[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