: khwrngd

This can be viewed as the in-kernel equivalent of hwrngd; like FUSE it is a good thing to have a mechanism in user land, but for some reasons (simplicity, secrecy, integrity, speed) it may be better to have it in kernel space.

drivers/char/hw_random/core.c renamed from drivers/char/hw_random/core.c.orig +4 -0

+
+static void start_khwrngd(void);
 
 static size_t rng_buffer_size(void)
 {

@@ -62,9 +71,18 @@ static size_t rng_buffer_size(void)
 
 static inline int hwrng_init(struct hwrng *rng)
 {
+	int err;
+

drivers/char/hw_random/core.c renamed from drivers/char/hw_random/core.c.orig +2 -0

+	return 0;
 }
 
 static inline void hwrng_cleanup(struct hwrng *rng)

@@ -300,6 +318,36 @@ err_misc_dereg:
 	goto out;
 }
 
+static int hwrng_fillfn(void *unused)

Quoted 4 lines · Torsten Duwe

This can be viewed as the in-kernel equivalent of hwrngd; like FUSE it is a good thing to have a mechanism in user land, but for some reasons (simplicity, secrecy, integrity, speed) it may be better to have it in kernel space.

Nice.

[...]

drivers/char/hw_random/core.c line 63

Quoted 13 lines

static struct hwrng *current_rng;

drivers/char/hw_random/core.c renamed from drivers/char/hw_random/core.c.orig +7 -1

+static struct task_struct *hwrng_fill;
 static LIST_HEAD(rng_list);
 static DEFINE_MUTEX(rng_mutex);
 static int data_avail;
-static u8 *rng_buffer;
+static u8 *rng_buffer, *rng_fillbuf;
+static unsigned short derating_current = 700; /* an arbitrary 70% */
+
+module_param(derating_current, ushort, 0644);
+MODULE_PARM_DESC(derating_current,
+		 "current hwrng entropy estimation per mill");

As an electrical engineer (sort of), I can't read this without thinking you're talking about the amount by which the current is derated. For example, a 14-50 electrical outlet is rated to 50 Amps. If you use it continuously for a long time, though, the current is derated to 40 Amps.

Shouldn't this be called credit_derating or, even better, credit_per_1000bits?

Also, "per mill" is just obscure enough that someone might think it means "per million".

Quoted 11 lines

drivers/char/hw_random/core.c renamed from drivers/char/hw_random/core.c.orig +4 -0

+
+static void start_khwrngd(void);
 
 static size_t rng_buffer_size(void)
 {

@@ -62,9 +71,18 @@ static size_t rng_buffer_size(void)
 
 static inline int hwrng_init(struct hwrng *rng)
 {
+	int err;
+

drivers/char/hw_random/core.c static size_t rng_buffer_size(void) · line 84

Quoted 10 lines

drivers/char/hw_random/core.c renamed from drivers/char/hw_random/core.c.orig +7 -1

 	if (!rng->init)
 		return 0;
-	return rng->init(rng);
+	err = rng->init(rng);
+	if (err)
+		return err;
+
+	if (derating_current > 0 && !hwrng_fill)
+		start_khwrngd();
+

Why the check for derating > 0? Paranoid users may want zero credit, but they probably still want the thing to run.

Quoted 9 lines

drivers/char/hw_random/core.c renamed from drivers/char/hw_random/core.c.orig +2 -0

+	return 0;
 }
 
 static inline void hwrng_cleanup(struct hwrng *rng)

@@ -300,6 +318,36 @@ err_misc_dereg:
 	goto out;
 }
 
+static int hwrng_fillfn(void *unused)

drivers/char/hw_random/core.c err_misc_dereg: · line 331

Quoted 10 lines

drivers/char/hw_random/core.c renamed from drivers/char/hw_random/core.c.orig +10 -0

+{
+	long rc;
+
+	while (!kthread_should_stop()) {
+		if (!current_rng)
+			break;
+		rc = rng_get_data(current_rng, rng_fillbuf,
+				  rng_buffer_size(), 1);
+		if (rc <= 0) {
+			pr_warn("hwrng: no data available\n");

ratelimit (heavily), please.

Also, would it make sense to round-robin all hwrngs? Even better:
collect entropy from each one and add them to the pool all at once. If so, would it make sense for the derating to be a per-rng parameter. For
example, if there's a sysfs class, it could go in there.

Finally, there may be hwrngs like TPMs that are amazingly slow. What happens if the RNG is so slow that it becomes the bottleneck? Should this thing back off? Using the TPM at 100% utilization seems silly when
there's a heavy entropy consumer, especially since reading 256 bits from
the TPM once is probably just about as secure as reading from it continuously.

Also, with my quantum hat on, thanks for doing this in a way that isn't gratuitously insecure against quantum attack. 128-bit reseeds are simply too small if your adversary has a large quantum computer :)

--Andy

I'm wondering more about the default. We default to 50% for arch_get_random_seed, and this is supposed to be the default for in effect unverified hwrngs...

[cc: Greg Price, might be working on this stuff]

Quoted 1 line · H. Peter Anvin

I'm wondering more about the default. We default to 50% for

arch_get_random_seed, and this is supposed to be the default for in effect unverified hwrngs...

TBH I'm highly skeptical of this kind of entropy estimation. /dev/random is IMO just silly, since you need to have very conservative entropy estimates for the concept to really work, and that ends up being hideously slow. Also, in the /dev/random sense, most hardware RNGs have no entropy at all, since they're likely to be FIPS-approved DRBGs that don't have a real non-deterministic source.

For the kernel's RNG to be secure, I think it should have the property that it still works if you rescale all the entropy estimates by any constant that's decently close to 1.

If entropy estimates are systematically too low, then a naive implementation results in an excessively long window during early bootup in which /dev/urandom is completely insecure.

If entropy estimates are systematically too high, then a naive implementation fails to do a catastrophic reseed, and the RNG can be brute-forced.

So I think that the core code should do something along the lines of using progressively larger reseeds. Since I think that /dev/random is silly, this means that we only really care about the extent to which "entropy" measures entropy conditioned on whatever an attacker can actually compute. Since this could vary widely between devices (e.g. if your TPM is malicious), I think that the best we can do is to collect ~256 bits from everything available, shove it all in to the core together, and repeat. For all I know, the core code already does this.

The upshot is that the actual rescaling factor should barely matter. 50% is probably fine. So is 100% and 25%. 10% is probably asking for trouble during early boot if all you have is a TPM.

--Andy

TBH I'm highly skeptical of this kind of entropy estimation. /dev/random is IMO just silly, since you need to have very conservative entropy estimates for the concept to really work, and that ends up being hideously slow.

Also, in the /dev/random sense,
most hardware RNGs have no entropy at all, since they're likely to be FIPS-approved DRBGs that don't have a real non-deterministic source.

For the kernel's RNG to be secure, I think it should have the property that it still works if you rescale all the entropy estimates by any constant that's decently close to 1.

If entropy estimates are systematically too low, then a naive implementation results in an excessively long window during early bootup in which /dev/urandom is completely insecure.

If entropy estimates are systematically too high, then a naive implementation fails to do a catastrophic reseed, and the RNG can be brute-forced.

So I think that the core code should do something along the lines of using progressively larger reseeds. Since I think that /dev/random is silly, this means that we only really care about the extent to which "entropy" measures entropy conditioned on whatever an attacker can actually compute. Since this could vary widely between devices (e.g. if your TPM is malicious), I think that the best we can do is to collect ~256 bits from everything available, shove it all in to the core together, and repeat. For all I know, the core code already does this.

The upshot is that the actual rescaling factor should barely matter. 50% is probably fine. So is 100% and 25%. 10% is probably asking for trouble during early boot if all you have is a TPM.

Quoted 3 lines · Andy Lutomirski

Also, in the /dev/random sense,
most hardware RNGs have no entropy at all, since they're likely to be FIPS-approved DRBGs that don't have a real non-deterministic source.

Such a device has no business being a Linux hwrng device. We already have a PRNG (DRBG) in the kernel, the *only* purpose for a hwrng device is to be an entropy source.

TPMs, in particular, should almost certainly be massively derated based on what little we know about TPM.

Quoted 5 lines · Andy Lutomirski

TBH I'm highly skeptical of this kind of entropy estimation. /dev/random is IMO just silly, since you need to have very conservative entropy estimates for the concept to really work, and that ends up being hideously slow.

In the absence of a hardware entropy source, it is, but for long-lived keys, delay is better than bad key generation.

A major reason for entropy estimation is to control the amount of backpressure. If you don't have backpressure, you only have generation pressure, and you can't put your system to sleep when the hwrng keeps outputting data. Worse, if your entropy source is inexhaustible, you might end up spending all your CPU time processing its output.

Quoted 4 lines

Also, in the /dev/random sense,
most hardware RNGs have no entropy at all, since they're likely to be FIPS-approved DRBGs that don't have a real non-deterministic source.

Such a device has no business being a Linux hwrng device. We already have a PRNG (DRBG) in the kernel, the *only* purpose for a hwrng device is to be an entropy source.

Quoted 4 lines

For the kernel's RNG to be secure, I think it should have the property that it still works if you rescale all the entropy estimates by any constant that's decently close to 1.

That is correct.

Quoted 3 lines

If entropy estimates are systematically too low, then a naive implementation results in an excessively long window during early bootup in which /dev/urandom is completely insecure.

Eh? What mechanism would make /dev/urandom any less secure due to entropy underestimation? The whole *point* is that we should systematically underestimate entropy -- and we do, according to research papers which have analyzed the state of things we do by orders of magnitude, which is the only possible way to do it for non-hwrng sources.

Quoted 4 lines

If entropy estimates are systematically too high, then a naive implementation fails to do a catastrophic reseed, and the RNG can be brute-forced.

This again is unacceptable. We really should not overestimate.

Quoted 11 lines

So I think that the core code should do something along the lines of using progressively larger reseeds. Since I think that /dev/random is silly, this means that we only really care about the extent to which "entropy" measures entropy conditioned on whatever an attacker can actually compute. Since this could vary widely between devices (e.g. if your TPM is malicious), I think that the best we can do is to collect ~256 bits from everything available, shove it all in to the core together, and repeat. For all I know, the core code already does this.

Quoted 3 lines

The upshot is that the actual rescaling factor should barely matter. 50% is probably fine. So is 100% and 25%. 10% is probably asking for trouble during early boot if all you have is a TPM.

I don't see why small factors should be a problem at all (except that it discourages /dev/random usage.) Keep in mind we still add the entropy -- we just don't credit its existence.

TPMs, in particular, should almost certainly be massively derated based on what little we know about TPM.

As a concrete example: RDRAND is a hardware entropy source that is architecturally allowed to be diluted by a DRBG up to 512 times. As far as I know of the hardware, no shipping piece of hardware is anywhere near 512 in this aspect. rngd currently does 512:1 data reduction, but injecting the raw output at 1/512 credit ought to give a much better result in terms of entropy.

I'm wondering more about the default. We default to 50% for arch_get_random_seed, and this is supposed to be the default for in effect unverified hwrngs...

Quoted 10 lines

drivers/char/hw_random/core.c line 63

Quoted 1 line

drivers/char/hw_random/core.c renamed from drivers/char/hw_random/core.c.orig +1 -0

+		 "current hwrng entropy estimation per mill");

As an electrical engineer (sort of), I can't read this without thinking you're talking about the amount by which the current is derated. For example, a 14-50 electrical outlet is rated to 50 Amps. If you use it continuously for a long time, though, the current is derated to 40 Amps.

Shouldn't this be called credit_derating or, even better, credit_per_1000bits?

Quoted 2 lines

Also, "per mill" is just obscure enough that someone might think it means "per million".

Quoted 2 lines

Why the check for derating > 0? Paranoid users may want zero credit, but they probably still want the thing to run.

Quoted 1 line

ratelimit (heavily), please.

Quoted 3 lines

Also, would it make sense to round-robin all hwrngs? Even better:
collect entropy from each one and add them to the pool all at once. If so, would it make sense for the derating to be a per-rng parameter.

Quoted 1 line · H. Peter Anvin

I'm wondering more about the default. We default to 50% for arch_get_random_seed, and this is supposed to be the default for in effect unverified hwrngs...

If the default were 0, it would be exactly the old behaviour. How about that? Plus, driver authors would have to come up with an estimate on their own.

Quoted 9 lines · Andy Lutomirski

Quoted 8 lines

Quoted 1 line

+ "current hwrng entropy estimation per mill");

As an electrical engineer (sort of), I can't read this without thinking you're talking about the amount by which the current is derated. For example, a 14-50 electrical outlet is rated to 50 Amps. If you use it continuously for a long time, though, the current is derated to 40 Amps.

Quoted 2 lines

Quoted 2 lines

Shouldn't this be called credit_derating or, even better, credit_per_1000bits?

That's an awkward name for a parameter.

Quoted 3 lines

Quoted 3 lines

Also, "per mill" is just obscure enough that someone might think it means "per million".

No. I looked it up, as we have the precise term "Promille" in German. Also in electrical engineering, (imperial :-) PCB design, a mil is one 1000th of an inch. Per million would surely be named PPM.

Quoted 2 lines

Quoted 2 lines

Why the check for derating > 0? Paranoid users may want zero credit, but they probably still want the thing to run.

[...]

Quoted 1 line

Quoted 1 line

ratelimit (heavily), please.

The kthread will stop once the estimated entropy is above the threshold. derating=0 will wind up one CPU core to 100%. So it's an elegant way to disable the whole mechanism.

Quoted 3 lines

Quoted 3 lines

Also, would it make sense to round-robin all hwrngs? Even better:
collect entropy from each one and add them to the pool all at once. If so, would it make sense for the derating to be a per-rng parameter.

Finally, the derating _is_ a per-RNG parameter. I also thought about mixing already, but first I want to see a machine with more than 1 HWRNG :-)

I'm wondering more about the default. We default to 50% for arch_get_random_seed, and this is supposed to be the default for in effect unverified hwrngs...

This patch introduces a derating factor to struct hwrng for the random bits going into the kernel input pool, and a common default derating for drivers which do not specify one.

Signed-off-by Torsten Duwe <[email protected]>

---
 drivers/char/hw_random/core.c |   11 ++++++++++-
 include/linux/hw_random.h     |    3 +++
 2 files changed, 13 insertions(+), 1 deletion(-)

Quoted 12 lines · Torsten Duwe

This patch introduces a derating factor to struct hwrng for the random bits going into the kernel input pool, and a common default derating for drivers which do not specify one.

Signed-off-by Torsten Duwe <[email protected]>

---
 drivers/char/hw_random/core.c |   11 ++++++++++-
 include/linux/hw_random.h     |    3 +++
 2 files changed, 13 insertions(+), 1 deletion(-)

include/linux/hw_random.h line 33

Quoted 8 lines

include/linux/hw_random.h renamed from include/linux/hw_random.h.orig +2 -0

@@ -29,6 +29,8 @@
  * @read:              New API. drivers can fill up to max bytes of data
  *                     into the buffer. The buffer is aligned for any type.
  * @priv:              Private data, for use by the RNG driver.
+ * @derating:          Estimation of true entropy in RNG's bitstream
+ *                     (per mill).

I'll bikeshed again: this is a rating, not a *de*rating. Higher = more confidence, at least assuming the comment is right.

Quoted 13 lines · Andy Lutomirski

Quoted 12 lines · Torsten Duwe

This patch introduces a derating factor to struct hwrng for the random bits going into the kernel input pool, and a common default derating for drivers which do not specify one.

Signed-off-by Torsten Duwe <[email protected]>

---
 drivers/char/hw_random/core.c |   11 ++++++++++-
 include/linux/hw_random.h     |    3 +++
 2 files changed, 13 insertions(+), 1 deletion(-)

Quoted 12 lines

include/linux/hw_random.h line 33

Quoted 8 lines

include/linux/hw_random.h renamed from include/linux/hw_random.h.orig +2 -0

@@ -29,6 +29,8 @@
  * @read:              New API. drivers can fill up to max bytes of data
  *                     into the buffer. The buffer is aligned for any type.
  * @priv:              Private data, for use by the RNG driver.
+ * @derating:          Estimation of true entropy in RNG's bitstream
+ *                     (per mill).

I'll bikeshed again: this is a rating, not a *de*rating. Higher = more confidence, at least assuming the comment is right.

You're right. Would anyone object to call it "quality", as in RX signal quality? In context of a random source that is pretty accurate, I'd say. Other opinions?

Quoted 2 lines · Torsten Duwe

You're right. Would anyone object to call it "quality", as in RX signal quality? In context of a random source that is pretty accurate, I'd say. Other opinions?

I'm okay with "quality", although I'm still partial to "entropy_per_1000bits".

[checkpatch tells me not to 0-init...]

This patch introduces a derating factor to struct hwrng for the random bits going into the kernel input pool, and a common default derating for drivers which do not specify one.

Signed-off-by Torsten Duwe <[email protected]>

Quoted 8 lines · Torsten Duwe

[checkpatch tells me not to 0-init...]

This patch introduces a derating factor to struct hwrng for the random bits going into the kernel input pool, and a common default derating for drivers which do not specify one.

Signed-off-by Torsten Duwe <[email protected]>

Did we lose track of this patchset?

Quoted 2 lines

Did we lose track of this patchset?

Yes. I was already considering a resend.

Quoted 4 lines · Torsten Duwe

Quoted 2 lines

Did we lose track of this patchset?

Yes. I was already considering a resend.

I've looked it over, and I'm fairly OK with it at this point. Do folks mind if I just run it through the random tree?

I want to add a tracepoint for better debugging, but I can take care of that after it's in the random tree.

- Ted

OK, I've merged these changes into the random.git tree.

I had to make a few minor changes.

1) Changes so it would compile on 3.15. (random_write_wakeup_thresh got renamed to random_write_wakeup_bits). I'm guessing the patch was massaged so that it would apply, but it was never compile tested.

2) Fixed a bug in patch #2 so that it would work correctly if the rng driver doesn't have an init function (which happens to be the case for the tpm-rng driver, which I used for my testing).

There are also a few minor rough edges that I've noted, but not yet fixed. The main one is that if you've compiled the hw_random's rng_core into the kernel, changes to /sys/modules/rng_core/parameters/* won't actually cause the hwrngd kerenl thread to get started. You have to set the parameters before you load the rng module in order for them to be activated. And if you've compiled the rng module into the kernel, that trick won't work.

Fixing this probably means that we need to set up a formal sysfs tree under /sys/kernel/hw_random.

Quoted 3 lines

2) Fixed a bug in patch #2 so that it would work correctly if the rng driver doesn't have an init function (which happens to be the case for the tpm-rng driver, which I used for my testing).

The whole thing stems from entropy-challenged s390. 3.12 on s390 compiles and runs fine. Yields a solid 200 kB/s

TPM RNG is a crook ;-)

From my quick testing on x86 platforms, it doubles the overhead of

With patch 03/03, it is up to the driver author to specify an entropy quality, which can be overridden at boot time, or when loading the module, respectively. This should be a constant hardware property. It would be nice to change it at runtime; but frankly I hope that this won't be neccessary.

Quoted 2 lines

Fixing this probably means that we need to set up a formal sysfs tree under /sys/kernel/hw_random.

Maybe along with more sophisticated steering of how many bits to pick from which source, if multiple are available.

Quoted 8 lines · Torsten Duwe

Quoted 3 lines

2) Fixed a bug in patch #2 so that it would work correctly if the rng driver doesn't have an init function (which happens to be the case for the tpm-rng driver, which I used for my testing).

The whole thing stems from entropy-challenged s390. 3.12 on s390 compiles and runs fine. Yields a solid 200 kB/s

TPM RNG is a crook ;-)

I think the word you mean is "crock" (as in "crock of sh*t"?) :-)

Were you referring to the typical hardware implementation in most TPM's, or something else?

Quoted 5 lines

With patch 03/03, it is up to the driver author to specify an entropy quality, which can be overridden at boot time, or when loading the module, respectively. This should be a constant hardware property. It would be nice to change it at runtime; but frankly I hope that this won't be neccessary.

The question of what should be the proper derating mechanism is going to be subject to individual administrators. I agree that we should have good defaults, but for example, I'm sure the manufacturer of the TPM that's in my Thinkpad would try to claim that it's the Bug Free(tm), and try to assign it derating factor accordingly. If the

manufacturer is supplying the device driver, it may not be a value that other people will agree with. Which is why I think making it runtime configurable is a good thing.

As another example, I assume Peter or someone else from Intel will be shortly submitting a hw_random driver for RDRAND on x86. What should the derating factor be for that? I suspect David Johnson's answer would be quite different from other people's. And that's to be expected, since he has much better information that most of us have access to about the RDRAND implementation, and the likelihood/possibiliy it could have been subverted.

Quoted 2 lines

Maybe along with more sophisticated steering of how many bits to pick from which source, if multiple are available.

Yeah, the question about what to do we have multiple hw random sources is something that I thought about. Do we want to poll from more than one?

Also, suppose some hw random sources require more resources --- battery life in particular, for mobile/laptop devices? How do we deal with policy questions such as these? Should we deal with it all, or just assume that userspace will dynamically enable or disable pulling from certain devices based on policy questions such as power utilization issues?

Quoted 3 lines

Quoted 1 line

TPM RNG is a crook ;-)

I think the word you mean is "crock" (as in "crock of sh*t"?) :-)

Actually, I was thinking of a crutch. Makes you walk slowly, but better than nothing. Seems I've bent the wrong tube.

Quoted 3 lines

manufacturer is supplying the device driver, it may not be a value that other people will agree with. Which is why I think making it runtime configurable is a good thing.

Boot time configurable, I'd say. Again: this is a hardware property, multiplied by the admin's level of confidence in the absence of backdoors. It's easy with s390: from z/VM you can read all the guest's memory anyway. If you use this machine, you already trust IBM.

Also, I added the patch below to our kernel. Who wants to take that one-liner upstream?

--- linux-3.12-SLE12/drivers/s390/crypto/zcrypt_api.c.orig

+++ linux-3.12-SLE12/drivers/s390/crypto/zcrypt_api.c

At this point in time the zcrypt hw device is not registered completely in the internal zcrypt device list (ap_device_list). The crypto card itself is initialized and ready to receive and service requests, but the tasklet that retrieve the card response is not able to find the device because it's not yet in the list. Finally the response would not be received and the thread is still waiting for completion, hence the probing/registering procedure for all the other crypto devices is blocked. No further devices could be scanned, initialized and registered.
Therefore I would not recommend to trigger a hw device request before the device register process has completed.

Anyway, when the kernel thread (hwrng_fillfn) starts, it take care about the initial call to the zcrypt rng device to be triggered. Therefore I don't see any reason to manually call rng_get_data() during the registration or did I missed something?

More or less a resend of v2.

Quoted 1 line · H. Peter Anvin

I'm wondering more about the default. We default to 50% for

arch_get_random_seed, and this is supposed to be the default for in effect unverified hwrngs...

Done. 50% is now the default, that's the only change from v2.

Andy: the printk you pointed out already limits itself to 1/10s, which is half the default rate limit. Also, as Peter already wrote, we're dealing with true HWRNGs here; if such a device does not produce a single byte within 10 seconds something _is_ severely broken and, like a dying disk, worth to be logged. Here's one of the better circuits I found:
http://www.maximintegrated.com/app-notes/index.mvp/id/3469
or offline:
http://pdfserv.maximintegrated.com/en/an/AN3469.pdf
Disclaimer: I'm not endorsing Maxim, it's just that paper that hits the spot IMHO.

Anything wrong with feeding those bits into the input pool? Any other comments on the code?

Torsten

I think the default should be zero, so each hwrng driver maintainer would have to consider what guarantees that particular driver can give. If anything 50% ought to be the maximum.

Quoted 1 line · H. Peter Anvin

I think the default should be zero, so each hwrng driver maintainer would have to consider what guarantees that particular driver can give. If anything 50% ought to be the maximum.

Repost of v4 just for patch 03/03 is on its way then, defaulting to 0 (off), which happens to be the old behaviour, which I think I've also expressed my sympathy for already.

Quoted 1 line · H. Peter Anvin

I think the default should be zero, so each hwrng driver maintainer would have to consider what guarantees that particular driver can give. If anything 50% ought to be the maximum.

Repost of v4 just for patch 03/03 is on its way then, defaulting to 0 (off), which happens to be the old behaviour, which I think I've also expressed my sympathy for already.