The current Linux kernel currently contains the generate_random_uuid() function, which creates - based on RFC 4122 - truly random UUIDs and provides them to userspace through /proc/sys/kernel/random/boot_id  and /proc/sys/kernel/random/uuid.
The attached patch additionally adds the "Time-based UUID" variant of RFC 4122 to the Linux Kernel.

With this patch applied, userspace applications may easily get real unique time-based UUIDs through /proc/sys/kernel/random/uuid_time.
The attached implementation uses getnstimeofday() to get more fine-grained granularity than what would be possible with gettimeofday() in userspace.

As such it's in principle possible to provide a lot more UUIDs (if needed) per time than in userspace.

Additionally a mutex takes care of the proper locking against a mistaken double creation of UUIDs for simultanious running processes.
It would be nice if the patch could be applied. It should apply cleanly against git-head.

Helge
Signed-off-by: Helge Deller <deller@gmx.de>
 drivers/char/random.c  |  162 +++++++++++++++++++++++++++++++++++++++++++------

 include/linux/sysctl.h |    5 -

 2 files changed, 148 insertions(+), 19 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c

index af274e5..c84a385 100644

--- a/drivers/char/random.c

+++ b/drivers/char/random.c

@@ -239,6 +239,7 @@

 #include <linux/spinlock.h>

 #include <linux/percpu.h>

 #include <linux/cryptohash.h>

+#include <linux/netdevice.h>
 #include <asm/processor.h>

 #include <asm/uaccess.h>

@@ -1157,6 +1158,8 @@ void generate_random_uuid(unsigned char uuid_out[16])

 	uuid_out[6] = (uuid_out[6] & 0x0F) | 0x40;

 	/* Set the UUID variant to DCE */

 	uuid_out[8] = (uuid_out[8] & 0x3F) | 0x80;

+	/* Set multicast bit to avoid conflicts with NIC MAC addresses */

+	uuid_out[10] |= 0x80;

 }
 EXPORT_SYMBOL(generate_random_uuid);

@@ -1174,12 +1177,135 @@ EXPORT_SYMBOL(generate_random_uuid);

 static int min_read_thresh = 8, min_write_...
[ message continues ]

Erm, was it *intended* that you also changed the behavior of generate_random_uuid()?

Hello Valdis,
Thanks that you ask!

I really should have mentioned it in my initial posting.
Yes, this change was intentional, as it in fact fixes a possible bug in the original code.
So up to now it was just pure ("random") luck if this bit was set or not.
While at it...

My patch addressed another small non-critical glitch in the current implementation as well.

The first read() returns the newly generated random uuid.

The second read() just returns zero, but the current implementation then already created a new uuid which wasn't used at all.

Although this is not critical, it was nevertheless leaking unnecessarily entropy from the pool.

For the case of the new time-based UUIDs it was worse. It unnecessary incremented the clock_seq number.

This issue is addressed by this part of my patch (esp.: "*ppos > 0"):

@@ -1191,13 +1317,13 @@ static int proc_do_uuid(ctl_table *table, int write, struct file *filp,

        ctl_table fake_table;

        unsigned char buf[64], tmp_uuid[16], *uuid;
-       uuid = table->data;

-       if (!uuid) {

-               uuid = tmp_uuid;

-               uuid[8] = 0;

+       /* random/time UUIDs need to be read completely at once */

+       if (table->ctl_name != RANDOM_BOOT_ID && *ppos > 0) {

+               *lenp = 0;

+               return 0;

        }
Helge

-

Sounds like a valid bugfix then - but it should probably be sent upstream

separately, with it's own changelog (what I quoted above should be fine)...
Remember - one patch, one logical change, so your patch should be split up

(among other things, that way the bugfix can proceed even if the new-function

part gets hung up in review).....
Other than splitting it up, I have no further comments on either part.. Enjoy...