linux-kernel - Re: [PATCH] Time-based RFC 4122 UUID generator

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071120063120.GD17536@waste.org>
Date:	Tue, 20 Nov 2007 00:31:20 -0600
From:	Matt Mackall <mpm@...enic.com>
To:	Helge Deller <deller@....de>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Theodore Tso <tytso@....edu>
Subject: Re: [PATCH] Time-based RFC 4122 UUID generator

On Sun, Nov 18, 2007 at 10:40:34PM +0100, Helge Deller wrote:
> On Sunday 18 November 2007, Andrew Morton wrote:
> > On Sun, 18 Nov 2007 20:38:21 +0100 Helge Deller <deller@....de> wrote:
> > 
> > > Title: Add time-based RFC 4122 UUID generator
> > > 
> > > 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.
> > > 
> > > This patch additionally adds the "Time-based UUID" variant of RFC 4122, 
> > > with which userspace applications can easily get real unique time-based 
> > > UUIDs through /proc/sys/kernel/random/uuid_time.
> > > A new /proc/sys/kernel/random/uuid_time_clockseq sysfs entry is available,
> > > so that the clock_seq value can be retained across system bootups (which
> > > is required by RFC 4122).
> > > 
> > > The attached implementation uses getnstimeofday() to get very fine-grained
> > > granularity. This helps, so that userspace tools can get a lot more UUIDs 
> > > (if needed) per time than before.
> > > A mutex takes care of the proper locking against a mistaken double creation 
> > > of UUIDs for simultanious running processes.
> 
> 
> > Who will use this feature, and for what?
> > (In fact, who uses the existing UUID generators, and for what?)
> 
> Current users I know of (but there are more):
> - e2fsprogs uses it e.g. to create unique UUIDs for disks (it ships an own library for that)
> - http://commons.apache.org/sandbox/id/uuid.html uses it with own libraries
> - SAP Netweaver on Linux uses it (http://www.sap.com/platform/netweaver/index.epx)
> 
> I'm mostly interested in fixing problems I see with SAP (I'm working for SAP).
> SAP Netweaver often needs during a very short time frame lots of unique UUIDs 
> (to reference the data afterwards) when new data is imported into the database.
> Main problem with current implementations is, is that they don't 100% 
> guarantee uniqness of the generated UUIDs. Sometimes, esp. on very fast 
> multi-processor machines, double UUIDs are generated and returned to the 
> application which is very bad and may result in unreliable behaviour.
> 
> Current implemenations use userspace-libraries. In userspace you e.g. can't 
> easily protect the uniquness of a UUID against other running _processes_.
> If you try do, you'll need to do locking e.g. with shared memory, which can 
> get very expensive.

Even with a futex? Or userspace atomics? I think something as simple
as a server stuffing a bunch of clock sequence numbers into a pipe
for clients to pop into their generated UUIDs should be plenty fast
enough.

> The problem will get even worse with virtualization technologies like XEN and
> containers. There it's even impossible to protect against processes in other VMs.

Nor does it make sense to try! A virtual machine is an independent machine
after all.

> Another user which could benefit from it are embedded devices. They could 
> drop their userspace-implementations in favour of this smaller kernel version
> to create UUIDs for their disks, using it in the webservers, ...

That's a silly tradeoff. It's an unusual embedded device that ships
with any need for a UUID, especially mkfs. And generally, putting a
feature in the kernel has no inherent size advantage. In fact, it has
a size disadvantage: it's no longer pageable.

ps: I'm the listed random.c maintainer so you'll want to cc: me in the
future.
-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/