hw_random: add quality categories

drivers/char/hw_random/core.c static inline int hwrng_data_read(struct · line 91

Quoted 13 lines · Michael Buesch

This adds quality categories for hardware random number generators.

drivers/char/hw_random/core.c +11 -0

+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 ?

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.

Quoted 8 lines · On Sun, 24 Jun 2007 15:55:22 +0200 Michael Buesch <[email protected]> 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.

This adds quality categories for hardware random number generators.

include/linux/hw_random.h +6 -0

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

Quoted 6 lines · Michael Buesch

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.

Quoted 8 lines

+ * @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".

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

Quoted 1 line · 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.

Quoted 7 lines · Michael Buesch

Quoted 1 line · 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?

Quoted 9 lines · On Wednesday 27 June 2007 04:00:46 Henrique de Moraes Holschuh wrote:

Quoted 7 lines · Michael Buesch

Quoted 1 line · 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.

Quoted 1 line

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.

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.

Quoted 4 lines · 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.

Quoted 2 lines · Michael Buesch

This adds quality categories for hardware random number generators.

...

Quoted 10 lines

include/linux/hw_random.h +10 -0

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

Quoted 6 lines

+ * 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.

Quoted 22 lines · On Tuesday 26 June 2007 05:13:41 Matt Mackall wrote:

Quoted 2 lines · Michael Buesch

This adds quality categories for hardware random number generators.

...

Quoted 6 lines

include/linux/hw_random.h +6 -0

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

include/linux/hw_random.h line 34

Quoted 10 lines

include/linux/hw_random.h +10 -0

+ * 			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.

Quoted 10 lines

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.

Quoted 11 lines · On Tuesday 26 June 2007 16:32:37 Matt Mackall wrote:

Quoted 10 lines

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.

Quoted 5 lines

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.

Quoted 2 lines

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

Quoted 18 lines · Michael Buesch

Quoted 16 lines · On Tuesday 26 June 2007 16:32:37 Matt Mackall wrote:

Quoted 10 lines

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.

Quoted 1 line

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.

Quoted 5 lines

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