[PATCH] hw_random: add quality categories

[PATCH] hw_random: add quality categories

[Michael Buesch]

This adds quality categories for hardware random number generators.

The qualities of the HWRNGs are different from each other.
So the current default policy of the hwrng core to default
to the first found RNG is broken. This changes the default
policy to select the RNG with the best quality category.
So for a machine with a bcm43xx and a RNG in the CPU it
would always default to the RNG in the CPU, as that's the
better one.
Of course, the selection can still be changed from userspace.

Signed-off-by: Michael Buesch <mb@bu3sch.de>

---

Andrew, please include this in -mm for some testing.

Index: bu3sch-wireless-dev/drivers/char/hw_random/core.c
===================================================================
--- bu3sch-wireless-dev.orig/drivers/char/hw_random/core.c	2007-03-05 18:42:03.000000000 +0100
+++ bu3sch-wireless-dev/drivers/char/hw_random/core.c	2007-06-24 15:39:19.000000000 +0200
@@ -78,6 +78,20 @@ static inline int hwrng_data_read(struct
 	return rng->data_read(rng, data);
 }
 
+static const char * hwrng_quality_string(enum hwrng_quality qual)
+{
+	switch (qual) {
+	case HWRNG_QUAL_HIGH:
+		return "high";
+	case HWRNG_QUAL_NORMAL:
+		return "normal";
+	case HWRNG_QUAL_LOW:
+		return "low";
+	case HWRNG_QUAL_PSEUDO:
+		return "pseudo";
+	}
+	return "unknown";
+}
 
 static int rng_dev_open(struct inode *inode, struct file *filp)
 {
@@ -210,7 +224,7 @@ static ssize_t hwrng_attr_current_show(s
 	ret = snprintf(buf, PAGE_SIZE, "%s\n", name);
 	mutex_unlock(&rng_mutex);
 
-	return ret;
+	return min(ret, (ssize_t)PAGE_SIZE);
 }
 
 static ssize_t hwrng_attr_available_show(struct device *dev,
@@ -235,7 +249,36 @@ static ssize_t hwrng_attr_available_show
 	ret++;
 	mutex_unlock(&rng_mutex);
 
-	return ret;
+	return min(ret, (ssize_t)PAGE_SIZE);
+}
+
+static ssize_t hwrng_attr_qualities_show(struct device *dev,
+					 struct device_attribute *attr,
+					 char *buf)
+{
+	int err;
+	ssize_t ret = 0;
+	struct hwrng *rng;
+	const char *qual;
+
+	err = mutex_lock_interruptible(&rng_mutex);
+	if (err)
+		return -ERESTARTSYS;
+	buf[0] = '\0';
+	list_for_each_entry(rng, &rng_list, list) {
+		strncat(buf, rng->name, PAGE_SIZE - ret - 1);
+		ret += strlen(rng->name);
+		strncat(buf, " quality: ", PAGE_SIZE - ret - 1);
+		ret += 10;
+		qual = hwrng_quality_string(rng->qual);
+		strncat(buf, qual, PAGE_SIZE - ret - 1);
+		ret += strlen(qual);
+		strncat(buf, "\n", PAGE_SIZE - ret - 1);
+		ret += 1;
+	}
+	mutex_unlock(&rng_mutex);
+
+	return min(ret, (ssize_t)PAGE_SIZE);
 }
 
 static DEVICE_ATTR(rng_current, S_IRUGO | S_IWUSR,
@@ -244,10 +287,58 @@ static DEVICE_ATTR(rng_current, S_IRUGO 
 static DEVICE_ATTR(rng_available, S_IRUGO,
 		   hwrng_attr_available_show,
 		   NULL);
+static DEVICE_ATTR(rng_qualities, S_IRUGO,
+		   hwrng_attr_qualities_show,
+		   NULL);
+
+
+/* Returns the RNG with the highest quality value.
+ * Expects rng_mutex locked. */
+static struct hwrng * select_best_hwrng(void)
+{
+	struct hwrng *rng, *ret = NULL;
+
+	list_for_each_entry(rng, &rng_list, list) {
+		if (!ret || (rng->qual > ret->qual))
+			ret = rng;
+	}
+
+	return ret;
+}
 
+/* Initializes the RNG with the highest quality value.
+ * Expects rng_mutex locked. */
+static int init_best_hwrng(void)
+{
+	struct hwrng *rng, *prev_rng = NULL;
+	int err;
+
+	rng = select_best_hwrng();
+	if (!rng)
+		return -ENODEV;
+	if (rng == current_rng)
+		return 0;
+	if (current_rng) {
+		/* Shutdown current RNG */
+		prev_rng = current_rng;
+		hwrng_cleanup(current_rng);
+		current_rng = NULL;
+	}
+	err = hwrng_init(rng);
+	if (err) {
+		/* Try to enable the old one again. */
+		if (prev_rng && (hwrng_init(prev_rng) == 0))
+			current_rng = prev_rng;
+		return err;
+	}
+	current_rng = rng;
+
+	return 0;
+}
 
 static void unregister_miscdev(void)
 {
+	device_remove_file(rng_miscdev.this_device, &dev_attr_rng_qualities);
 	device_remove_file(rng_miscdev.this_device, &dev_attr_rng_available);
 	device_remove_file(rng_miscdev.this_device, &dev_attr_rng_current);
 	misc_deregister(&rng_miscdev);
@@ -268,9 +359,16 @@ static int register_miscdev(void)
 				 &dev_attr_rng_available);
 	if (err)
 		goto err_remove_current;
+	err = device_create_file(rng_miscdev.this_device,
+				 &dev_attr_rng_qualities);
+	if (err)
+		goto err_remove_available;
+
 out:
 	return err;
 
+err_remove_available:
+	device_remove_file(rng_miscdev.this_device, &dev_attr_rng_available);
 err_remove_current:
 	device_remove_file(rng_miscdev.this_device, &dev_attr_rng_current);
 err_misc_dereg:
@@ -282,7 +380,7 @@ int hwrng_register(struct hwrng *rng)
 {
 	int must_register_misc;
 	int err = -EINVAL;
-	struct hwrng *old_rng, *tmp;
+	struct hwrng *tmp;
 
 	if (rng->name == NULL ||
 	    rng->data_read == NULL)
@@ -297,27 +395,26 @@ int hwrng_register(struct hwrng *rng)
 			goto out_unlock;
 	}
 
-	must_register_misc = (current_rng == NULL);
-	old_rng = current_rng;
-	if (!old_rng) {
-		err = hwrng_init(rng);
-		if (err)
-			goto out_unlock;
-		current_rng = rng;
-	}
+	must_register_misc = list_empty(&rng_list);
+	INIT_LIST_HEAD(&rng->list);
+	list_add(&rng->list, &rng_list);
+
+	init_best_hwrng();
+	/* We ignore the error code of init_best_hwrng(), as
+	 * it doesn't matter for hwrng_register(). */
 	err = 0;
 	if (must_register_misc) {
 		err = register_miscdev();
 		if (err) {
-			if (!old_rng) {
-				hwrng_cleanup(rng);
+			if (current_rng) {
+				hwrng_cleanup(current_rng);
 				current_rng = NULL;
 			}
+			list_del(&rng->list);
 			goto out_unlock;
 		}
 	}
-	INIT_LIST_HEAD(&rng->list);
-	list_add_tail(&rng->list, &rng_list);
+
 out_unlock:
 	mutex_unlock(&rng_mutex);
 out:
@@ -327,21 +424,15 @@ EXPORT_SYMBOL_GPL(hwrng_register);
 
 void hwrng_unregister(struct hwrng *rng)
 {
-	int err;
-
 	mutex_lock(&rng_mutex);
 
 	list_del(&rng->list);
 	if (current_rng == rng) {
 		hwrng_cleanup(rng);
-		if (list_empty(&rng_list)) {
-			current_rng = NULL;
-		} else {
-			current_rng = list_entry(rng_list.prev, struct hwrng, list);
-			err = hwrng_init(current_rng);
-			if (err)
-				current_rng = NULL;
-		}
+		current_rng = NULL;
+		/* Now try to init another hwrng, if any.
+		 * We're not interested if this fails or not. */
+		init_best_hwrng();
 	}
 	if (list_empty(&rng_list))
 		unregister_miscdev();
Index: bu3sch-wireless-dev/include/linux/hw_random.h
===================================================================
--- bu3sch-wireless-dev.orig/include/linux/hw_random.h	2007-03-05 18:42:17.000000000 +0100
+++ bu3sch-wireless-dev/include/linux/hw_random.h	2007-06-24 15:18:21.000000000 +0200
@@ -16,6 +16,29 @@
 #include <linux/types.h>
 #include <linux/list.h>
 
+
+/**
+ * enum hwrng_quality - Quality identifier for RNG hardware
+ * @HWRNG_QUAL_HIGH:	High quality RNG. Higher quality than
+ * 			what is found on the usual PC mainboards.
+ * 			Use that for special dedicated RNG
+ * 			extension boards.
+ * @HWRNG_QUAL_NORMAL:	PC-onboard-RNG devices.
+ * @HWRNG_QUAL_LOW:	Low quality RNG devices. Use this for
+ * 			devices which gather the entropy from possibly
+ * 			bad sources, like the network.
+ * @HWRNG_QUAL_PSEUDO:	Pseudo RNG device. Use this for devices
+ * 			which are not RNG devices by definition, but
+ * 			could be used as such. For example various
+ * 			hardware sensors, like a motion sensor.
+ */
+enum hwrng_quality {
+	HWRNG_QUAL_HIGH		= 3,
+	HWRNG_QUAL_NORMAL	= 2,
+	HWRNG_QUAL_LOW		= 1,
+	HWRNG_QUAL_PSEUDO	= 0,
+};
+
 /**
  * struct hwrng - Hardware Random Number Generator driver
  * @name:		Unique RNG name.
@@ -28,6 +51,7 @@
  *			Returns the number of lower random bytes in "data".
  *			Must not be NULL.
  * @priv:		Private data, for use by the RNG driver.
+ * @qual:		The quality category of the RNG device.
  */
 struct hwrng {
 	const char *name;
@@ -36,6 +60,7 @@ struct hwrng {
 	int (*data_present)(struct hwrng *rng);
 	int (*data_read)(struct hwrng *rng, u32 *data);
 	unsigned long priv;
+	enum hwrng_quality qual;
 
 	/* internal. */
 	struct list_head list;
Index: bu3sch-wireless-dev/drivers/char/hw_random/amd-rng.c
===================================================================
--- bu3sch-wireless-dev.orig/drivers/char/hw_random/amd-rng.c	2007-03-05 18:42:03.000000000 +0100
+++ bu3sch-wireless-dev/drivers/char/hw_random/amd-rng.c	2007-06-24 15:23:40.000000000 +0200
@@ -99,6 +99,7 @@ static struct hwrng amd_rng = {
 	.cleanup	= amd_rng_cleanup,
 	.data_present	= amd_rng_data_present,
 	.data_read	= amd_rng_data_read,
+	.qual		= HWRNG_QUAL_NORMAL,
 };
 
 
Index: bu3sch-wireless-dev/drivers/char/hw_random/geode-rng.c
===================================================================
--- bu3sch-wireless-dev.orig/drivers/char/hw_random/geode-rng.c	2007-03-05 18:42:03.000000000 +0100
+++ bu3sch-wireless-dev/drivers/char/hw_random/geode-rng.c	2007-06-24 15:23:15.000000000 +0200
@@ -73,6 +73,7 @@ static struct hwrng geode_rng = {
 	.name		= "geode",
 	.data_present	= geode_rng_data_present,
 	.data_read	= geode_rng_data_read,
+	.qual		= HWRNG_QUAL_NORMAL,
 };
 
 
Index: bu3sch-wireless-dev/drivers/char/hw_random/intel-rng.c
===================================================================
--- bu3sch-wireless-dev.orig/drivers/char/hw_random/intel-rng.c	2007-05-18 16:31:10.000000000 +0200
+++ bu3sch-wireless-dev/drivers/char/hw_random/intel-rng.c	2007-06-24 15:24:11.000000000 +0200
@@ -216,6 +216,7 @@ static struct hwrng intel_rng = {
 	.cleanup	= intel_rng_cleanup,
 	.data_present	= intel_rng_data_present,
 	.data_read	= intel_rng_data_read,
+	.qual		= HWRNG_QUAL_NORMAL,
 };
 
 struct intel_rng_hw {
Index: bu3sch-wireless-dev/drivers/char/hw_random/ixp4xx-rng.c
===================================================================
--- bu3sch-wireless-dev.orig/drivers/char/hw_random/ixp4xx-rng.c	2007-03-05 18:42:03.000000000 +0100
+++ bu3sch-wireless-dev/drivers/char/hw_random/ixp4xx-rng.c	2007-06-24 15:24:35.000000000 +0200
@@ -38,6 +38,7 @@ static int ixp4xx_rng_data_read(struct h
 static struct hwrng ixp4xx_rng_ops = {
 	.name		= "ixp4xx",
 	.data_read	= ixp4xx_rng_data_read,
+	.qual		= HWRNG_QUAL_NORMAL,
 };
 
 static int __init ixp4xx_rng_init(void)
Index: bu3sch-wireless-dev/drivers/char/hw_random/pasemi-rng.c
===================================================================
--- bu3sch-wireless-dev.orig/drivers/char/hw_random/pasemi-rng.c	2007-05-18 16:31:10.000000000 +0200
+++ bu3sch-wireless-dev/drivers/char/hw_random/pasemi-rng.c	2007-06-24 15:25:00.000000000 +0200
@@ -137,6 +137,7 @@ static struct of_platform_driver rng_dri
 	.match_table	= rng_match,
 	.probe		= rng_probe,
 	.remove		= rng_remove,
+	.qual		= HWRNG_QUAL_NORMAL,
 };
 
 static int __init rng_init(void)
Index: bu3sch-wireless-dev/drivers/char/hw_random/via-rng.c
===================================================================
--- bu3sch-wireless-dev.orig/drivers/char/hw_random/via-rng.c	2007-05-18 16:31:10.000000000 +0200
+++ bu3sch-wireless-dev/drivers/char/hw_random/via-rng.c	2007-06-24 15:25:25.000000000 +0200
@@ -150,6 +150,7 @@ static struct hwrng via_rng = {
 	.init		= via_rng_init,
 	.data_present	= via_rng_data_present,
 	.data_read	= via_rng_data_read,
+	.qual		= HWRNG_QUAL_NORMAL,
 };
 
 
Index: bu3sch-wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===================================================================
--- bu3sch-wireless-dev.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c	2007-05-18 16:31:17.000000000 +0200
+++ bu3sch-wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_main.c	2007-06-24 15:26:49.000000000 +0200
@@ -3278,6 +3278,7 @@ static int bcm43xx_rng_init(struct bcm43
 	bcm->rng.name = bcm->rng_name;
 	bcm->rng.data_read = bcm43xx_rng_read;
 	bcm->rng.priv = (unsigned long)bcm;
+	bcm->rng.qual = HWRNG_QUAL_LOW;
 	err = hwrng_register(&bcm->rng);
 	if (err)
 		printk(KERN_ERR PFX "RNG init failed (%d)\n", err);
Index: bu3sch-wireless-dev/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c
===================================================================
--- bu3sch-wireless-dev.orig/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c	2007-06-23 11:50:59.000000000 +0200
+++ bu3sch-wireless-dev/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c	2007-06-24 15:26:14.000000000 +0200
@@ -2416,6 +2416,7 @@ static int bcm43xx_rng_init(struct bcm43
 	wl->rng.name = wl->rng_name;
 	wl->rng.data_read = bcm43xx_rng_read;
 	wl->rng.priv = (unsigned long)wl;
+	wl->rng.qual = HWRNG_QUAL_LOW;
 	wl->rng_initialized = 1;
 	err = hwrng_register(&wl->rng);
 	if (err) {

-- 
Greetings Michael.

Re: [PATCH] hw_random: add quality categories

[Alexey Dobriyan]

On Sun, Jun 24, 2007 at 03:55:22PM +0200, Michael Buesch wrote:
> This adds quality categories for hardware random number generators.

> +static const char * hwrng_quality_string(enum hwrng_quality qual)
> +{
> +	switch (qual) {
> +	case HWRNG_QUAL_HIGH:
> +		return "high";
> +	case HWRNG_QUAL_NORMAL:
> +		return "normal";
> +	case HWRNG_QUAL_LOW:
> +		return "low";
> +	case HWRNG_QUAL_PSEUDO:
> +		return "pseudo";

And how are you going to extend this in future? HWRNG_QUAL_SUPERB ?

Re: [PATCH] hw_random: add quality categories

[Michael Buesch]

On Sunday 24 June 2007 16:30:59 Alexey Dobriyan wrote:
> On Sun, Jun 24, 2007 at 03:55:22PM +0200, Michael Buesch wrote:
> > This adds quality categories for hardware random number generators.
> 
> > +static const char * hwrng_quality_string(enum hwrng_quality qual)
> > +{
> > +	switch (qual) {
> > +	case HWRNG_QUAL_HIGH:
> > +		return "high";
> > +	case HWRNG_QUAL_NORMAL:
> > +		return "normal";
> > +	case HWRNG_QUAL_LOW:
> > +		return "low";
> > +	case HWRNG_QUAL_PSEUDO:
> > +		return "pseudo";
> 
> And how are you going to extend this in future? HWRNG_QUAL_SUPERB ?

Why extend it? "high" means devices which generate truely
random data. Do you have a device which generates data more
random than true-random? how?

See the descriptions in hw_random.h

-- 
Greetings Michael.

Re: [PATCH] hw_random: add quality categories

[Andrew Morton]

On Sun, 24 Jun 2007 15:55:22 +0200
Michael Buesch <mb@bu3sch.de> wrote:

> The qualities of the HWRNGs are different from each other.
> So the current default policy of the hwrng core to default
> to the first found RNG is broken. This changes the default
> policy to select the RNG with the best quality category.
> So for a machine with a bcm43xx and a RNG in the CPU it
> would always default to the RNG in the CPU, as that's the
> better one.
> Of course, the selection can still be changed from userspace.

I'm presently having git disasters with the wireless tree and am unable to
include it in the -mm lineup so the hunk against
drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c doesn't apply here.

I stuck that change into a second patch and commented it out.  I will
hopefully remember to bring that patch back when git-wireless gets sorted
out.

Re: [PATCH] hw_random: add quality categories

[Michael Buesch]

On Tuesday 26 June 2007 01:21:56 Andrew Morton wrote:
> On Sun, 24 Jun 2007 15:55:22 +0200
> Michael Buesch <mb@bu3sch.de> wrote:
> 
> > The qualities of the HWRNGs are different from each other.
> > So the current default policy of the hwrng core to default
> > to the first found RNG is broken. This changes the default
> > policy to select the RNG with the best quality category.
> > So for a machine with a bcm43xx and a RNG in the CPU it
> > would always default to the RNG in the CPU, as that's the
> > better one.
> > Of course, the selection can still be changed from userspace.
> 
> I'm presently having git disasters with the wireless tree and am unable to
> include it in the -mm lineup so the hunk against
> drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c doesn't apply here.
> 
> I stuck that change into a second patch and commented it out.  I will
> hopefully remember to bring that patch back when git-wireless gets sorted
> out.

Ok, thanks. I'll tell you, in case you forget it.

-- 
Greetings Michael.

Re: [PATCH] hw_random: add quality categories

[Matt Mackall]

On Sun, Jun 24, 2007 at 03:55:22PM +0200, Michael Buesch wrote:
> This adds quality categories for hardware random number generators.
> 
...
> +
> +/**
> + * enum hwrng_quality - Quality identifier for RNG hardware
> + * @HWRNG_QUAL_HIGH:	High quality RNG. Higher quality than
> + * 			what is found on the usual PC mainboards.
> + * 			Use that for special dedicated RNG
> + * 			extension boards.
> + * @HWRNG_QUAL_NORMAL:	PC-onboard-RNG devices.
> + * @HWRNG_QUAL_LOW:	Low quality RNG devices. Use this for
> + * 			devices which gather the entropy from possibly
> + * 			bad sources, like the network.
> + * @HWRNG_QUAL_PSEUDO:	Pseudo RNG device. Use this for devices
> + * 			which are not RNG devices by definition, but
> + * 			could be used as such. For example various
> + * 			hardware sensors, like a motion sensor.
> + */

I don't think these definitions are very useful.

There are basically three ways of measuring RNG quality:

a) does it generate a good spectrum based on an unpredictable physical
process like Schott noise or free-running oscillator beat patterns?

b) can the end-user trust that the design is implemented as described?

c) does it output lots of bits fast?

Anything that fails (a) belongs in the PSEUDO class. This applies to
RNGs where the implementation is undocumented too. (There's not much
excuse for this as it costs negligible silicon to do this right.)

Anything that passes (b) is something that the end-user built
themselves while wearing their tinfoil hat.

Anything that claims to be significantly better than the trivial
circuit and whitening on a typical PC is probably marketing hype. 

Which brings us down to (c). And basically all hardware RNGs are
plenty fast enough.

So that's basically three orthogonal axes: "real", "trusted", and
"fast". And "trusted" trumps "real", which trumps "fast".

-- 
Mathematics is the supreme nostalgia of our time.

Re: [PATCH] hw_random: add quality categories

[Henrique de Moraes Holschuh]

On Mon, 25 Jun 2007, Matt Mackall wrote:
> On Sun, Jun 24, 2007 at 03:55:22PM +0200, Michael Buesch wrote:
> > This adds quality categories for hardware random number generators.
> > + * enum hwrng_quality - Quality identifier for RNG hardware
> > + * @HWRNG_QUAL_HIGH:	High quality RNG. Higher quality than
> > + * 			what is found on the usual PC mainboards.
> > + * 			Use that for special dedicated RNG
> > + * 			extension boards.
> > + * @HWRNG_QUAL_NORMAL:	PC-onboard-RNG devices.
> > + * @HWRNG_QUAL_LOW:	Low quality RNG devices. Use this for
> > + * 			devices which gather the entropy from possibly
> > + * 			bad sources, like the network.
> > + * @HWRNG_QUAL_PSEUDO:	Pseudo RNG device. Use this for devices
> > + * 			which are not RNG devices by definition, but
> > + * 			could be used as such. For example various
> > + * 			hardware sensors, like a motion sensor.
> 
> I don't think these definitions are very useful.

Agreed. They are horrible.

> There are basically three ways of measuring RNG quality:
> 
> a) does it generate a good spectrum based on an unpredictable physical
> process like Schott noise or free-running oscillator beat patterns?

Which, AFAIK, we can quantify as the minimum expected entropy in the output.

You can get output with the minimum expected entropy quite close to 1 from
good HRNGs.  Note that the same HRNGs might be configurable to disable the
whitener and output more bits, dropping to an expected minimum entropy of
0.75 for example (say hello, VIA Padlock!).

So quality is a property of (HRNG implementation, HRNG configuration when
the data was generated).

AFAIK, what really matters on a RNG is:

	0. trust on the design and implementation
	1. quality (minimum entropy expected on output)
	2. speed (minimum and average bits-per-second expected on output)
	3. whether it is implemented on software, or not.

Anything else is just *useless*.  And which RNG you should use (if you have
more than one available), based on the four attributes above, depends on
what you want to do.

> b) can the end-user trust that the design is implemented as described?

Heh, that's a hard one :-)  But I'd say HRNGs without at least a peer review
and open design are not to be trusted at all (which doesn't mean that those
which do have a peer review and open design can be trusted...).

> c) does it output lots of bits fast?

Yeah, you can go from a few bit/s, to some kbits/s, to megabits/s, it is a
damn important thing to know.

> Anything that fails (a) belongs in the PSEUDO class. This applies to
> RNGs where the implementation is undocumented too. (There's not much
> excuse for this as it costs negligible silicon to do this right.)

I'd say RNGs where the implementation is undocumented should not even be
supported at all...  but they certainly cannot be considered anything but
pseudo-random.

> Anything that passes (b) is something that the end-user built
> themselves while wearing their tinfoil hat.

Yes. Leave the user to decide whether they trust it or not.  And if the
kernel needs to know this, default to untrusted and let the user set a trust
level through some parameter.

> Anything that claims to be significantly better than the trivial
> circuit and whitening on a typical PC is probably marketing hype. 

Sort of.  But IMHO, such claims, when not backed by some hard paper analysis
the RNG design and output by third-parties, really are a reason to
*blacklist* the RNG and not use it at all.

> Which brings us down to (c). And basically all hardware RNGs are
> plenty fast enough.

Err... not really.  Intel's 82802AB or 82802AC-builtin RNG gives only ~24 *
10^3 bit/s, which is not much depending on what you are doing, for example.
While a VIA Padlock dual-HRNG CPU can easily output 1 * 10^6 bits/s of data
in its highest quality setting.  With such a bit amplitude of speeds
available, I really doubt you can say that all HRNGs are plenty fast enough.

> So that's basically three orthogonal axes: "real", "trusted", and
> "fast". And "trusted" trumps "real", which trumps "fast".

Heh. Indeed.

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

Re: [PATCH] hw_random: add quality categories

[Michael Buesch]

On Tuesday 26 June 2007 16:06:25 Henrique de Moraes Holschuh wrote:
> Which, AFAIK, we can quantify as the minimum expected entropy in the output.

The category is _not_ a measure of the entropy in the output.
It is _just_ to get the chance to get a sane _default_ policy
for which RNG is enabled by default, in the kernel.
It's just about a default policy. _Nothing_ else.

-- 
Greetings Michael.

Re: [PATCH] hw_random: add quality categories

[Henrique de Moraes Holschuh]

On Tue, 26 Jun 2007, Michael Buesch wrote:
> On Tuesday 26 June 2007 16:06:25 Henrique de Moraes Holschuh wrote:
> > Which, AFAIK, we can quantify as the minimum expected entropy in the output.
> 
> The category is _not_ a measure of the entropy in the output.
> It is _just_ to get the chance to get a sane _default_ policy
> for which RNG is enabled by default, in the kernel.
> It's just about a default policy. _Nothing_ else.

Then why don't you call it "preference", or something to that effect?

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

Re: [PATCH] hw_random: add quality categories

[Michael Buesch]

On Wednesday 27 June 2007 04:00:46 Henrique de Moraes Holschuh wrote:
> On Tue, 26 Jun 2007, Michael Buesch wrote:
> > On Tuesday 26 June 2007 16:06:25 Henrique de Moraes Holschuh wrote:
> > > Which, AFAIK, we can quantify as the minimum expected entropy in the output.
> > 
> > The category is _not_ a measure of the entropy in the output.
> > It is _just_ to get the chance to get a sane _default_ policy
> > for which RNG is enabled by default, in the kernel.
> > It's just about a default policy. _Nothing_ else.
> 
> Then why don't you call it "preference", or something to that effect?

Why? Because I did not get the same idea as you?
So, please make up "preference" categories and give me some examples.

-- 
Greetings Michael.

Re: [PATCH] hw_random: add quality categories

[Henrique de Moraes Holschuh]

Hi Michael!

On Wed, 27 Jun 2007, Michael Buesch wrote:

> On Wednesday 27 June 2007 04:00:46 Henrique de Moraes Holschuh wrote:
> > On Tue, 26 Jun 2007, Michael Buesch wrote:
> > > On Tuesday 26 June 2007 16:06:25 Henrique de Moraes Holschuh wrote:
> > > > Which, AFAIK, we can quantify as the minimum expected entropy in the output.
> > > 
> > > The category is _not_ a measure of the entropy in the output.
> > > It is _just_ to get the chance to get a sane _default_ policy
> > > for which RNG is enabled by default, in the kernel.
> > > It's just about a default policy. _Nothing_ else.
> > 
> > Then why don't you call it "preference", or something to that effect?
> 
> Why? Because I did not get the same idea as you?
> So, please make up "preference" categories and give me some examples.

preference: 

	scalar, unsigned 32 bit value.  Higher values mean higher
	preference.

	values:

	0 - ANYTHING that has no peer-review papers for both design and
	implementation, done by third-parties with reasonable credence in
	the field.  Anything for which the expected minimum entropy per bit
	of output is unknown, or below 50%.  This includes all pseudo-random
	RNGs, as we are not evaulating the seeding here.

	Never use anything with preference zero by default.

	
	For H-RNGs that have their design and implementation public and
	peer-reviewed by at least one third-party with reasonable credence
	in the field, and for which the minimum worst-case expected entropy
	per bit of output is known and equal or higher than 50.000% (if it
	was reviewed, it will be known), calculate preference as follows:

	LSW (lower 16 bits) should be the average bandwidth of the RNG, in
	10^3 bit/s. Use 0 for RNGs slower than 10^3 bits/s.  Use 0xFFFF for
	RNGs faster than 65535*10^3 bits/s (if this scale is not good
	enough, I suggest one with 0 being 10^3 bit/s or lower, and 0xFFFF
	being 10^7 bit/s or higher).

	MSW (higher 16 bits) should be the expected worst-case minimum
	entropy per bit of output of the RNG with at least 1% confidence. 0
	means a minimum worst-case entropy per bit of output of 50.000%,
	0xFFFF means a minimum worst-case entropy per bit of output of
	99.999% or higher.


Add a "fail always" RNG device to select by default if only RNGs of
preference zero are available, and select by default the RNG with highest
preference (or the first one you find, in case of a tie), and you are set.

It is not perfect, but it at least it makes some sense.

There *is* a much better way to deal with it, though.  Add the fail always
RNG device, and always select it by default.  Let the user specifically set
which RNG he wants, and it now rates as "trusted", which is the only
fail-proof way to go about it IMHO.

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

Re: [PATCH] hw_random: add quality categories

[Michael Buesch]

On Wednesday 27 June 2007 18:40:41 Henrique de Moraes Holschuh wrote:
> There *is* a much better way to deal with it, though.  Add the fail always
> RNG device, and always select it by default.  Let the user specifically set
> which RNG he wants, and it now rates as "trusted", which is the only
> fail-proof way to go about it IMHO.

Well, but it changes ABI, which is forbidden.
After a kernel update your system will partially not work anymore.

-- 
Greetings Michael.

Re: [PATCH] hw_random: add quality categories

[Henrique de Moraes Holschuh]

On Wed, 27 Jun 2007, Michael Buesch wrote:
> On Wednesday 27 June 2007 18:40:41 Henrique de Moraes Holschuh wrote:
> > There *is* a much better way to deal with it, though.  Add the fail always
> > RNG device, and always select it by default.  Let the user specifically set
> > which RNG he wants, and it now rates as "trusted", which is the only
> > fail-proof way to go about it IMHO.
> 
> Well, but it changes ABI, which is forbidden.
> After a kernel update your system will partially not work anymore.

<shrug>.  At least it will not be doing anything dangerous, and it is a ABI
*fix*, so you are not just changing it for the kicks 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

Re: [PATCH] hw_random: add quality categories

[Michael Buesch]

On Tuesday 26 June 2007 05:13:41 Matt Mackall wrote:
> On Sun, Jun 24, 2007 at 03:55:22PM +0200, Michael Buesch wrote:
> > This adds quality categories for hardware random number generators.
> > 
> ...
> > +
> > +/**
> > + * enum hwrng_quality - Quality identifier for RNG hardware
> > + * @HWRNG_QUAL_HIGH:	High quality RNG. Higher quality than
> > + * 			what is found on the usual PC mainboards.
> > + * 			Use that for special dedicated RNG
> > + * 			extension boards.
> > + * @HWRNG_QUAL_NORMAL:	PC-onboard-RNG devices.
> > + * @HWRNG_QUAL_LOW:	Low quality RNG devices. Use this for
> > + * 			devices which gather the entropy from possibly
> > + * 			bad sources, like the network.
> > + * @HWRNG_QUAL_PSEUDO:	Pseudo RNG device. Use this for devices
> > + * 			which are not RNG devices by definition, but
> > + * 			could be used as such. For example various
> > + * 			hardware sensors, like a motion sensor.
> > + */
> 
> I don't think these definitions are very useful.
...

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.
_All_ HWRNGs that are shipped onboard in machines are
QUAL_NORMAL. There's no point in prefering an intel RNG
over and AMD RNG, although there might be differences.
These quality categories are only a _rough_ estimation
of how good the device is.
The reference frame for this estimation are the normal
onboard (or on-CPU) RNGs that are shipped.

This is _not_ a test to rule out your RNG extender board
for 10,000USD against the one which costs 100,000USD. They
would _both_ get QUAL_HIGH. So it's up to the user which
one of the devices he uses. But the important thing is that
this quality categories prevent the kernel from _defaulting_
to the in-CPU RNG, while a 10,000USD extender card is installed.

QUAL_LOW and QUAL_PSEUDO are _not_ to be used for real
HWRNGs. These categories are only for devices that can be used
to get entropy, _if_ there's nothing better in the machine.

Of would you like to generate your keys from entropy gathered
by your wireless-card, while you have a perfectly fine RNG in
your shiny CPU? This patch prevents that.
And you can still switch to your crappy wireless-card, if you
like that, in sysfs.

-- 
Greetings Michael.

Re: [PATCH] hw_random: add quality categories

[Matt Mackall]

On Tue, Jun 26, 2007 at 04:12:26PM +0200, Michael Buesch wrote:
> On Tuesday 26 June 2007 05:13:41 Matt Mackall wrote:
> > On Sun, Jun 24, 2007 at 03:55:22PM +0200, Michael Buesch wrote:
> > > This adds quality categories for hardware random number generators.
> > > 
> > ...
> > > +
> > > +/**
> > > + * enum hwrng_quality - Quality identifier for RNG hardware
> > > + * @HWRNG_QUAL_HIGH:	High quality RNG. Higher quality than
> > > + * 			what is found on the usual PC mainboards.
> > > + * 			Use that for special dedicated RNG
> > > + * 			extension boards.
> > > + * @HWRNG_QUAL_NORMAL:	PC-onboard-RNG devices.
> > > + * @HWRNG_QUAL_LOW:	Low quality RNG devices. Use this for
> > > + * 			devices which gather the entropy from possibly
> > > + * 			bad sources, like the network.
> > > + * @HWRNG_QUAL_PSEUDO:	Pseudo RNG device. Use this for devices
> > > + * 			which are not RNG devices by definition, but
> > > + * 			could be used as such. For example various
> > > + * 			hardware sensors, like a motion sensor.
> > > + */
> > 
> > I don't think these definitions are very useful.
> ...
> 
> 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. 

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

So we're down to one bit distinguishing real RNGs from pseudo RNGs.

-- 
Mathematics is the supreme nostalgia of our time.

Re: [PATCH] hw_random: add quality categories

[Michael Buesch]

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.

Re: [PATCH] hw_random: add quality categories

[Matt Mackall]

On Tue, Jun 26, 2007 at 04:45:24PM +0200, Michael Buesch wrote:
> 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.

Again, if it's not using an underlying physical process that's
unpredictable, it does not deserve to be called a real HWRNG. It's no
better than the software PRNG in the kernel at that point.

If you have a reasonable suspicion that this is the case with the BCM
part, then you should so mark it.

> Where it gets its entropy from is unknown. (I'm just guessing
> around).
> PSEUDO is for example for entropy gathered from hardware sensors.

Not sure what this means. Some hardware sensors are quite good sources
of noise. What gets you into trouble is when the sources are either
predictable (ie heavily correlated with fixed-frequency crosstalk),
observable (ie wireless traffic), or controllable (ie wireless traffic).

> > 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).

I do not believe there exist devices that deserve to be classified as
"HIGH". Any device that makes this claim probably instead deserves to
be classified as "SNAKE OIL". Making a high-quality HWRNG is easy, and
cheap (>$.05), and very hard to improve on except by upping the
bandwidth. Anyone who tells you that their HWRNG is significantly or
even measurably better than the one in, say, VIA Padlock, in any
dimension except for speed, they are almost certainly LYING.

Given that, I'd really rather not create an opportunity for such snake
oil salesmen to claim to be "the only Linux-supported RNG to use
QUAL_HIGH" or some such bullshit.

> 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).

That's perfectly reasonable. And all I'm saying is please have only
two levels: CRAP and NOTCRAP. Anything else just muddies the waters.

-- 
Mathematics is the supreme nostalgia of our time.

Re: [PATCH] hw_random: add quality categories

[Michael Buesch]

On Wednesday 27 June 2007 05:18:00 Matt Mackall wrote:
> On Tue, Jun 26, 2007 at 04:45:24PM +0200, Michael Buesch wrote:
> > 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.
> 
> Again, if it's not using an underlying physical process that's
> unpredictable, it does not deserve to be called a real HWRNG. It's no
> better than the software PRNG in the kernel at that point.
> 
> If you have a reasonable suspicion that this is the case with the BCM
> part, then you should so mark it.

Done so in the new patch.

> > 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).
> 
> I do not believe there exist devices that deserve to be classified as
> "HIGH".

You still didn't understand what I am trying to explain.
Please look at my new patch. The "DEDICATED" type is what QUAL_HIGH
meant.

Again: It is _just_ for selecting a default policy of which RNG
to enable by default. It is _not_ about quality. (And so the QUAL_XXX
defines were misnamed).

-- 
Greetings Michael.