linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Buesch <mb@bu3sch.de>
To: Matt Mackall <mpm@selenic.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] hw_random: add quality categories
Date: Tue, 26 Jun 2007 16:45:24 +0200	[thread overview]
Message-ID: <200706261645.24360.mb@bu3sch.de> (raw)
In-Reply-To: <20070626143237.GF11115@waste.org>

On Tuesday 26 June 2007 16:32:37 Matt Mackall wrote:
> > No wait. You are missing the whole point of this
> > quality category.
> > The whole point of it is to prevent defaulting to a bad RNG, if
> > there's a bad and a good one in a machine.
> > Well, what's bad.
> > It's easy. HWRNGs like the one in bcm43xx are bad.
> > It's proprietary and nobody knows what it does (I guess
> > it gathers the entropy from the network or something
> > and hashes that in hardware).
> > So such a device would be QUAL_LOW.
> 
> If it's gathering its entropy from the network, it is not a QUAL_LOW
> RNG because it is not a hardware random number generator at all!
> 
> Such a device is QUAL_PSEUDO or QUAL_UNKNOWN. If it's known or
> suspected to be bogus, it should be so marked. 

No, it should not be marked pseudo. It _is_ a RNG in hardware.
Where it gets its entropy from is unknown. (I'm just guessing
around).
PSEUDO is for example for entropy gathered from hardware sensors.
That's not a RNG (so pseudo) and it's even worse than the proprietary
bcm43xx thing. So bcm43xx(LOW) would win the default over the sensor.
But if there's a RNG in the CPU, it would win over bcm43xx.
And an extension board would win over the CPU.
Yeah, the extension board could in fact produce worse entropy than
the in-CPU thing. If that's the case, remove it from the machine
(or disable it in the sysfs interface).

> Once you've merged your LOW class with PSEUDO, you're left with a
> meaningless, unquantifiable distinction between NORMAL and HIGH.

No, that's not true. I explained the difference to you and it's even
explained in the kdoc help text. Re-read it, please.
HIGH is for seperate dedicated extension devices that you buy and
stick into your machine. So it would default to that, as you want
to use that by default (why would you otherwise stick it in).

To say it again: It all is _just_ for defining a sane _default_
policy. That's all.
Currently the policy is: "Select whatever comes first", which is
random. So it could select crap (bcm43xx) over not-so-crap (in-CPU-RNG).

-- 
Greetings Michael.

  reply	other threads:[~2007-06-26 14:46 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-24 13:55 [PATCH] hw_random: add quality categories Michael Buesch
2007-06-24 14:30 ` Alexey Dobriyan
2007-06-24 14:43   ` Michael Buesch
2007-06-25 23:21 ` Andrew Morton
2007-06-26 13:56   ` Michael Buesch
2007-06-26  3:13 ` Matt Mackall
2007-06-26 14:06   ` Henrique de Moraes Holschuh
2007-06-26 14:20     ` Michael Buesch
2007-06-27  2:00       ` Henrique de Moraes Holschuh
2007-06-27 12:58         ` Michael Buesch
2007-06-27 16:40           ` Henrique de Moraes Holschuh
2007-06-27 17:56             ` Michael Buesch
2007-06-28  7:57               ` Henrique de Moraes Holschuh
2007-06-26 14:12   ` Michael Buesch
2007-06-26 14:32     ` Matt Mackall
2007-06-26 14:45       ` Michael Buesch [this message]
2007-06-27  3:18         ` Matt Mackall
2007-06-27 12:52           ` Michael Buesch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200706261645.24360.mb@bu3sch.de \
    --to=mb@bu3sch.de \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).