After a suspend/resume cycle, and especially after hibernating, we
should assume that the random pools might have leaked. To minimize
the risk this poses, try to collect fresh architectural entropy on
resume.
Signed-off-by: Andy Lutomirski <l...@amacapital.net>
---
drivers/char/random.c | 26 +++++++++++++++++++++++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 8dc3e3a..0811ad4 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -257,6 +257,7 @@
#include <linux/kmemcheck.h>
#include <linux/workqueue.h>
#include <linux/irq.h>
+#include <linux/syscore_ops.h>
#include <asm/processor.h>
#include <asm/uaccess.h>
@@ -1279,6 +1280,26 @@ static void init_std_data(struct entropy_store *r)
mix_pool_bytes(r, utsname(), sizeof(*(utsname())), NULL);
}
+static void init_all_pools(void)
+{
+ init_std_data(&input_pool);
+ init_std_data(&blocking_pool);
+ init_std_data(&nonblocking_pool);
+}
+
+static void random_resume(void)
+{
+ /*
+ * After resume (and especially after hibernation / kexec resume),
+ * make a best-effort attempt to collect fresh entropy.
+ */
+ init_all_pools();
+}
+
+static struct syscore_ops random_syscore_ops = {
+ .resume = random_resume,
+};
+
/*
* Note that setup_arch() may call add_device_randomness()
* long before we get here. This allows seeding of the pools
@@ -1291,9 +1312,8 @@ static void init_std_data(struct entropy_store *r)
*/
static int rand_initialize(void)
{
- init_std_data(&input_pool);
- init_std_data(&blocking_pool);
- init_std_data(&nonblocking_pool);
+ init_all_pools();
+ register_syscore_ops(&random_syscore_ops);
return 0;
}
early_initcall(rand_initialize);
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
