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: <20071120230012.GF26022@thunk.org>
Date:	Tue, 20 Nov 2007 18:00:12 -0500
From:	Theodore Tso <tytso@....edu>
To:	Helge Deller <deller@....de>
Cc:	Matt Mackall <mpm@...enic.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Time-based RFC 4122 UUID generator

On Tue, Nov 20, 2007 at 10:59:58PM +0100, Helge Deller wrote:
> > Even with a futex? Or userspace atomics? 
> 
> Yes, you'll need a futex or similiar.
>
> The problem is then more, where will you put that futex to be able
> to protect against other processes ?
> 
> Best solution is probably shared memory, but then the question will
> be, who is allowed to access this memory/futex ?
>
> Will any process (shared library) be allowed to read/write/delete it?
>
> At this stage you then suddenly run from a locking-problem into a
> security problem, which is probably equally hard to solve.

Basically, the only way to solve this problem 100% in userspace would
be with a userspace daemon running as a privileged user, and some kind
of Unix domain socket.

Patches to implement this in the e2fsprogs UUID library would be
greatfully accepted.

> Sounds simple and is probably fast enough.
>
> But do you really want to add then another daemon to the Linux
> system, just in case "some" application needs somewhen a UUID ?
> 
> And I think such an implementation is more complex, would need more
> memory, file handles, and so on than this simple kernel patch.

Well, it probably is less code, but keep in mind to really get things
right, you need to store the UUID counter on disk, so there is some
complexity which is needed in userspace anyway.

One bigger question which is why do you want to use time-based UUID's?
With the kernels random number generator, the random UUID's should be
quite good enough for your purposes.

> I think mkfs was a very bad example from my side. I should not have
> mentioned this one.  Nevertheless, time-based UUIDs are used in
> quite many other and more critical applications than e2fsprogs
> tools.

Actually, these days e2fsprogs uses random-based UUID's.

							- Ted
-
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/