linux-kernel - Re: [PATCH RFC #2] hwrng: Add type categories

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]

Date:	Tue, 26 Jun 2007 23:48:56 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Matt Mackall <mpm@...enic.com>
Cc:	Michael Buesch <mb@...sch.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC #2] hwrng: Add type categories

On Tue, 26 Jun 2007, Matt Mackall wrote:
> On Tue, Jun 26, 2007 at 08:21:51PM +0200, Michael Buesch wrote:
> > Don't use the word "quality", as people seem to think of
> > the entropy quality when hearing that word.
> 
> Why do I so often feel compelled to respond with "did you read what I
> wrote?" on this list?
> 
> I object to your MEANINGLESS CATEGORIES.
> 
> > This uses the word "type", which is probably better for
> > understanding what the value really means.
> 
> Please explain:
> 
> a) how is bad different from pseudo?
> b) how is onboard different than dedicated?

Actually, I think I understand the reason behind (b).  If someone adds a
dedicated crypto/RNG engine to the system, he likely wants to use that and
not anything else that might also be around.

(a) is just broken, unless one is to take it as "never use it".  And I am
really not sure about (b).  It *is* better than just using whatever crap we
found first (or last), but it is the wrong solution for a problem that we
really should not have in the first place if someone had thought a bit
before adding a misc device for something that has no reason to be unique in
a system.

Instead of papering over the problem with borked solutions, maybe we should
just export ALL HRNGs to userspace.  While at it, please add whatever is
needed so that userspace can talk to the kernel driver to get vital
information about the HRNG device the driver might have (the current
interface is a bad simplistic hack).

Let userspace get the data from whichever HRNG it wants, process it in any
way it wants and pipe it back through /dev/random IOCTLs.  And let it do it
for as many HRNGs it wants at the same time.

And if you must have /dev/hw_random point somewhere, let udev scripts or
something else like that take care of it.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
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/