* [PATCH v3 01/03]: hwrng: provide an injection point for pure hardware randomness
2014-04-14 16:02 ` [PATCH v3 00/03]: hwrng: an in-kernel rngd Torsten Duwe
@ 2014-04-14 16:04 ` Torsten Duwe
2014-04-14 16:05 ` [PATCH v3 02/03]: hwrng: create filler thread Torsten Duwe
` (2 subsequent siblings)
3 siblings, 0 replies; 41+ messages in thread
From: Torsten Duwe @ 2014-04-14 16:04 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Andy Lutomirski, Theodore Ts'o, Greg Kroah-Hartman,
Andrew Morton, Matt Mackall, Herbert Xu, Arnd Bergmann,
Rusty Russell, Satoru Takeuchi, ingo.tuchscherer, linux-kernel,
Hans-Georg Markgraf, Gerald Schaefer, Martin Schwidefsky,
Heiko Carstens, Joe Perches
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);
+
^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH v3 02/03]: hwrng: create filler thread
2014-04-14 16:02 ` [PATCH v3 00/03]: hwrng: an in-kernel rngd Torsten Duwe
2014-04-14 16:04 ` [PATCH v3 01/03]: hwrng: provide an injection point for pure hardware randomness Torsten Duwe
@ 2014-04-14 16:05 ` Torsten Duwe
2014-04-14 16:06 ` [PATCH v3 03/03]: hwrng: khwrngd derating per device Torsten Duwe
2014-04-14 16:09 ` [PATCH v3 00/03]: hwrng: an in-kernel rngd H. Peter Anvin
3 siblings, 0 replies; 41+ messages in thread
From: Torsten Duwe @ 2014-04-14 16:05 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Andy Lutomirski, Theodore Ts'o, Greg Kroah-Hartman,
Andrew Morton, Matt Mackall, Herbert Xu, Arnd Bergmann,
Rusty Russell, Satoru Takeuchi, ingo.tuchscherer, linux-kernel,
Hans-Georg Markgraf, Gerald Schaefer, Martin Schwidefsky,
Heiko Carstens, Joe Perches
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.
This patch creates a thread once a hwrng registers, and uses
the previously established add_hwgenerator_randomness() to feed
its data to the input pool as long as needed. A derating factor
is used to bias the entropy estimation and to disable this
mechanism entirely when set to zero.
Signed-off-by: Torsten Duwe <duwe@suse.de>
---
drivers/char/hw_random/core.c | 65 ++++++++++++++++++++++++++++++++++++++++--
1 file changed, 62 insertions(+), 3 deletions(-)
--- linux/drivers/char/hw_random/core.c.orig
+++ linux/drivers/char/hw_random/core.c
@@ -39,6 +39,7 @@
#include <linux/sched.h>
#include <linux/init.h>
#include <linux/miscdevice.h>
+#include <linux/kthread.h>
#include <linux/delay.h>
#include <linux/slab.h>
#include <asm/uaccess.h>
@@ -50,10 +51,18 @@
static struct hwrng *current_rng;
+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");
+
+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;
+
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();
+
+ 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)
+{
+ 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");
+ msleep_interruptible(10000);
+ continue;
+ }
+ add_hwgenerator_randomness((void *)rng_fillbuf, rc,
+ (rc*derating_current)>>10);
+ }
+ hwrng_fill = 0;
+ return 0;
+}
+
+static void start_khwrngd(void)
+{
+ hwrng_fill = kthread_run(hwrng_fillfn, NULL, "hwrng");
+ if (hwrng_fill == ERR_PTR(-ENOMEM)) {
+ pr_err("hwrng_fill thread creation failed");
+ hwrng_fill = NULL;
+ }
+}
+
int hwrng_register(struct hwrng *rng)
{
int must_register_misc;
@@ -319,6 +367,13 @@ int hwrng_register(struct hwrng *rng)
if (!rng_buffer)
goto out_unlock;
}
+ if (!rng_fillbuf) {
+ rng_fillbuf = kmalloc(rng_buffer_size(), GFP_KERNEL);
+ if (!rng_fillbuf) {
+ kfree(rng_buffer);
+ goto out_unlock;
+ }
+ }
/* Must not register two RNGs with the same name. */
err = -EEXIST;
@@ -373,8 +428,11 @@ void hwrng_unregister(struct hwrng *rng)
current_rng = NULL;
}
}
- if (list_empty(&rng_list))
+ if (list_empty(&rng_list)) {
unregister_miscdev();
+ if (hwrng_fill)
+ kthread_stop(hwrng_fill);
+ }
mutex_unlock(&rng_mutex);
}
@@ -385,6 +443,7 @@ static void __exit hwrng_exit(void)
mutex_lock(&rng_mutex);
BUG_ON(current_rng);
kfree(rng_buffer);
+ kfree(rng_fillbuf);
mutex_unlock(&rng_mutex);
}
^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH v3 03/03]: hwrng: khwrngd derating per device
2014-04-14 16:02 ` [PATCH v3 00/03]: hwrng: an in-kernel rngd Torsten Duwe
2014-04-14 16:04 ` [PATCH v3 01/03]: hwrng: provide an injection point for pure hardware randomness Torsten Duwe
2014-04-14 16:05 ` [PATCH v3 02/03]: hwrng: create filler thread Torsten Duwe
@ 2014-04-14 16:06 ` Torsten Duwe
2014-04-14 16:41 ` Andy Lutomirski
2014-04-14 16:09 ` [PATCH v3 00/03]: hwrng: an in-kernel rngd H. Peter Anvin
3 siblings, 1 reply; 41+ messages in thread
From: Torsten Duwe @ 2014-04-14 16:06 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Andy Lutomirski, Theodore Ts'o, Greg Kroah-Hartman,
Andrew Morton, Matt Mackall, Herbert Xu, Arnd Bergmann,
Rusty Russell, Satoru Takeuchi, ingo.tuchscherer, linux-kernel,
Hans-Georg Markgraf, Gerald Schaefer, Martin Schwidefsky,
Heiko Carstens, Joe Perches
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 <duwe@suse.de>
---
drivers/char/hw_random/core.c | 11 ++++++++++-
include/linux/hw_random.h | 3 +++
2 files changed, 13 insertions(+), 1 deletion(-)
--- linux/include/linux/hw_random.h.orig
+++ linux/include/linux/hw_random.h
@@ -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).
*/
struct hwrng {
const char *name;
@@ -38,6 +39,7 @@ struct hwrng {
int (*data_read)(struct hwrng *rng, u32 *data);
int (*read)(struct hwrng *rng, void *data, size_t max, bool wait);
unsigned long priv;
+ unsigned short derating;
/* internal. */
struct list_head list;
--- linux/drivers/char/hw_random/core.c.orig
+++ linux/drivers/char/hw_random/core.c
@@ -56,11 +56,15 @@ static LIST_HEAD(rng_list);
static DEFINE_MUTEX(rng_mutex);
static int data_avail;
static u8 *rng_buffer, *rng_fillbuf;
-static unsigned short derating_current = 700; /* an arbitrary 70% */
+static unsigned short derating_current;
+static unsigned short derating_default = 500; /* an arbitrary 50% */
module_param(derating_current, ushort, 0644);
MODULE_PARM_DESC(derating_current,
"current hwrng entropy estimation per mill");
+module_param(derating_default, ushort, 0644);
+MODULE_PARM_DESC(derating_default,
+ "default entropy content of hwrng per mill");
static void start_khwrngd(void);
@@ -79,6 +83,11 @@ static inline int hwrng_init(struct hwrn
if (err)
return err;
+ derating_current = rng->derating ? : derating_default;
+ derating_current &= 1023;
+
+ if (derating_current == 0 && hwrng_fill)
+ kthread_stop(hwrng_fill);
if (derating_current > 0 && !hwrng_fill)
start_khwrngd();
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH v3 03/03]: hwrng: khwrngd derating per device
2014-04-14 16:06 ` [PATCH v3 03/03]: hwrng: khwrngd derating per device Torsten Duwe
@ 2014-04-14 16:41 ` Andy Lutomirski
2014-04-15 8:51 ` Torsten Duwe
0 siblings, 1 reply; 41+ messages in thread
From: Andy Lutomirski @ 2014-04-14 16:41 UTC (permalink / raw)
To: Torsten Duwe
Cc: H. Peter Anvin, Theodore Ts'o, Greg Kroah-Hartman,
Andrew Morton, Matt Mackall, Herbert Xu, Arnd Bergmann,
Rusty Russell, Satoru Takeuchi, ingo.tuchscherer, linux-kernel,
Hans-Georg Markgraf, Gerald Schaefer, Martin Schwidefsky,
Heiko Carstens, Joe Perches
On Mon, Apr 14, 2014 at 9:06 AM, Torsten Duwe <duwe@lst.de> wrote:
>
> 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 <duwe@suse.de>
>
> ---
> drivers/char/hw_random/core.c | 11 ++++++++++-
> include/linux/hw_random.h | 3 +++
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> --- linux/include/linux/hw_random.h.orig
> +++ linux/include/linux/hw_random.h
> @@ -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.
--Andy
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH v3 03/03]: hwrng: khwrngd derating per device
2014-04-14 16:41 ` Andy Lutomirski
@ 2014-04-15 8:51 ` Torsten Duwe
2014-04-15 16:53 ` Andy Lutomirski
0 siblings, 1 reply; 41+ messages in thread
From: Torsten Duwe @ 2014-04-15 8:51 UTC (permalink / raw)
To: Andy Lutomirski
Cc: H. Peter Anvin, Theodore Ts'o, Greg Kroah-Hartman,
Andrew Morton, Matt Mackall, Herbert Xu, Arnd Bergmann,
Rusty Russell, Satoru Takeuchi, ingo.tuchscherer, linux-kernel,
Hans-Georg Markgraf, Gerald Schaefer, Martin Schwidefsky,
Heiko Carstens, Joe Perches
On Mon, Apr 14, 2014 at 09:41:10AM -0700, Andy Lutomirski wrote:
> On Mon, Apr 14, 2014 at 9:06 AM, Torsten Duwe <duwe@lst.de> wrote:
> >
> > 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 <duwe@suse.de>
> >
> > ---
> > drivers/char/hw_random/core.c | 11 ++++++++++-
> > include/linux/hw_random.h | 3 +++
> > 2 files changed, 13 insertions(+), 1 deletion(-)
> >
> > --- linux/include/linux/hw_random.h.orig
> > +++ linux/include/linux/hw_random.h
> > @@ -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?
Torsten
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH v3 03/03]: hwrng: khwrngd derating per device
2014-04-15 8:51 ` Torsten Duwe
@ 2014-04-15 16:53 ` Andy Lutomirski
2014-05-27 13:41 ` [PATCH v5 00/03]: hwrng: an in-kernel rngd Torsten Duwe
0 siblings, 1 reply; 41+ messages in thread
From: Andy Lutomirski @ 2014-04-15 16:53 UTC (permalink / raw)
To: Torsten Duwe
Cc: H. Peter Anvin, Theodore Ts'o, Greg Kroah-Hartman,
Andrew Morton, Matt Mackall, Herbert Xu, Arnd Bergmann,
Rusty Russell, Satoru Takeuchi, ingo.tuchscherer, linux-kernel,
Hans-Georg Markgraf, Gerald Schaefer, Martin Schwidefsky,
Heiko Carstens, Joe Perches
On Tue, Apr 15, 2014 at 1:51 AM, Torsten Duwe <duwe@lst.de> wrote:
> On Mon, Apr 14, 2014 at 09:41:10AM -0700, Andy Lutomirski wrote:
>> On Mon, Apr 14, 2014 at 9:06 AM, Torsten Duwe <duwe@lst.de> wrote:
>> >
>> > 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 <duwe@suse.de>
>> >
>> > ---
>> > drivers/char/hw_random/core.c | 11 ++++++++++-
>> > include/linux/hw_random.h | 3 +++
>> > 2 files changed, 13 insertions(+), 1 deletion(-)
>> >
>> > --- linux/include/linux/hw_random.h.orig
>> > +++ linux/include/linux/hw_random.h
>> > @@ -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?
I'm okay with "quality", although I'm still partial to "entropy_per_1000bits".
--Andy
^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH v5 00/03]: hwrng: an in-kernel rngd
2014-04-15 16:53 ` Andy Lutomirski
@ 2014-05-27 13:41 ` Torsten Duwe
2014-05-27 13:44 ` [Patch 01/03]: provide an injection point for pure hardware randomness Torsten Duwe
` (2 more replies)
0 siblings, 3 replies; 41+ messages in thread
From: Torsten Duwe @ 2014-05-27 13:41 UTC (permalink / raw)
To: Andy Lutomirski
Cc: H. Peter Anvin, Theodore Ts'o, Greg Kroah-Hartman,
Andrew Morton, Matt Mackall, Herbert Xu, Arnd Bergmann,
Rusty Russell, Satoru Takeuchi, ingo.tuchscherer, linux-kernel,
Hans-Georg Markgraf, Gerald Schaefer, Martin Schwidefsky,
Heiko Carstens, Joe Perches
On Tue, Apr 15, 2014 at 09:53:53AM -0700, Andy Lutomirski wrote:
> On Tue, Apr 15, 2014 at 1:51 AM, Torsten Duwe <duwe@lst.de> wrote:
> > 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".
So, since there were no other comments, here's v5 with aforementioned change.
Default is still "off". Patch 02/03 de-fuzzed for 3.15.
Torsten
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Patch 01/03]: provide an injection point for pure hardware randomness
2014-05-27 13:41 ` [PATCH v5 00/03]: hwrng: an in-kernel rngd Torsten Duwe
@ 2014-05-27 13:44 ` Torsten Duwe
2014-05-27 13:45 ` [Patch v5 02/03]: hwrng: create filler thread Torsten Duwe
2014-05-27 13:46 ` [Patch v5 03/03]: hwrng: khwrngd derating per device Torsten Duwe
2 siblings, 0 replies; 41+ messages in thread
From: Torsten Duwe @ 2014-05-27 13:44 UTC (permalink / raw)
To: Andy Lutomirski
Cc: H. Peter Anvin, Theodore Ts'o, Greg Kroah-Hartman,
Andrew Morton, Matt Mackall, Herbert Xu, Arnd Bergmann,
Rusty Russell, Satoru Takeuchi, ingo.tuchscherer, linux-kernel,
Hans-Georg Markgraf, Gerald Schaefer, Martin Schwidefsky,
Heiko Carstens, Joe Perches
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);
+
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Patch v5 02/03]: hwrng: create filler thread
2014-05-27 13:41 ` [PATCH v5 00/03]: hwrng: an in-kernel rngd Torsten Duwe
2014-05-27 13:44 ` [Patch 01/03]: provide an injection point for pure hardware randomness Torsten Duwe
@ 2014-05-27 13:45 ` Torsten Duwe
2014-05-27 13:46 ` [Patch v5 03/03]: hwrng: khwrngd derating per device Torsten Duwe
2 siblings, 0 replies; 41+ messages in thread
From: Torsten Duwe @ 2014-05-27 13:45 UTC (permalink / raw)
To: Andy Lutomirski
Cc: H. Peter Anvin, Theodore Ts'o, Greg Kroah-Hartman,
Andrew Morton, Matt Mackall, Herbert Xu, Arnd Bergmann,
Rusty Russell, Satoru Takeuchi, ingo.tuchscherer, linux-kernel,
Hans-Georg Markgraf, Gerald Schaefer, Martin Schwidefsky,
Heiko Carstens, Joe Perches
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.
This patch creates a thread once a hwrng registers, and uses
the previously established add_hwgenerator_randomness() to feed
its data to the input pool as long as needed. A derating factor
is used to bias the entropy estimation and to disable this
mechanism entirely when set to zero.
Signed-off-by: Torsten Duwe <duwe@suse.de>
---
drivers/char/hw_random/core.c | 65 ++++++++++++++++++++++++++++++++++++++++--
1 file changed, 62 insertions(+), 3 deletions(-)
--- linux/drivers/char/hw_random/core.c.orig
+++ linux/drivers/char/hw_random/core.c
@@ -39,6 +39,7 @@
#include <linux/fs.h>
#include <linux/sched.h>
#include <linux/miscdevice.h>
+#include <linux/kthread.h>
#include <linux/delay.h>
#include <linux/slab.h>
#include <linux/random.h>
@@ -50,10 +51,18 @@
static struct hwrng *current_rng;
+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 current_quality = 700; /* an arbitrary 70% */
+
+module_param(current_quality, ushort, 0644);
+MODULE_PARM_DESC(current_quality,
+ "current hwrng entropy estimation per mill");
+
+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;
+
if (!rng->init)
return 0;
- return rng->init(rng);
+ err = rng->init(rng);
+ if (err)
+ return err;
+
+ if (current_quality > 0 && !hwrng_fill)
+ start_khwrngd();
+
+ 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)
+{
+ 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");
+ msleep_interruptible(10000);
+ continue;
+ }
+ add_hwgenerator_randomness((void *)rng_fillbuf, rc,
+ (rc*current_quality)>>10);
+ }
+ hwrng_fill = 0;
+ return 0;
+}
+
+static void start_khwrngd(void)
+{
+ hwrng_fill = kthread_run(hwrng_fillfn, NULL, "hwrng");
+ if (hwrng_fill == ERR_PTR(-ENOMEM)) {
+ pr_err("hwrng_fill thread creation failed");
+ hwrng_fill = NULL;
+ }
+}
+
int hwrng_register(struct hwrng *rng)
{
int err = -EINVAL;
@@ -319,6 +367,13 @@ int hwrng_register(struct hwrng *rng)
if (!rng_buffer)
goto out_unlock;
}
+ if (!rng_fillbuf) {
+ rng_fillbuf = kmalloc(rng_buffer_size(), GFP_KERNEL);
+ if (!rng_fillbuf) {
+ kfree(rng_buffer);
+ goto out_unlock;
+ }
+ }
/* Must not register two RNGs with the same name. */
err = -EEXIST;
@@ -373,8 +428,11 @@ void hwrng_unregister(struct hwrng *rng)
current_rng = NULL;
}
}
- if (list_empty(&rng_list))
+ if (list_empty(&rng_list)) {
unregister_miscdev();
+ if (hwrng_fill)
+ kthread_stop(hwrng_fill);
+ }
mutex_unlock(&rng_mutex);
}
@@ -385,6 +443,7 @@ static void __exit hwrng_exit(void)
mutex_lock(&rng_mutex);
BUG_ON(current_rng);
kfree(rng_buffer);
+ kfree(rng_fillbuf);
mutex_unlock(&rng_mutex);
}
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Patch v5 03/03]: hwrng: khwrngd derating per device
2014-05-27 13:41 ` [PATCH v5 00/03]: hwrng: an in-kernel rngd Torsten Duwe
2014-05-27 13:44 ` [Patch 01/03]: provide an injection point for pure hardware randomness Torsten Duwe
2014-05-27 13:45 ` [Patch v5 02/03]: hwrng: create filler thread Torsten Duwe
@ 2014-05-27 13:46 ` Torsten Duwe
2014-05-27 14:11 ` [Patch v5.1 " Torsten Duwe
2 siblings, 1 reply; 41+ messages in thread
From: Torsten Duwe @ 2014-05-27 13:46 UTC (permalink / raw)
To: Andy Lutomirski
Cc: H. Peter Anvin, Theodore Ts'o, Greg Kroah-Hartman,
Andrew Morton, Matt Mackall, Herbert Xu, Arnd Bergmann,
Rusty Russell, Satoru Takeuchi, ingo.tuchscherer, linux-kernel,
Hans-Georg Markgraf, Gerald Schaefer, Martin Schwidefsky,
Heiko Carstens, Joe Perches
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 <duwe@suse.de>
---
drivers/char/hw_random/core.c | 11 ++++++++++-
include/linux/hw_random.h | 3 +++
2 files changed, 13 insertions(+), 1 deletion(-)
--- linux/include/linux/hw_random.h.orig
+++ linux/include/linux/hw_random.h
@@ -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.
+ * @quality: Estimation of true entropy in RNG's bitstream
+ * (per mill).
*/
struct hwrng {
const char *name;
@@ -38,6 +39,7 @@ struct hwrng {
int (*data_read)(struct hwrng *rng, u32 *data);
int (*read)(struct hwrng *rng, void *data, size_t max, bool wait);
unsigned long priv;
+ unsigned short quality;
/* internal. */
struct list_head list;
--- linux/drivers/char/hw_random/core.c.orig
+++ linux/drivers/char/hw_random/core.c
@@ -56,11 +56,15 @@ static LIST_HEAD(rng_list);
static DEFINE_MUTEX(rng_mutex);
static int data_avail;
static u8 *rng_buffer, *rng_fillbuf;
-static unsigned short current_quality = 700; /* an arbitrary 70% */
+static unsigned short current_quality;
+static unsigned short default_quality = 0; /* default to "off" */
module_param(current_quality, ushort, 0644);
MODULE_PARM_DESC(current_quality,
"current hwrng entropy estimation per mill");
+module_param(default_quality, ushort, 0644);
+MODULE_PARM_DESC(default_quality,
+ "default entropy content of hwrng per mill");
static void start_khwrngd(void);
@@ -79,6 +83,11 @@ static inline int hwrng_init(struct hwrn
if (err)
return err;
+ current_quality = rng->quality ? : default_quality;
+ current_quality &= 1023;
+
+ if (current_quality == 0 && hwrng_fill)
+ kthread_stop(hwrng_fill);
if (current_quality > 0 && !hwrng_fill)
start_khwrngd();
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Patch v5.1 03/03]: hwrng: khwrngd derating per device
2014-05-27 13:46 ` [Patch v5 03/03]: hwrng: khwrngd derating per device Torsten Duwe
@ 2014-05-27 14:11 ` Torsten Duwe
2014-06-12 1:24 ` H. Peter Anvin
0 siblings, 1 reply; 41+ messages in thread
From: Torsten Duwe @ 2014-05-27 14:11 UTC (permalink / raw)
To: Andy Lutomirski
Cc: H. Peter Anvin, Theodore Ts'o, Greg Kroah-Hartman,
Andrew Morton, Matt Mackall, Herbert Xu, Arnd Bergmann,
Rusty Russell, Satoru Takeuchi, ingo.tuchscherer, linux-kernel,
Hans-Georg Markgraf, Gerald Schaefer, Martin Schwidefsky,
Heiko Carstens, Joe Perches
[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 <duwe@suse.de>
---
drivers/char/hw_random/core.c | 11 ++++++++++-
include/linux/hw_random.h | 3 +++
2 files changed, 13 insertions(+), 1 deletion(-)
--- linux/include/linux/hw_random.h.orig
+++ linux/include/linux/hw_random.h
@@ -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.
+ * @quality: Estimation of true entropy in RNG's bitstream
+ * (per mill).
*/
struct hwrng {
const char *name;
@@ -38,6 +39,7 @@ struct hwrng {
int (*data_read)(struct hwrng *rng, u32 *data);
int (*read)(struct hwrng *rng, void *data, size_t max, bool wait);
unsigned long priv;
+ unsigned short quality;
/* internal. */
struct list_head list;
--- linux/drivers/char/hw_random/core.c.orig
+++ linux/drivers/char/hw_random/core.c
@@ -56,11 +56,15 @@ static LIST_HEAD(rng_list);
static DEFINE_MUTEX(rng_mutex);
static int data_avail;
static u8 *rng_buffer, *rng_fillbuf;
-static unsigned short current_quality = 700; /* an arbitrary 70% */
+static unsigned short current_quality;
+static unsigned short default_quality; /* = 0; default to "off" */
module_param(current_quality, ushort, 0644);
MODULE_PARM_DESC(current_quality,
"current hwrng entropy estimation per mill");
+module_param(default_quality, ushort, 0644);
+MODULE_PARM_DESC(default_quality,
+ "default entropy content of hwrng per mill");
static void start_khwrngd(void);
@@ -79,6 +83,11 @@ static inline int hwrng_init(struct hwrn
if (err)
return err;
+ current_quality = rng->quality ? : default_quality;
+ current_quality &= 1023;
+
+ if (current_quality == 0 && hwrng_fill)
+ kthread_stop(hwrng_fill);
if (current_quality > 0 && !hwrng_fill)
start_khwrngd();
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Patch v5.1 03/03]: hwrng: khwrngd derating per device
2014-05-27 14:11 ` [Patch v5.1 " Torsten Duwe
@ 2014-06-12 1:24 ` H. Peter Anvin
2014-06-12 10:09 ` Torsten Duwe
0 siblings, 1 reply; 41+ messages in thread
From: H. Peter Anvin @ 2014-06-12 1:24 UTC (permalink / raw)
To: Torsten Duwe, Andy Lutomirski
Cc: Theodore Ts'o, Greg Kroah-Hartman, Andrew Morton,
Matt Mackall, Herbert Xu, Arnd Bergmann, Rusty Russell,
Satoru Takeuchi, ingo.tuchscherer, linux-kernel,
Hans-Georg Markgraf, Gerald Schaefer, Martin Schwidefsky,
Heiko Carstens, Joe Perches
On 05/27/2014 07:11 AM, Torsten Duwe wrote:
> [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 <duwe@suse.de>
>
Did we lose track of this patchset?
-hpa
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Patch v5.1 03/03]: hwrng: khwrngd derating per device
2014-06-12 1:24 ` H. Peter Anvin
@ 2014-06-12 10:09 ` Torsten Duwe
2014-06-14 2:40 ` Theodore Ts'o
0 siblings, 1 reply; 41+ messages in thread
From: Torsten Duwe @ 2014-06-12 10:09 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Andy Lutomirski, Theodore Ts'o, Greg Kroah-Hartman,
Andrew Morton, Matt Mackall, Herbert Xu, Arnd Bergmann,
Rusty Russell, Satoru Takeuchi, ingo.tuchscherer, linux-kernel,
Hans-Georg Markgraf, Gerald Schaefer, Martin Schwidefsky,
Heiko Carstens, Joe Perches
On Wed, Jun 11, 2014 at 06:24:53PM -0700, H. Peter Anvin wrote:
> On 05/27/2014 07:11 AM, Torsten Duwe wrote:
> > [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 <duwe@suse.de>
> >
>
> Did we lose track of this patchset?
Yes. I was already considering a resend.
Torsten
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Patch v5.1 03/03]: hwrng: khwrngd derating per device
2014-06-12 10:09 ` Torsten Duwe
@ 2014-06-14 2:40 ` Theodore Ts'o
2014-06-14 2:44 ` H. Peter Anvin
0 siblings, 1 reply; 41+ messages in thread
From: Theodore Ts'o @ 2014-06-14 2:40 UTC (permalink / raw)
To: Torsten Duwe
Cc: H. Peter Anvin, Andy Lutomirski, Greg Kroah-Hartman,
Andrew Morton, Matt Mackall, Herbert Xu, Arnd Bergmann,
Rusty Russell, Satoru Takeuchi, ingo.tuchscherer, linux-kernel,
Hans-Georg Markgraf, Gerald Schaefer, Martin Schwidefsky,
Heiko Carstens, Joe Perches
On Thu, Jun 12, 2014 at 12:09:54PM +0200, Torsten Duwe wrote:
> >
> > 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Patch v5.1 03/03]: hwrng: khwrngd derating per device
2014-06-14 2:40 ` Theodore Ts'o
@ 2014-06-14 2:44 ` H. Peter Anvin
2014-06-15 5:11 ` Theodore Ts'o
0 siblings, 1 reply; 41+ messages in thread
From: H. Peter Anvin @ 2014-06-14 2:44 UTC (permalink / raw)
To: Theodore Ts'o, Torsten Duwe
Cc: Andy Lutomirski, Greg Kroah-Hartman, Andrew Morton, Matt Mackall,
Herbert Xu, Arnd Bergmann, Rusty Russell, Satoru Takeuchi,
ingo.tuchscherer, linux-kernel, Hans-Georg Markgraf,
Gerald Schaefer, Martin Schwidefsky, Heiko Carstens, Joe Perches
Makes sense to me.
Feel free to add my
Acked-by: H. Peter Anvin <hpa@zytor.com>
On June 13, 2014 7:40:50 PM PDT, Theodore Ts'o <tytso@mit.edu> wrote:
>On Thu, Jun 12, 2014 at 12:09:54PM +0200, Torsten Duwe wrote:
>> >
>> > 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
--
Sent from my mobile phone. Please pardon brevity and lack of formatting.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Patch v5.1 03/03]: hwrng: khwrngd derating per device
2014-06-14 2:44 ` H. Peter Anvin
@ 2014-06-15 5:11 ` Theodore Ts'o
2014-06-16 7:31 ` Torsten Duwe
0 siblings, 1 reply; 41+ messages in thread
From: Theodore Ts'o @ 2014-06-15 5:11 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Torsten Duwe, Andy Lutomirski, Greg Kroah-Hartman, Andrew Morton,
Matt Mackall, Herbert Xu, Arnd Bergmann, Rusty Russell,
Satoru Takeuchi, ingo.tuchscherer, linux-kernel,
Hans-Georg Markgraf, Gerald Schaefer, Martin Schwidefsky,
Heiko Carstens, Joe Perches
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.
- Ted
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Patch v5.1 03/03]: hwrng: khwrngd derating per device
2014-06-15 5:11 ` Theodore Ts'o
@ 2014-06-16 7:31 ` Torsten Duwe
2014-06-16 11:22 ` Theodore Ts'o
0 siblings, 1 reply; 41+ messages in thread
From: Torsten Duwe @ 2014-06-16 7:31 UTC (permalink / raw)
To: Theodore Ts'o, H. Peter Anvin, Andy Lutomirski,
Greg Kroah-Hartman, Andrew Morton, Matt Mackall, Herbert Xu,
Arnd Bergmann, Rusty Russell, Satoru Takeuchi, ingo.tuchscherer,
linux-kernel, Hans-Georg Markgraf, Gerald Schaefer,
Martin Schwidefsky, Heiko Carstens, Joe Perches
On Sun, Jun 15, 2014 at 01:11:46AM -0400, Theodore Ts'o wrote:
> 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.
I'm keeping and updating 2 versions, one -current (more or less)
and one for 3.12. I probably missed that when making the discussion changes
back and forth, sorry.
> 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 ;-)
> 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.
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.
> 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.
Thanks,
Torsten
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Patch v5.1 03/03]: hwrng: khwrngd derating per device
2014-06-16 7:31 ` Torsten Duwe
@ 2014-06-16 11:22 ` Theodore Ts'o
2014-06-16 14:07 ` Torsten Duwe
[not found] ` <20140616141444.GB1744@suse.de>
0 siblings, 2 replies; 41+ messages in thread
From: Theodore Ts'o @ 2014-06-16 11:22 UTC (permalink / raw)
To: Torsten Duwe
Cc: H. Peter Anvin, Andy Lutomirski, Greg Kroah-Hartman,
Andrew Morton, Matt Mackall, Herbert Xu, Arnd Bergmann,
Rusty Russell, Satoru Takeuchi, ingo.tuchscherer, linux-kernel,
Hans-Georg Markgraf, Gerald Schaefer, Martin Schwidefsky,
Heiko Carstens, Joe Perches, Jörn Engel
On Mon, Jun 16, 2014 at 09:31:08AM +0200, Torsten Duwe wrote:
> > 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?
If you're testing on s390, I'd appreciate it if you could give the "dev"
branch on random.git a quick try. It has some improvements to help
deal with "entropy challenged" platforms by using the register values
to be mixed in with everything else. This was based on some
suggestions and work by Jörn Engel.
>From my quick testing on x86 platforms, it doubles the overhead of
add_interrupt_randomness() on platforms that don't have a cycle
counter. It still should be fairly low overhead, but it would be
great if some folks on other architectures did some testing to confirm
that the resulting overhead isn't problematic. (Jörn wanted to mix in
all of the registers, but from my calculations, even if we only did
this once a clock tick, the overhead and resulting long tail latency
in interrupt processing time was not something I was willing to
inflict on everyone.)
Also note if you are playing with the random.git tree, there is a
fairly serious bug fix on the "for_linus_stable" branch that will be
pushed to Linus once it gets a bit more testing.
> 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.
> > 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.
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?
Cheers,
- Ted
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Patch v5.1 03/03]: hwrng: khwrngd derating per device
2014-06-16 11:22 ` Theodore Ts'o
@ 2014-06-16 14:07 ` Torsten Duwe
2014-06-16 14:40 ` Theodore Ts'o
[not found] ` <20140616141444.GB1744@suse.de>
1 sibling, 1 reply; 41+ messages in thread
From: Torsten Duwe @ 2014-06-16 14:07 UTC (permalink / raw)
To: Theodore Ts'o, H. Peter Anvin, Andy Lutomirski,
Greg Kroah-Hartman, Andrew Morton, Matt Mackall, Herbert Xu,
Arnd Bergmann, Rusty Russell, Satoru Takeuchi, ingo.tuchscherer,
linux-kernel, Hans-Georg Markgraf, Gerald Schaefer,
Martin Schwidefsky, Heiko Carstens, Joe Perches, Jörn Engel
On Mon, Jun 16, 2014 at 07:22:07AM -0400, Theodore Ts'o wrote:
> On Mon, Jun 16, 2014 at 09:31:08AM +0200, Torsten Duwe wrote:
> > > 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"?) :-)
Actually, I was thinking of a crutch. Makes you walk slowly, but better
than nothing. Seems I've bent the wrong tube.
> Were you referring to the typical hardware implementation in most
> TPM's, or something else?
Those are designed for the TPM's own, internal use IIRC. Their exposure
to the main computer is only a side effect.
> > 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
Then the next question would be about the underlying specification.
A bug free implementation of dual-EC DRBG?
> 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.
> 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.
So let's keep it close to 0, and allow those to raise it who have confidence.
> > 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?
Of course! Choose your mix!
> 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?
One thing after the other. What are the consumers of kernel entropy?
Mostly ASLR, I guess, and the web server / sshd accepting connections.
Those proceses starting probably eats more power than a HWRNG needs for
the appropriate random bits. We can address exceptions once they arise.
Torsten
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Patch v5.1 03/03]: hwrng: khwrngd derating per device
2014-06-16 14:07 ` Torsten Duwe
@ 2014-06-16 14:40 ` Theodore Ts'o
0 siblings, 0 replies; 41+ messages in thread
From: Theodore Ts'o @ 2014-06-16 14:40 UTC (permalink / raw)
To: Torsten Duwe
Cc: H. Peter Anvin, Andy Lutomirski, Greg Kroah-Hartman,
Andrew Morton, Matt Mackall, Herbert Xu, Arnd Bergmann,
Rusty Russell, Satoru Takeuchi, ingo.tuchscherer, linux-kernel,
Hans-Georg Markgraf, Gerald Schaefer, Martin Schwidefsky,
Heiko Carstens, Joe Perches, Jörn Engel
On Mon, Jun 16, 2014 at 04:07:19PM +0200, Torsten Duwe wrote:
> > > 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.
Heh. One of the things that I have considered, especially for TPM, is
that in addition to having a very small quality rating, we should also
have some kind of delay so that we sleep some small amount time before
we pull from the TPM again.
Otherwise the result of using a very small quality rating is that we
end up pounding on the TPM a huge amount until the entropy pool is
above the write_wakeup threshold. If there's some "real" use of the
TPM, such as authenticating to a wireless network, or some such, I'd
rather not be constantly pounding on the TPM if so happens that there
is a heavy drain on /dev/random at the same time that Network Manager
needs to reauthenticate to the 802.1x network.
> > 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.
Sure, but I guess I'm a bit allergic to gazillions of boot
command-line parameters. I guess if you are building a modular
kernel, this matters a lot less, since you can put the configs in
/etc/modprobe.d.
- Ted
^ permalink raw reply [flat|nested] 41+ messages in thread
[parent not found: <20140616141444.GB1744@suse.de>]
* Re: [PATCH v3 00/03]: hwrng: an in-kernel rngd
2014-04-14 16:02 ` [PATCH v3 00/03]: hwrng: an in-kernel rngd Torsten Duwe
` (2 preceding siblings ...)
2014-04-14 16:06 ` [PATCH v3 03/03]: hwrng: khwrngd derating per device Torsten Duwe
@ 2014-04-14 16:09 ` H. Peter Anvin
2014-04-14 16:24 ` Torsten Duwe
2014-04-14 16:27 ` [PATCH v4 03/03]: hwrng: khwrngd derating per device Torsten Duwe
3 siblings, 2 replies; 41+ messages in thread
From: H. Peter Anvin @ 2014-04-14 16:09 UTC (permalink / raw)
To: Torsten Duwe
Cc: Andy Lutomirski, Theodore Ts'o, Greg Kroah-Hartman,
Andrew Morton, Matt Mackall, Herbert Xu, Arnd Bergmann,
Rusty Russell, Satoru Takeuchi, ingo.tuchscherer, linux-kernel,
Hans-Georg Markgraf, Gerald Schaefer, Martin Schwidefsky,
Heiko Carstens, Joe Perches
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.
On April 14, 2014 9:02:11 AM PDT, Torsten Duwe <duwe@lst.de> wrote:
>More or less a resend of v2.
>
>On Wed, Mar 26, 2014 at 06:03:37PM -0700, H. Peter Anvin wrote:
>> 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
--
Sent from my mobile phone. Please pardon brevity and lack of formatting.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH v3 00/03]: hwrng: an in-kernel rngd
2014-04-14 16:09 ` [PATCH v3 00/03]: hwrng: an in-kernel rngd H. Peter Anvin
@ 2014-04-14 16:24 ` Torsten Duwe
2014-04-14 16:29 ` H. Peter Anvin
2014-04-14 16:43 ` Andy Lutomirski
2014-04-14 16:27 ` [PATCH v4 03/03]: hwrng: khwrngd derating per device Torsten Duwe
1 sibling, 2 replies; 41+ messages in thread
From: Torsten Duwe @ 2014-04-14 16:24 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Andy Lutomirski, Theodore Ts'o, Greg Kroah-Hartman,
Andrew Morton, Matt Mackall, Herbert Xu, Arnd Bergmann,
Rusty Russell, Satoru Takeuchi, ingo.tuchscherer, linux-kernel,
Hans-Georg Markgraf, Gerald Schaefer, Martin Schwidefsky,
Heiko Carstens, Joe Perches
On Mon, Apr 14, 2014 at 09:09:14AM -0700, H. Peter Anvin wrote:
> 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.
Torsten
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH v3 00/03]: hwrng: an in-kernel rngd
2014-04-14 16:24 ` Torsten Duwe
@ 2014-04-14 16:29 ` H. Peter Anvin
2014-04-14 16:43 ` Andy Lutomirski
1 sibling, 0 replies; 41+ messages in thread
From: H. Peter Anvin @ 2014-04-14 16:29 UTC (permalink / raw)
To: Torsten Duwe
Cc: Andy Lutomirski, Theodore Ts'o, Greg Kroah-Hartman,
Andrew Morton, Matt Mackall, Herbert Xu, Arnd Bergmann,
Rusty Russell, Satoru Takeuchi, ingo.tuchscherer, linux-kernel,
Hans-Georg Markgraf, Gerald Schaefer, Martin Schwidefsky,
Heiko Carstens, Joe Perches
On 04/14/2014 09:24 AM, Torsten Duwe wrote:
> On Mon, Apr 14, 2014 at 09:09:14AM -0700, H. Peter Anvin wrote:
>> 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.
>
Sounds good.
-hpa
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH v3 00/03]: hwrng: an in-kernel rngd
2014-04-14 16:24 ` Torsten Duwe
2014-04-14 16:29 ` H. Peter Anvin
@ 2014-04-14 16:43 ` Andy Lutomirski
1 sibling, 0 replies; 41+ messages in thread
From: Andy Lutomirski @ 2014-04-14 16:43 UTC (permalink / raw)
To: Torsten Duwe
Cc: H. Peter Anvin, Theodore Ts'o, Greg Kroah-Hartman,
Andrew Morton, Matt Mackall, Herbert Xu, Arnd Bergmann,
Rusty Russell, Satoru Takeuchi, ingo.tuchscherer, linux-kernel,
Hans-Georg Markgraf, Gerald Schaefer, Martin Schwidefsky,
Heiko Carstens, Joe Perches
On Mon, Apr 14, 2014 at 9:24 AM, Torsten Duwe <duwe@lst.de> wrote:
> On Mon, Apr 14, 2014 at 09:09:14AM -0700, H. Peter Anvin wrote:
>> 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.
>
To be clear, I like your patches, bikeshedding aside. Having reads of
/dev/random automatically pull in hwrng data would be *great*. My
drbg patches are not meant to replace them at all. I just think that
there's a need for the nonblocking pool to be well-seeded as quickly
as possible, regardless of configuration, and I don't think your code
is meant to do that.
--Andy
^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH v4 03/03]: hwrng: khwrngd derating per device
2014-04-14 16:09 ` [PATCH v3 00/03]: hwrng: an in-kernel rngd H. Peter Anvin
2014-04-14 16:24 ` Torsten Duwe
@ 2014-04-14 16:27 ` Torsten Duwe
1 sibling, 0 replies; 41+ messages in thread
From: Torsten Duwe @ 2014-04-14 16:27 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Andy Lutomirski, Theodore Ts'o, Greg Kroah-Hartman,
Andrew Morton, Matt Mackall, Herbert Xu, Arnd Bergmann,
Rusty Russell, Satoru Takeuchi, ingo.tuchscherer, linux-kernel,
Hans-Georg Markgraf, Gerald Schaefer, Martin Schwidefsky,
Heiko Carstens, Joe Perches
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 <duwe@suse.de>
---
drivers/char/hw_random/core.c | 11 ++++++++++-
include/linux/hw_random.h | 3 +++
2 files changed, 13 insertions(+), 1 deletion(-)
--- linux/include/linux/hw_random.h.orig
+++ linux/include/linux/hw_random.h
@@ -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).
*/
struct hwrng {
const char *name;
@@ -38,6 +39,7 @@ struct hwrng {
int (*data_read)(struct hwrng *rng, u32 *data);
int (*read)(struct hwrng *rng, void *data, size_t max, bool wait);
unsigned long priv;
+ unsigned short derating;
/* internal. */
struct list_head list;
--- linux/drivers/char/hw_random/core.c.orig
+++ linux/drivers/char/hw_random/core.c
@@ -56,11 +56,15 @@ static LIST_HEAD(rng_list);
static DEFINE_MUTEX(rng_mutex);
static int data_avail;
static u8 *rng_buffer, *rng_fillbuf;
-static unsigned short derating_current = 700; /* an arbitrary 70% */
+static unsigned short derating_current;
+static unsigned short derating_default = 0; /* default to "off" */
module_param(derating_current, ushort, 0644);
MODULE_PARM_DESC(derating_current,
"current hwrng entropy estimation per mill");
+module_param(derating_default, ushort, 0644);
+MODULE_PARM_DESC(derating_default,
+ "default entropy content of hwrng per mill");
static void start_khwrngd(void);
@@ -79,6 +83,11 @@ static inline int hwrng_init(struct hwrn
if (err)
return err;
+ derating_current = rng->derating ? : derating_default;
+ derating_current &= 1023;
+
+ if (derating_current == 0 && hwrng_fill)
+ kthread_stop(hwrng_fill);
if (derating_current > 0 && !hwrng_fill)
start_khwrngd();
^ permalink raw reply [flat|nested] 41+ messages in thread