linux-kernel - Re: [PATCH v3 21/22] netoops: Add user-programmable boot

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: <20101215021651.GA9463@thunk.org>
Date:	Tue, 14 Dec 2010 21:16:51 -0500
From:	Ted Ts'o <tytso@....edu>
To:	Mike Waychison <mikew@...gle.com>
Cc:	Matt Mackall <mpm@...enic.com>, simon.kagstrom@...insight.net,
	davem@...emloft.net, nhorman@...driver.com, adurbin@...gle.com,
	linux-kernel@...r.kernel.org, chavey@...gle.com,
	Greg KH <greg@...ah.com>, netdev@...r.kernel.org,
	Américo Wang <xiyou.wangcong@...il.com>,
	akpm@...ux-foundation.org, linux-api@...r.kernel.org
Subject: Re: [PATCH v3 21/22] netoops: Add user-programmable boot_id

On Tue, Dec 14, 2010 at 03:19:50PM -0800, Mike Waychison wrote:
> 
> I'm not sure there is a _good_ way to support this, is there?  I just
> read through RFC 4122 and UUIDs seem to be pretty well structured;
> it's probably not such a great idea to allow folks to override
> portions of it.  Like I mentioned in my last email though, I'm okay
> pushing this boot sequence ID down into the user blob which acts like
> a place for "vendor extensions" if there isn't a good place for it in
> the kernel.

If you really wanted to do it I could imagine using a time-based UUID
(see RFC 4122, section 4.2), where the boot sequence number could be
mapped into the 14-bit clock sequence, and using the time read from
the hardware counter and the ethernet MAC address from... umm the
"first" ethernet port (depending on how you define that) to form a
UUID.  I'm not convinced it's really worth it, though, unless someone
really wants a good per-boot session UUID generated some other way
than a random number generator that may not be all that adequately
seed at the time when you first sample the boot session UUID.

I suspect pushing the boot sequence ID into its own special field with
the semantics that you want is probably the better way to go.

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