linux-kernel - Re: [PATCH] dmi: Feed DMI table to /dev/random driver

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: <20120721020258.GA12898@thunk.org>
Date:	Fri, 20 Jul 2012 22:02:58 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Tony Luck <tony.luck@...el.com>
Cc:	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	w@....eu, ewust@...ch.edu, zakir@...ch.edu, greg@...ah.com,
	mpm@...enic.com, nadiah@...ucsd.edu, jhalderm@...ch.edu,
	tglx@...utronix.de, davem@...emloft.net
Subject: Re: [PATCH] dmi: Feed DMI table to /dev/random driver

On Fri, Jul 20, 2012 at 06:19:33PM -0700, Tony Luck wrote:
> On Fri, Jul 20, 2012 at 5:56 PM, Theodore Ts'o <tytso@....edu> wrote:
> > The other approach was to add some new interface that random.c would
> > call which would grab the dmi data from rand_initialize().  But that's
> > going to be a lot more complicated, so I guess we should go with the
> > simple/stupid approach.
> 
> It wouldn't be all that hard ... we'd just need to add a new entry point
> to the dmi codefor random to call (and a stub somewhere so that
> CONFIG_DMI=n kernels still build). But getting some per-platform
> data into the random pools earlier is a good thing ... it means that
> users of random data will see the benefit earlier than they do now.

Yeah, what makes it tricky is if we wanted to do things in an arch
independent way, since I assume there are architectures out there
which have something which has the same sort of information as the DMI
tables, but which would be something else.  So we'd need to have some
interface which could be defined by each architecture, and a no-op
function for architectures that didn't provide such a thing.

> So add the big fat comment so that people know not to break this
> useful (if not entirely intentional) functionality.

I agree.  Want to send a revised patch with the comment, and I'll drop
it into the random.git tree?

Thanks,

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