[Resend PATCH 2/2] s390: provide hardware randomness from zcrypt card to /dev/random

[Resend PATCH 2/2] s390: provide hardware randomness from zcrypt card to /dev/random

[Torsten Duwe]

Running completely virtualised, system Z severely lacks good true random sources.
Gathering entropy in a virtual environment is difficult. To compensate, there is
specialised crypto hardware which includes a source for hardware randomness;
the zcrypt driver is able to access this random source. This patch adds a kernel
thread that feeds the random bits via the interface created with the previous patch.

Signed-off-by: Torsten Duwe <duwe@lst.de>

---
 zcrypt_api.c |   51 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)
--- a/drivers/s390/crypto/zcrypt_api.c
+++ b/drivers/s390/crypto/zcrypt_api.c
@@ -38,6 +38,8 @@
 #include <linux/atomic.h>
 #include <asm/uaccess.h>
 #include <linux/hw_random.h>
+#include <linux/kthread.h>
+#include <linux/delay.h>
 #include <linux/debugfs.h>
 #include <asm/debug.h>
 
@@ -99,6 +99,13 @@ static ssize_t zcrypt_online_store(struc
 
 	if (sscanf(buf, "%d\n", &online) != 1 || online < 0 || online > 1)
 		return -EINVAL;
+	if (zdev->ops->rng) {
+		if (zdev->online == 0 && online == 1)
+			zcrypt_rng_device_add();
+		if (zdev->online == 1 && online == 0)
+			zcrypt_rng_device_remove();
+
+	}
 	zdev->online = online;
 	ZCRYPT_DBF_DEV(DBF_INFO, zdev, "dev%04xo%dman", zdev->ap_dev->qid,
 		       zdev->online);
@@ -1117,6 +1119,7 @@ static int zcrypt_rng_device_count;
 static u32 *zcrypt_rng_buffer;
 static int zcrypt_rng_buffer_index;
 static DEFINE_MUTEX(zcrypt_rng_mutex);
+static struct task_struct *zcrypt_hwrng_fill;
 
 static int zcrypt_rng_data_read(struct hwrng *rng, u32 *data)
 {
@@ -1141,6 +1144,36 @@ static struct hwrng zcrypt_rng_dev = {
 	.data_read	= zcrypt_rng_data_read,
 };
 
+static int zcrypt_hwrng_fillfn(void *unused)
+{
+	long rc;
+
+	while (!kthread_should_stop()) {
+		rc = zcrypt_rng((char *)zcrypt_rng_buffer);
+		if (rc == -ENODEV || rc == -EINVAL || rc == -ENOMEM) {
+			pr_err("zcrypt_rng unavailable: %ld\n", rc);
+			break;
+		}
+		if (rc == -EAGAIN || rc == -ERESTARTSYS) {
+			pr_info("zcrypt_rng interrupted: %ld\n", rc);
+			msleep_interruptible(1000);
+			continue;
+		}
+		if (rc == 0) {
+			pr_err("zcrypt_rng: no data available\n");
+			msleep_interruptible(10000);
+			continue;
+		}
+		if (rc < 0) {
+			pr_err("zcrypt_rng unknown error: %ld\n", rc);
+			break;
+		}
+		add_hwgenerator_randomness((void *)zcrypt_rng_buffer, rc);
+	}
+	zcrypt_hwrng_fill = 0;
+	return 0;
+}
+
 static int zcrypt_rng_device_add(void)
 {
 	int rc = 0;
@@ -1157,6 +1189,12 @@ static int zcrypt_rng_device_add(void)
 		if (rc)
 			goto out_free;
 		zcrypt_rng_device_count = 1;
+		zcrypt_hwrng_fill = kthread_run(zcrypt_hwrng_fillfn,
+			NULL, "zc_hwrng");
+		if (zcrypt_hwrng_fill == ERR_PTR(-ENOMEM)) {
+			pr_err("zcrypt_hwrng_fill thread creation failed\n");
+			zcrypt_hwrng_fill = 0;
+		}
 	} else
 		zcrypt_rng_device_count++;
 	mutex_unlock(&zcrypt_rng_mutex);
@@ -1174,6 +1211,10 @@ static void zcrypt_rng_device_remove(voi
 	mutex_lock(&zcrypt_rng_mutex);
 	zcrypt_rng_device_count--;
 	if (zcrypt_rng_device_count == 0) {
+		if (zcrypt_hwrng_fill) {
+			kthread_stop(zcrypt_hwrng_fill);
+			zcrypt_hwrng_fill = 0;
+		}
 		hwrng_unregister(&zcrypt_rng_dev);
 		free_page((unsigned long) zcrypt_rng_buffer);
 	}

Re: [Resend PATCH 2/2] s390: provide hardware randomness from zcrypt card to /dev/random

[H. Peter Anvin]

On 09/12/2013 02:41 AM, Torsten Duwe wrote:
> 
> Running completely virtualised, system Z severely lacks good true random sources.
> Gathering entropy in a virtual environment is difficult. To compensate, there is
> specialised crypto hardware which includes a source for hardware randomness;
> the zcrypt driver is able to access this random source. This patch adds a kernel
> thread that feeds the random bits via the interface created with the previous patch.
> 
> Signed-off-by: Torsten Duwe <duwe@lst.de>

>From what I can gather from the patch this is too heavyweight (need
locks and so on) to use as arch_get_random*().  There has been a lot of
discussion about the pros and cons of allowing the kernel to bypass
rngd, but I would think that any such plumbing -- once it gets past the
fully synchronous low latency properties of arch_get_random*() -- really
should be implemented as an option in the existing hwrng device
infrastructure.

In other words, start by implementing a hwrng device.  That will work
right now with rngd running.  Then we can consider if we want to allow
bypass of rngd for certain hwrng devices -- which may include zcrypt,
virtio_rng and so on.

	-hpa

Re: [Resend PATCH 2/2] s390: provide hardware randomness from zcrypt card to /dev/random

[Torsten Duwe]

On Thu, 12 Sep 2013, H. Peter Anvin wrote:

> From what I can gather from the patch this is too heavyweight (need
> locks and so on) to use as arch_get_random*().  There has been a lot of

Alas, I can see there's only x86 that currently has this implemented?

> discussion about the pros and cons of allowing the kernel to bypass
> rngd, but I would think that any such plumbing -- once it gets past the
> fully synchronous low latency properties of arch_get_random*() -- really
> should be implemented as an option in the existing hwrng device
> infrastructure.

As I wrote in the intro, the problem to solve is slow startup when ASLR is 
in effect; in that case: until rngd or haveged is finally running.

> In other words, start by implementing a hwrng device.  That will work
> right now with rngd running.  Then we can consider if we want to allow

That's already there, thanks to the IBM guys :)

> bypass of rngd for certain hwrng devices -- which may include zcrypt,
> virtio_rng and so on.

I'm currently thinking about some kind of buffer in zcrypt, where 
arch_get_random can get a long or int quickly, as "designed" after x86.
Device init or low water would trigger a work item to refill the buffer.
It might tun out though, that every device on every architecture that does
not quite match the x86 approach implements its own buffer.

What do you think?

Besides that, as you wrote, a generic mechanism to mix hwrngs into the 
input pool would be nice, triggered by user space policy. As far as I can 
see, some mixing of arch_get_random is done, but no entropy credited?

	Torsten

Re: [Resend PATCH 2/2] s390: provide hardware randomness from zcrypt card to /dev/random

[H. Peter Anvin]

By the way, haveged is... worthy of suspicion (I doubt it is malicious, but still).  Its self-tests are completely useless (replace the entropy source with a constant "1" and they still pass) and there is as far as I know no analysis about the randomness other than "it passes some tests."



Torsten Duwe <duwe@lst.de> wrote:
>
>
>On Thu, 12 Sep 2013, H. Peter Anvin wrote:
>
>> From what I can gather from the patch this is too heavyweight (need
>> locks and so on) to use as arch_get_random*().  There has been a lot
>of
>
>Alas, I can see there's only x86 that currently has this implemented?
>
>> discussion about the pros and cons of allowing the kernel to bypass
>> rngd, but I would think that any such plumbing -- once it gets past
>the
>> fully synchronous low latency properties of arch_get_random*() --
>really
>> should be implemented as an option in the existing hwrng device
>> infrastructure.
>
>As I wrote in the intro, the problem to solve is slow startup when ASLR
>is 
>in effect; in that case: until rngd or haveged is finally running.
>
>> In other words, start by implementing a hwrng device.  That will work
>> right now with rngd running.  Then we can consider if we want to
>allow
>
>That's already there, thanks to the IBM guys :)
>
>> bypass of rngd for certain hwrng devices -- which may include zcrypt,
>> virtio_rng and so on.
>
>I'm currently thinking about some kind of buffer in zcrypt, where 
>arch_get_random can get a long or int quickly, as "designed" after x86.
>Device init or low water would trigger a work item to refill the
>buffer.
>It might tun out though, that every device on every architecture that
>does
>not quite match the x86 approach implements its own buffer.
>
>What do you think?
>
>Besides that, as you wrote, a generic mechanism to mix hwrngs into the 
>input pool would be nice, triggered by user space policy. As far as I
>can 
>see, some mixing of arch_get_random is done, but no entropy credited?
>
>	Torsten

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.

Re: [Resend PATCH 2/2] s390: provide hardware randomness from zcrypt card to /dev/random

[H. Peter Anvin]

As I said, the option of doing feed from hwrng directly via a kernel thread seems the most logical thing to me, assuming you can convince Ted & co.  rngd doesn't really add much value for a whitened source.

Torsten Duwe <duwe@lst.de> wrote:
>
>
>On Thu, 12 Sep 2013, H. Peter Anvin wrote:
>
>> From what I can gather from the patch this is too heavyweight (need
>> locks and so on) to use as arch_get_random*().  There has been a lot
>of
>
>Alas, I can see there's only x86 that currently has this implemented?
>
>> discussion about the pros and cons of allowing the kernel to bypass
>> rngd, but I would think that any such plumbing -- once it gets past
>the
>> fully synchronous low latency properties of arch_get_random*() --
>really
>> should be implemented as an option in the existing hwrng device
>> infrastructure.
>
>As I wrote in the intro, the problem to solve is slow startup when ASLR
>is 
>in effect; in that case: until rngd or haveged is finally running.
>
>> In other words, start by implementing a hwrng device.  That will work
>> right now with rngd running.  Then we can consider if we want to
>allow
>
>That's already there, thanks to the IBM guys :)
>
>> bypass of rngd for certain hwrng devices -- which may include zcrypt,
>> virtio_rng and so on.
>
>I'm currently thinking about some kind of buffer in zcrypt, where 
>arch_get_random can get a long or int quickly, as "designed" after x86.
>Device init or low water would trigger a work item to refill the
>buffer.
>It might tun out though, that every device on every architecture that
>does
>not quite match the x86 approach implements its own buffer.
>
>What do you think?
>
>Besides that, as you wrote, a generic mechanism to mix hwrngs into the 
>input pool would be nice, triggered by user space policy. As far as I
>can 
>see, some mixing of arch_get_random is done, but no entropy credited?
>
>	Torsten

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.

[PATCH 00/03]: khwrngd (Was: s390: provide hardware randomness from zcrypt card to /dev/random)

[Torsten Duwe]

On Thu, Sep 19, 2013 at 08:05:32AM -0500, H. Peter Anvin wrote:
> As I said, the option of doing feed from hwrng directly
> via a kernel thread seems the most logical thing to me,
> assuming you can convince Ted & co.
> rngd doesn't really add much value for a whitened source.

Following up on this on (time flies!) I have moved the code
up into the arch-independent hw_random code and split it into 3
patches. First generate the injection point for true HWRNGs,
then create a thread that makes use of it and finally add
some simple on/off switch. The latter could be replaced with
something far more sophisticated if desired.

	Torsten

[Patch 01/03]: provide an injection point for pure hardware randomness

[Torsten Duwe]

This patch adds an interface to the random pool for feeding entropy in-kernel.
It may serve as a destination for dedicated HWRNGs.

It resembles -- and could be merged with -- the ioctl(RNDADDENTROPY) code, plus 
a sleep condition for eager writers.

Signed-off-by: Torsten Duwe <duwe@suse.de>

---
 include/linux/hw_random.h |    2 ++
 drivers/char/random.c     |   23 +++++++++++++++++++++++
 2 files changed, 25 insertions(+)

--- a/include/linux/hw_random.h
+++ b/include/linux/hw_random.h
@@ -47,5 +47,7 @@ struct hwrng {
 extern int hwrng_register(struct hwrng *rng);
 /** Unregister a Hardware Random Number Generator driver. */
 extern void hwrng_unregister(struct hwrng *rng);
+/** Feed random bits into the pool. */
+extern void add_hwgenerator_randomness(const char *buffer, size_t count, size_t entropy);
 
 #endif /* LINUX_HWRANDOM_H_ */
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -250,6 +250,7 @@
 #include <linux/interrupt.h>
 #include <linux/mm.h>
 #include <linux/spinlock.h>
+#include <linux/kthread.h>
 #include <linux/percpu.h>
 #include <linux/cryptohash.h>
 #include <linux/fips.h>
@@ -1347,3 +1347,25 @@ randomize_range(unsigned long start, uns
 		return 0;
 	return PAGE_ALIGN(get_random_int() % range + start);
 }
+
+/* Interface for in-kernel drivers of true hardware RNGs.
+ * Those devices may produce endless random bits and will be throttled
+ * when our pool is full.
+ */
+void add_hwgenerator_randomness(const char *buffer, size_t count,
+				 size_t entropy)
+{
+	struct entropy_store *poolp = &input_pool;
+
+	/* Suspend writing if we're above the trickle threshold.
+	 * We'll be woken up again once below random_write_wakeup_thresh,
+	 * or when the calling thread is about to terminate.
+	 */
+	wait_event_interruptible(random_write_wait, kthread_should_stop() ||
+				 input_pool.entropy_count
+					 <= random_write_wakeup_thresh);
+	mix_pool_bytes(poolp, buffer, count, NULL);
+	credit_entropy_bits(poolp, entropy);
+}
+EXPORT_SYMBOL_GPL(add_hwgenerator_randomness);
+