[PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm

[PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm

[Andy Lutomirski]

This introduces and uses a very simple synchronous mechanism to get
/dev/urandom-style bits appropriate for initial KVM PV guest RNG
seeding.

It also re-works the way that architectural random data is fed into
random.c's pools.  I added a new arch hook called arch_get_rng_seed.
The default implementation is more or less the same as the current
code, except that random_get_entropy is now called unconditionally.

x86 gets a custom arch_get_rng_seed.  It will use KVM_GET_RNG_SEED
if available, and, if it does anything, it will log the number of
bits collected from each available architectural source.  If more
paravirt seed sources show up, it will be a natural place to add
them.

I sent the corresponding kvm-unit-tests and qemu changes separately.

Changes from v4:
 - Got rid of the RDRAND behavior change.  If this series is accepted,
   I may resend it separately, but I think it's an unrelated issue.
 - Fix up the changelog entries -- I misunderstood how the old code
   worked.
 - Avoid lots of failed attempts to use KVM_GET_RNG_SEED if it's not
   available.

Changes from v3:
 - Other than KASLR, the guest pieces are completely rewritten.
   Patches 2-4 have essentially nothing in common with v2.

Changes from v2:
 - Bisection fix (patch 2 had a misplaced brace).  The final states is
   identical to that of v2.
 - Improve the 0/5 description a little bit.

Changes from v1:
 - Split patches 2 and 3
 - Log all arch sources in init_std_data
 - Fix the 32-bit kaslr build

Andy Lutomirski (5):
  x86,kvm: Add MSR_KVM_GET_RNG_SEED and a matching feature bit
  random: Add and use arch_get_rng_seed
  x86,random: Add an x86 implementation of arch_get_rng_seed
  x86,random,kvm: Use KVM_GET_RNG_SEED in arch_get_rng_seed
  x86,kaslr: Use MSR_KVM_GET_RNG_SEED for KASLR if available

 Documentation/virtual/kvm/cpuid.txt  |  3 ++
 arch/x86/Kconfig                     |  4 ++
 arch/x86/boot/compressed/aslr.c      | 27 +++++++++++++
 arch/x86/include/asm/archrandom.h    |  6 +++
 arch/x86/include/asm/kvm_guest.h     |  9 +++++
 arch/x86/include/asm/processor.h     | 21 ++++++++--
 arch/x86/include/uapi/asm/kvm_para.h |  2 +
 arch/x86/kernel/Makefile             |  2 +
 arch/x86/kernel/archrandom.c         | 74 ++++++++++++++++++++++++++++++++++++
 arch/x86/kernel/kvm.c                | 10 +++++
 arch/x86/kvm/cpuid.c                 |  3 +-
 arch/x86/kvm/x86.c                   |  4 ++
 drivers/char/random.c                | 14 +++++--
 include/linux/random.h               | 40 +++++++++++++++++++
 14 files changed, 212 insertions(+), 7 deletions(-)
 create mode 100644 arch/x86/kernel/archrandom.c

-- 
1.9.3

[PATCH v5 1/5] x86,kvm: Add MSR_KVM_GET_RNG_SEED and a matching feature bit

[Andy Lutomirski]

This adds a simple interface to allow a guest to request 64 bits of
host nonblocking entropy.  This is independent of virtio-rng for a
couple of reasons:

 - It's intended to be usable during early boot, when a trivial
   synchronous interface is needed.

 - virtio-rng gives blocking entropy, and making guest boot wait for
   the host's /dev/random will cause problems.

MSR_KVM_GET_RNG_SEED is intended to provide 64 bits of best-effort
cryptographically secure data for use as a seed.  It provides no
guarantee that the result contains any actual entropy.

Signed-off-by: Andy Lutomirski <luto@amacapital.net>
---
 Documentation/virtual/kvm/cpuid.txt  | 3 +++
 arch/x86/include/uapi/asm/kvm_para.h | 2 ++
 arch/x86/kvm/cpuid.c                 | 3 ++-
 arch/x86/kvm/x86.c                   | 4 ++++
 4 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt
index 3c65feb..0ab043b 100644
--- a/Documentation/virtual/kvm/cpuid.txt
+++ b/Documentation/virtual/kvm/cpuid.txt
@@ -54,6 +54,9 @@ KVM_FEATURE_PV_UNHALT              ||     7 || guest checks this feature bit
                                    ||       || before enabling paravirtualized
                                    ||       || spinlock support.
 ------------------------------------------------------------------------------
+KVM_FEATURE_GET_RNG_SEED           ||     8 || host provides rng seed data via
+                                   ||       || MSR_KVM_GET_RNG_SEED.
+------------------------------------------------------------------------------
 KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||    24 || host will warn if no guest-side
                                    ||       || per-cpu warps are expected in
                                    ||       || kvmclock.
diff --git a/arch/x86/include/uapi/asm/kvm_para.h b/arch/x86/include/uapi/asm/kvm_para.h
index 94dc8ca..e2eaf93 100644
--- a/arch/x86/include/uapi/asm/kvm_para.h
+++ b/arch/x86/include/uapi/asm/kvm_para.h
@@ -24,6 +24,7 @@
 #define KVM_FEATURE_STEAL_TIME		5
 #define KVM_FEATURE_PV_EOI		6
 #define KVM_FEATURE_PV_UNHALT		7
+#define KVM_FEATURE_GET_RNG_SEED	8
 
 /* The last 8 bits are used to indicate how to interpret the flags field
  * in pvclock structure. If no bits are set, all flags are ignored.
@@ -40,6 +41,7 @@
 #define MSR_KVM_ASYNC_PF_EN 0x4b564d02
 #define MSR_KVM_STEAL_TIME  0x4b564d03
 #define MSR_KVM_PV_EOI_EN      0x4b564d04
+#define MSR_KVM_GET_RNG_SEED 0x4b564d05
 
 struct kvm_steal_time {
 	__u64 steal;
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 38a0afe..40d6763 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -479,7 +479,8 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
 			     (1 << KVM_FEATURE_ASYNC_PF) |
 			     (1 << KVM_FEATURE_PV_EOI) |
 			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
-			     (1 << KVM_FEATURE_PV_UNHALT);
+			     (1 << KVM_FEATURE_PV_UNHALT) |
+			     (1 << KVM_FEATURE_GET_RNG_SEED);
 
 		if (sched_info_on())
 			entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index f644933..4e81853 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -48,6 +48,7 @@
 #include <linux/pci.h>
 #include <linux/timekeeper_internal.h>
 #include <linux/pvclock_gtod.h>
+#include <linux/random.h>
 #include <trace/events/kvm.h>
 
 #define CREATE_TRACE_POINTS
@@ -2480,6 +2481,9 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata)
 	case MSR_KVM_PV_EOI_EN:
 		data = vcpu->arch.pv_eoi.msr_val;
 		break;
+	case MSR_KVM_GET_RNG_SEED:
+		get_random_bytes(&data, sizeof(data));
+		break;
 	case MSR_IA32_P5_MC_ADDR:
 	case MSR_IA32_P5_MC_TYPE:
 	case MSR_IA32_MCG_CAP:
-- 
1.9.3

[PATCH v5 2/5] random: Add and use arch_get_rng_seed

[Andy Lutomirski]

Currently, init_std_data contains its own logic for using arch
random sources.  This replaces that logic with a generic function
arch_get_rng_seed that allows arch code to supply its own logic.
The default implementation tries arch_get_random_seed_long and
arch_get_random_long individually.

The only functional change here is that random_get_entropy() is used
unconditionally instead of being used only when the arch sources
fail.  This may add a tiny amount of security.

Signed-off-by: Andy Lutomirski <luto@amacapital.net>
---
 drivers/char/random.c  | 14 +++++++++++---
 include/linux/random.h | 40 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 51 insertions(+), 3 deletions(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 0a7ac0a..be7a94e 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1236,6 +1236,10 @@ void get_random_bytes_arch(void *buf, int nbytes)
 }
 EXPORT_SYMBOL(get_random_bytes_arch);
 
+static void seed_entropy_store(void *ctx, u32 data)
+{
+	mix_pool_bytes((struct entropy_store *)ctx, &data, sizeof(data), NULL);
+}
 
 /*
  * init_std_data - initialize pool with system data
@@ -1251,15 +1255,19 @@ static void init_std_data(struct entropy_store *r)
 	int i;
 	ktime_t now = ktime_get_real();
 	unsigned long rv;
+	char log_prefix[128];
 
 	r->last_pulled = jiffies;
 	mix_pool_bytes(r, &now, sizeof(now), NULL);
 	for (i = r->poolinfo->poolbytes; i > 0; i -= sizeof(rv)) {
-		if (!arch_get_random_seed_long(&rv) &&
-		    !arch_get_random_long(&rv))
-			rv = random_get_entropy();
+		rv = random_get_entropy();
 		mix_pool_bytes(r, &rv, sizeof(rv), NULL);
 	}
+
+	sprintf(log_prefix, "random: seeded %s pool", r->name);
+	arch_get_rng_seed(r, seed_entropy_store, 8 * r->poolinfo->poolbytes,
+			  log_prefix);
+
 	mix_pool_bytes(r, utsname(), sizeof(*(utsname())), NULL);
 }
 
diff --git a/include/linux/random.h b/include/linux/random.h
index 57fbbff..81a6145 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -106,6 +106,46 @@ static inline int arch_has_random_seed(void)
 }
 #endif
 
+#ifndef __HAVE_ARCH_GET_RNG_SEED
+
+/**
+ * arch_get_rng_seed() - get architectural rng seed data
+ * @ctx: context for the seed function
+ * @seed: function to call for each u32 obtained
+ * @bits_per_source: number of bits from each source to try to use
+ * @log_prefix: beginning of log output (may be NULL)
+ *
+ * Synchronously load some architectural entropy or other best-effort
+ * random seed data.  An arch-specific implementation should be no worse
+ * than this generic implementation.  If the arch code does something
+ * interesting, it may log something of the form "log_prefix with
+ * 8 bits of stuff".
+ *
+ * No arch-specific implementation should be any worse than the generic
+ * implementation.
+ */
+static inline void arch_get_rng_seed(void *ctx,
+				     void (*seed)(void *ctx, u32 data),
+				     int bits_per_source,
+				     const char *log_prefix)
+{
+	int i;
+
+	for (i = 0; i < bits_per_source; i += 8 * sizeof(long)) {
+		unsigned long rv;
+
+		if (arch_get_random_seed_long(&rv) ||
+		    arch_get_random_long(&rv)) {
+			seed(ctx, (u32)rv);
+#if BITS_PER_LONG > 32
+			seed(ctx, (u32)(rv >> 32));
+#endif
+		}
+	}
+}
+
+#endif /* __HAVE_ARCH_GET_RNG_SEED */
+
 /* Pseudo random number generator from numerical recipes. */
 static inline u32 next_pseudo_random32(u32 seed)
 {
-- 
1.9.3

[PATCH v5 3/5] x86,random: Add an x86 implementation of arch_get_rng_seed

[Andy Lutomirski]

This does the same thing as the generic implementation, except
that it logs how many bits of each type it collected.  I want to
know whether the initial seeding is working and, if so, whether
the RNG is fast enough.

(I know that hpa assures me that the hardware RNG is more than
 fast enough, but I'd still like a direct way to verify this.)

Arguably, arch_get_random_seed could be removed now: I'm having some
trouble imagining a sensible non-architecture-specific use of it
that wouldn't be better served by arch_get_rng_seed.

Signed-off-by: Andy Lutomirski <luto@amacapital.net>
---
 arch/x86/include/asm/archrandom.h |  6 +++++
 arch/x86/kernel/Makefile          |  2 ++
 arch/x86/kernel/archrandom.c      | 51 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 59 insertions(+)
 create mode 100644 arch/x86/kernel/archrandom.c

diff --git a/arch/x86/include/asm/archrandom.h b/arch/x86/include/asm/archrandom.h
index 69f1366..88f9c5a 100644
--- a/arch/x86/include/asm/archrandom.h
+++ b/arch/x86/include/asm/archrandom.h
@@ -117,6 +117,12 @@ GET_SEED(arch_get_random_seed_int, unsigned int, RDSEED_INT, ASM_NOP4);
 #define arch_has_random()	static_cpu_has(X86_FEATURE_RDRAND)
 #define arch_has_random_seed()	static_cpu_has(X86_FEATURE_RDSEED)
 
+#define __HAVE_ARCH_GET_RNG_SEED
+extern void arch_get_rng_seed(void *ctx,
+			      void (*seed)(void *ctx, u32 data),
+			      int bits_per_source,
+			      const char *log_prefix);
+
 #else
 
 static inline int rdrand_long(unsigned long *v)
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 047f9ff..0718bae 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -92,6 +92,8 @@ obj-$(CONFIG_PARAVIRT)		+= paravirt.o paravirt_patch_$(BITS).o
 obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= paravirt-spinlocks.o
 obj-$(CONFIG_PARAVIRT_CLOCK)	+= pvclock.o
 
+obj-$(CONFIG_ARCH_RANDOM)	+= archrandom.o
+
 obj-$(CONFIG_PCSPKR_PLATFORM)	+= pcspeaker.o
 
 obj-$(CONFIG_X86_CHECK_BIOS_CORRUPTION) += check.o
diff --git a/arch/x86/kernel/archrandom.c b/arch/x86/kernel/archrandom.c
new file mode 100644
index 0000000..47d13b0
--- /dev/null
+++ b/arch/x86/kernel/archrandom.c
@@ -0,0 +1,51 @@
+/*
+ * This file is part of the Linux kernel.
+ *
+ * Copyright (c) 2014 Andy Lutomirski
+ * Authors: Andy Lutomirski <luto@amacapital.net>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <asm/archrandom.h>
+
+void arch_get_rng_seed(void *ctx,
+		       void (*seed)(void *ctx, u32 data),
+		       int bits_per_source,
+		       const char *log_prefix)
+{
+	int i;
+	int rdseed_bits = 0, rdrand_bits = 0;
+	char buf[128] = "";
+	char *msgptr = buf;
+
+	for (i = 0; i < bits_per_source; i += 8 * sizeof(long)) {
+		unsigned long rv;
+
+		if (arch_get_random_seed_long(&rv))
+			rdseed_bits += 8 * sizeof(rv);
+		else if (arch_get_random_long(&rv))
+			rdrand_bits += 8 * sizeof(rv);
+		else
+			continue;	/* Don't waste time mixing. */
+
+		seed(ctx, (u32)rv);
+#if BITS_PER_LONG > 32
+		seed(ctx, (u32)(rv >> 32));
+#endif
+	}
+
+	if (rdseed_bits)
+		msgptr += sprintf(msgptr, ", %d bits from RDSEED", rdseed_bits);
+	if (rdrand_bits)
+		msgptr += sprintf(msgptr, ", %d bits from RDRAND", rdrand_bits);
+	if (buf[0])
+		pr_info("%s with %s\n", log_prefix, buf + 2);
+}
-- 
1.9.3

[PATCH v5 4/5] x86,random,kvm: Use KVM_GET_RNG_SEED in arch_get_rng_seed

[Andy Lutomirski]

This is a straightforward implementation: for each bit of internal
RNG state, request one bit from KVM_GET_RNG_SEED.  This is done even
if RDSEED/RDRAND worked, since KVM_GET_RNG_SEED is likely to provide
cryptographically secure output even if the CPU's RNG is weak or
compromised.

Signed-off-by: Andy Lutomirski <luto@amacapital.net>
---
 arch/x86/Kconfig                 |  4 ++++
 arch/x86/include/asm/kvm_guest.h |  9 +++++++++
 arch/x86/kernel/archrandom.c     | 25 ++++++++++++++++++++++++-
 arch/x86/kernel/kvm.c            | 10 ++++++++++
 4 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a8f749e..adfa09c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -593,6 +593,7 @@ config KVM_GUEST
 	bool "KVM Guest support (including kvmclock)"
 	depends on PARAVIRT
 	select PARAVIRT_CLOCK
+	select ARCH_RANDOM
 	default y
 	---help---
 	  This option enables various optimizations for running under the KVM
@@ -1507,6 +1508,9 @@ config ARCH_RANDOM
 	  If supported, this is a high bandwidth, cryptographically
 	  secure hardware random number generator.
 
+	  This also enables paravirt RNGs such as KVM's if the relevant
+	  PV guest support is enabled.
+
 config X86_SMAP
 	def_bool y
 	prompt "Supervisor Mode Access Prevention" if EXPERT
diff --git a/arch/x86/include/asm/kvm_guest.h b/arch/x86/include/asm/kvm_guest.h
index a92b176..8c4dbd5 100644
--- a/arch/x86/include/asm/kvm_guest.h
+++ b/arch/x86/include/asm/kvm_guest.h
@@ -3,4 +3,13 @@
 
 int kvm_setup_vsyscall_timeinfo(void);
 
+#if defined(CONFIG_KVM_GUEST) && defined(CONFIG_ARCH_RANDOM)
+extern bool kvm_get_rng_seed(u64 *rv);
+#else
+static inline bool kvm_get_rng_seed(u64 *rv)
+{
+	return false;
+}
+#endif
+
 #endif /* _ASM_X86_KVM_GUEST_H */
diff --git a/arch/x86/kernel/archrandom.c b/arch/x86/kernel/archrandom.c
index 47d13b0..8c8d021 100644
--- a/arch/x86/kernel/archrandom.c
+++ b/arch/x86/kernel/archrandom.c
@@ -15,6 +15,7 @@
  */
 
 #include <asm/archrandom.h>
+#include <asm/kvm_guest.h>
 
 void arch_get_rng_seed(void *ctx,
 		       void (*seed)(void *ctx, u32 data),
@@ -22,7 +23,7 @@ void arch_get_rng_seed(void *ctx,
 		       const char *log_prefix)
 {
 	int i;
-	int rdseed_bits = 0, rdrand_bits = 0;
+	int rdseed_bits = 0, rdrand_bits = 0, kvm_bits = 0;
 	char buf[128] = "";
 	char *msgptr = buf;
 
@@ -42,10 +43,32 @@ void arch_get_rng_seed(void *ctx,
 #endif
 	}
 
+	/*
+	 * Use KVM_GET_RNG_SEED regardless of whether the CPU RNG
+	 * worked, since it incorporates entropy unavailable to the CPU,
+	 * and we shouldn't trust the hardware RNG more than we need to.
+	 * We request enough bits for the entire internal RNG state,
+	 * because there's no good reason not to.
+	 */
+	for (i = 0; i < bits_per_source; i += 64) {
+		u64 rv;
+
+		if (kvm_get_rng_seed(&rv)) {
+			seed(ctx, (u32)rv);
+			seed(ctx, (u32)(rv >> 32));
+			kvm_bits += 8 * sizeof(rv);
+		} else {
+			break;	/* If it fails once, it will keep failing. */
+		}
+	}
+
 	if (rdseed_bits)
 		msgptr += sprintf(msgptr, ", %d bits from RDSEED", rdseed_bits);
 	if (rdrand_bits)
 		msgptr += sprintf(msgptr, ", %d bits from RDRAND", rdrand_bits);
+	if (kvm_bits)
+		msgptr += sprintf(msgptr, ", %d bits from KVM_GET_RNG_BITS",
+				  kvm_bits);
 	if (buf[0])
 		pr_info("%s with %s\n", log_prefix, buf + 2);
 }
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 3dd8e2c..bd8783a 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -416,6 +416,16 @@ void kvm_disable_steal_time(void)
 	wrmsr(MSR_KVM_STEAL_TIME, 0, 0);
 }
 
+bool kvm_get_rng_seed(u64 *v)
+{
+	/*
+	 * Allow migration from a hypervisor with the GET_RNG_SEED
+	 * feature to a hypervisor without it.
+	 */
+	return (kvm_para_has_feature(KVM_FEATURE_GET_RNG_SEED) &&
+		rdmsrl_safe(MSR_KVM_GET_RNG_SEED, v) == 0);
+}
+
 #ifdef CONFIG_SMP
 static void __init kvm_smp_prepare_boot_cpu(void)
 {
-- 
1.9.3

[PATCH v5 5/5] x86,kaslr: Use MSR_KVM_GET_RNG_SEED for KASLR if available

[Andy Lutomirski]

It's considerably better than any of the alternatives on KVM.

Rather than reinventing all of the cpu feature query code, this fixes
native_cpuid to work in PIC objects.

I haven't combined it with boot/cpuflags.c's cpuid implementation:
including asm/processor.h from boot/cpuflags.c results in a flood of
unrelated errors, and fixing it might be messy.

Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
---
 arch/x86/boot/compressed/aslr.c  | 27 +++++++++++++++++++++++++++
 arch/x86/include/asm/processor.h | 21 ++++++++++++++++++---
 2 files changed, 45 insertions(+), 3 deletions(-)

diff --git a/arch/x86/boot/compressed/aslr.c b/arch/x86/boot/compressed/aslr.c
index fc6091a..8583f0e 100644
--- a/arch/x86/boot/compressed/aslr.c
+++ b/arch/x86/boot/compressed/aslr.c
@@ -5,6 +5,8 @@
 #include <asm/archrandom.h>
 #include <asm/e820.h>
 
+#include <uapi/asm/kvm_para.h>
+
 #include <generated/compile.h>
 #include <linux/module.h>
 #include <linux/uts.h>
@@ -15,6 +17,22 @@
 static const char build_str[] = UTS_RELEASE " (" LINUX_COMPILE_BY "@"
 		LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION;
 
+static bool kvm_para_has_feature(unsigned int feature)
+{
+	u32 kvm_base;
+	u32 features;
+
+	if (!has_cpuflag(X86_FEATURE_HYPERVISOR))
+		return false;
+
+	kvm_base = hypervisor_cpuid_base("KVMKVMKVM\0\0\0", KVM_CPUID_FEATURES);
+	if (!kvm_base)
+		return false;
+
+	features = cpuid_eax(kvm_base | KVM_CPUID_FEATURES);
+	return features & (1UL << feature);
+}
+
 #define I8254_PORT_CONTROL	0x43
 #define I8254_PORT_COUNTER0	0x40
 #define I8254_CMD_READBACK	0xC0
@@ -81,6 +99,15 @@ static unsigned long get_random_long(void)
 		}
 	}
 
+	if (kvm_para_has_feature(KVM_FEATURE_GET_RNG_SEED)) {
+		u64 seed;
+
+		debug_putstr(" MSR_KVM_GET_RNG_SEED");
+		rdmsrl(MSR_KVM_GET_RNG_SEED, seed);
+		random ^= (unsigned long)seed;
+		use_i8254 = false;
+	}
+
 	if (has_cpuflag(X86_FEATURE_TSC)) {
 		debug_putstr(" RDTSC");
 		rdtscll(raw);
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index a4ea023..6096f3c 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -189,10 +189,25 @@ static inline int have_cpuid_p(void)
 static inline void native_cpuid(unsigned int *eax, unsigned int *ebx,
 				unsigned int *ecx, unsigned int *edx)
 {
-	/* ecx is often an input as well as an output. */
-	asm volatile("cpuid"
+	/*
+	 * This function can be used from the boot code, so it needs
+	 * to avoid using EBX in constraints in PIC mode.
+	 *
+	 * ecx is often an input as well as an output.
+	 */
+	asm volatile(".ifnc %%ebx,%1 ; .ifnc %%rbx,%1           \n\t"
+		     "movl  %%ebx,%1                            \n\t"
+		     ".endif ; .endif                           \n\t"
+		     "cpuid					\n\t"
+		     ".ifnc %%ebx,%1 ; .ifnc %%rbx,%1           \n\t"
+		     "xchgl %%ebx,%1                            \n\t"
+		     ".endif ; .endif"
 	    : "=a" (*eax),
-	      "=b" (*ebx),
+#if defined(__i386__) && defined(__PIC__)
+	      "=r" (*ebx),	/* gcc won't let us use ebx */
+#else
+	      "=b" (*ebx),	/* ebx is okay */
+#endif
 	      "=c" (*ecx),
 	      "=d" (*edx)
 	    : "0" (*eax), "2" (*ecx)
-- 
1.9.3

Re: [PATCH v5 2/5] random: Add and use arch_get_rng_seed

[Andy Lutomirski]

On Wed, Jul 23, 2014 at 9:57 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> Currently, init_std_data contains its own logic for using arch
> random sources.  This replaces that logic with a generic function
> arch_get_rng_seed that allows arch code to supply its own logic.
> The default implementation tries arch_get_random_seed_long and
> arch_get_random_long individually.
>
> The only functional change here is that random_get_entropy() is used
> unconditionally instead of being used only when the arch sources
> fail.  This may add a tiny amount of security.

tytso, are you okay with this approach?  I'd be happy to rework this
if you prefer some other way of doing it.

--Andy

>
> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> ---
>  drivers/char/random.c  | 14 +++++++++++---
>  include/linux/random.h | 40 ++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 51 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index 0a7ac0a..be7a94e 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -1236,6 +1236,10 @@ void get_random_bytes_arch(void *buf, int nbytes)
>  }
>  EXPORT_SYMBOL(get_random_bytes_arch);
>
> +static void seed_entropy_store(void *ctx, u32 data)
> +{
> +       mix_pool_bytes((struct entropy_store *)ctx, &data, sizeof(data), NULL);
> +}
>
>  /*
>   * init_std_data - initialize pool with system data
> @@ -1251,15 +1255,19 @@ static void init_std_data(struct entropy_store *r)
>         int i;
>         ktime_t now = ktime_get_real();
>         unsigned long rv;
> +       char log_prefix[128];
>
>         r->last_pulled = jiffies;
>         mix_pool_bytes(r, &now, sizeof(now), NULL);
>         for (i = r->poolinfo->poolbytes; i > 0; i -= sizeof(rv)) {
> -               if (!arch_get_random_seed_long(&rv) &&
> -                   !arch_get_random_long(&rv))
> -                       rv = random_get_entropy();
> +               rv = random_get_entropy();
>                 mix_pool_bytes(r, &rv, sizeof(rv), NULL);
>         }
> +
> +       sprintf(log_prefix, "random: seeded %s pool", r->name);
> +       arch_get_rng_seed(r, seed_entropy_store, 8 * r->poolinfo->poolbytes,
> +                         log_prefix);
> +
>         mix_pool_bytes(r, utsname(), sizeof(*(utsname())), NULL);
>  }
>
> diff --git a/include/linux/random.h b/include/linux/random.h
> index 57fbbff..81a6145 100644
> --- a/include/linux/random.h
> +++ b/include/linux/random.h
> @@ -106,6 +106,46 @@ static inline int arch_has_random_seed(void)
>  }
>  #endif
>
> +#ifndef __HAVE_ARCH_GET_RNG_SEED
> +
> +/**
> + * arch_get_rng_seed() - get architectural rng seed data
> + * @ctx: context for the seed function
> + * @seed: function to call for each u32 obtained
> + * @bits_per_source: number of bits from each source to try to use
> + * @log_prefix: beginning of log output (may be NULL)
> + *
> + * Synchronously load some architectural entropy or other best-effort
> + * random seed data.  An arch-specific implementation should be no worse
> + * than this generic implementation.  If the arch code does something
> + * interesting, it may log something of the form "log_prefix with
> + * 8 bits of stuff".
> + *
> + * No arch-specific implementation should be any worse than the generic
> + * implementation.
> + */
> +static inline void arch_get_rng_seed(void *ctx,
> +                                    void (*seed)(void *ctx, u32 data),
> +                                    int bits_per_source,
> +                                    const char *log_prefix)
> +{
> +       int i;
> +
> +       for (i = 0; i < bits_per_source; i += 8 * sizeof(long)) {
> +               unsigned long rv;
> +
> +               if (arch_get_random_seed_long(&rv) ||
> +                   arch_get_random_long(&rv)) {
> +                       seed(ctx, (u32)rv);
> +#if BITS_PER_LONG > 32
> +                       seed(ctx, (u32)(rv >> 32));
> +#endif
> +               }
> +       }
> +}
> +
> +#endif /* __HAVE_ARCH_GET_RNG_SEED */
> +
>  /* Pseudo random number generator from numerical recipes. */
>  static inline u32 next_pseudo_random32(u32 seed)
>  {
> --
> 1.9.3
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH v5 5/5] x86,kaslr: Use MSR_KVM_GET_RNG_SEED for KASLR if available

[Paolo Bonzini]

Il 24/07/2014 06:57, Andy Lutomirski ha scritto:
> It's considerably better than any of the alternatives on KVM.
> 
> Rather than reinventing all of the cpu feature query code, this fixes
> native_cpuid to work in PIC objects.
> 
> I haven't combined it with boot/cpuflags.c's cpuid implementation:
> including asm/processor.h from boot/cpuflags.c results in a flood of
> unrelated errors, and fixing it might be messy.
> 
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> ---
>  arch/x86/boot/compressed/aslr.c  | 27 +++++++++++++++++++++++++++
>  arch/x86/include/asm/processor.h | 21 ++++++++++++++++++---
>  2 files changed, 45 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/boot/compressed/aslr.c b/arch/x86/boot/compressed/aslr.c
> index fc6091a..8583f0e 100644
> --- a/arch/x86/boot/compressed/aslr.c
> +++ b/arch/x86/boot/compressed/aslr.c
> @@ -5,6 +5,8 @@
>  #include <asm/archrandom.h>
>  #include <asm/e820.h>
>  
> +#include <uapi/asm/kvm_para.h>
> +
>  #include <generated/compile.h>
>  #include <linux/module.h>
>  #include <linux/uts.h>
> @@ -15,6 +17,22 @@
>  static const char build_str[] = UTS_RELEASE " (" LINUX_COMPILE_BY "@"
>  		LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION;
>  
> +static bool kvm_para_has_feature(unsigned int feature)
> +{
> +	u32 kvm_base;
> +	u32 features;
> +
> +	if (!has_cpuflag(X86_FEATURE_HYPERVISOR))
> +		return false;
> +
> +	kvm_base = hypervisor_cpuid_base("KVMKVMKVM\0\0\0", KVM_CPUID_FEATURES);
> +	if (!kvm_base)
> +		return false;
> +
> +	features = cpuid_eax(kvm_base | KVM_CPUID_FEATURES);
> +	return features & (1UL << feature);
> +}
> +
>  #define I8254_PORT_CONTROL	0x43
>  #define I8254_PORT_COUNTER0	0x40
>  #define I8254_CMD_READBACK	0xC0
> @@ -81,6 +99,15 @@ static unsigned long get_random_long(void)
>  		}
>  	}
>  
> +	if (kvm_para_has_feature(KVM_FEATURE_GET_RNG_SEED)) {
> +		u64 seed;
> +
> +		debug_putstr(" MSR_KVM_GET_RNG_SEED");
> +		rdmsrl(MSR_KVM_GET_RNG_SEED, seed);
> +		random ^= (unsigned long)seed;
> +		use_i8254 = false;
> +	}
> +
>  	if (has_cpuflag(X86_FEATURE_TSC)) {
>  		debug_putstr(" RDTSC");
>  		rdtscll(raw);
> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> index a4ea023..6096f3c 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -189,10 +189,25 @@ static inline int have_cpuid_p(void)
>  static inline void native_cpuid(unsigned int *eax, unsigned int *ebx,
>  				unsigned int *ecx, unsigned int *edx)
>  {
> -	/* ecx is often an input as well as an output. */
> -	asm volatile("cpuid"
> +	/*
> +	 * This function can be used from the boot code, so it needs
> +	 * to avoid using EBX in constraints in PIC mode.
> +	 *
> +	 * ecx is often an input as well as an output.
> +	 */
> +	asm volatile(".ifnc %%ebx,%1 ; .ifnc %%rbx,%1           \n\t"
> +		     "movl  %%ebx,%1                            \n\t"
> +		     ".endif ; .endif                           \n\t"
> +		     "cpuid					\n\t"
> +		     ".ifnc %%ebx,%1 ; .ifnc %%rbx,%1           \n\t"
> +		     "xchgl %%ebx,%1                            \n\t"
> +		     ".endif ; .endif"
>  	    : "=a" (*eax),
> -	      "=b" (*ebx),
> +#if defined(__i386__) && defined(__PIC__)
> +	      "=r" (*ebx),	/* gcc won't let us use ebx */
> +#else
> +	      "=b" (*ebx),	/* ebx is okay */
> +#endif
>  	      "=c" (*ecx),
>  	      "=d" (*edx)
>  	    : "0" (*eax), "2" (*ecx)
> 

Acked-by: Paolo Bonzini <pbonzini@redhat.com>

Re: [PATCH v5 4/5] x86,random,kvm: Use KVM_GET_RNG_SEED in arch_get_rng_seed

[Paolo Bonzini]

Il 24/07/2014 06:57, Andy Lutomirski ha scritto:
> This is a straightforward implementation: for each bit of internal
> RNG state, request one bit from KVM_GET_RNG_SEED.  This is done even
> if RDSEED/RDRAND worked, since KVM_GET_RNG_SEED is likely to provide
> cryptographically secure output even if the CPU's RNG is weak or
> compromised.
> 
> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> ---
>  arch/x86/Kconfig                 |  4 ++++
>  arch/x86/include/asm/kvm_guest.h |  9 +++++++++
>  arch/x86/kernel/archrandom.c     | 25 ++++++++++++++++++++++++-
>  arch/x86/kernel/kvm.c            | 10 ++++++++++
>  4 files changed, 47 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index a8f749e..adfa09c 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -593,6 +593,7 @@ config KVM_GUEST
>  	bool "KVM Guest support (including kvmclock)"
>  	depends on PARAVIRT
>  	select PARAVIRT_CLOCK
> +	select ARCH_RANDOM
>  	default y
>  	---help---
>  	  This option enables various optimizations for running under the KVM
> @@ -1507,6 +1508,9 @@ config ARCH_RANDOM
>  	  If supported, this is a high bandwidth, cryptographically
>  	  secure hardware random number generator.
>  
> +	  This also enables paravirt RNGs such as KVM's if the relevant
> +	  PV guest support is enabled.
> +
>  config X86_SMAP
>  	def_bool y
>  	prompt "Supervisor Mode Access Prevention" if EXPERT
> diff --git a/arch/x86/include/asm/kvm_guest.h b/arch/x86/include/asm/kvm_guest.h
> index a92b176..8c4dbd5 100644
> --- a/arch/x86/include/asm/kvm_guest.h
> +++ b/arch/x86/include/asm/kvm_guest.h
> @@ -3,4 +3,13 @@
>  
>  int kvm_setup_vsyscall_timeinfo(void);
>  
> +#if defined(CONFIG_KVM_GUEST) && defined(CONFIG_ARCH_RANDOM)
> +extern bool kvm_get_rng_seed(u64 *rv);
> +#else
> +static inline bool kvm_get_rng_seed(u64 *rv)
> +{
> +	return false;
> +}
> +#endif
> +
>  #endif /* _ASM_X86_KVM_GUEST_H */
> diff --git a/arch/x86/kernel/archrandom.c b/arch/x86/kernel/archrandom.c
> index 47d13b0..8c8d021 100644
> --- a/arch/x86/kernel/archrandom.c
> +++ b/arch/x86/kernel/archrandom.c
> @@ -15,6 +15,7 @@
>   */
>  
>  #include <asm/archrandom.h>
> +#include <asm/kvm_guest.h>
>  
>  void arch_get_rng_seed(void *ctx,
>  		       void (*seed)(void *ctx, u32 data),
> @@ -22,7 +23,7 @@ void arch_get_rng_seed(void *ctx,
>  		       const char *log_prefix)
>  {
>  	int i;
> -	int rdseed_bits = 0, rdrand_bits = 0;
> +	int rdseed_bits = 0, rdrand_bits = 0, kvm_bits = 0;
>  	char buf[128] = "";
>  	char *msgptr = buf;
>  
> @@ -42,10 +43,32 @@ void arch_get_rng_seed(void *ctx,
>  #endif
>  	}
>  
> +	/*
> +	 * Use KVM_GET_RNG_SEED regardless of whether the CPU RNG
> +	 * worked, since it incorporates entropy unavailable to the CPU,
> +	 * and we shouldn't trust the hardware RNG more than we need to.
> +	 * We request enough bits for the entire internal RNG state,
> +	 * because there's no good reason not to.
> +	 */
> +	for (i = 0; i < bits_per_source; i += 64) {
> +		u64 rv;
> +
> +		if (kvm_get_rng_seed(&rv)) {
> +			seed(ctx, (u32)rv);
> +			seed(ctx, (u32)(rv >> 32));
> +			kvm_bits += 8 * sizeof(rv);
> +		} else {
> +			break;	/* If it fails once, it will keep failing. */
> +		}
> +	}
> +
>  	if (rdseed_bits)
>  		msgptr += sprintf(msgptr, ", %d bits from RDSEED", rdseed_bits);
>  	if (rdrand_bits)
>  		msgptr += sprintf(msgptr, ", %d bits from RDRAND", rdrand_bits);
> +	if (kvm_bits)
> +		msgptr += sprintf(msgptr, ", %d bits from KVM_GET_RNG_BITS",
> +				  kvm_bits);
>  	if (buf[0])
>  		pr_info("%s with %s\n", log_prefix, buf + 2);
>  }
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index 3dd8e2c..bd8783a 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -416,6 +416,16 @@ void kvm_disable_steal_time(void)
>  	wrmsr(MSR_KVM_STEAL_TIME, 0, 0);
>  }
>  
> +bool kvm_get_rng_seed(u64 *v)
> +{
> +	/*
> +	 * Allow migration from a hypervisor with the GET_RNG_SEED
> +	 * feature to a hypervisor without it.
> +	 */
> +	return (kvm_para_has_feature(KVM_FEATURE_GET_RNG_SEED) &&
> +		rdmsrl_safe(MSR_KVM_GET_RNG_SEED, v) == 0);
> +}
> +
>  #ifdef CONFIG_SMP
>  static void __init kvm_smp_prepare_boot_cpu(void)
>  {
> 

Acked-by: Paolo Bonzini <pbonzini@redhat.com>

Re: [PATCH v5 1/5] x86,kvm: Add MSR_KVM_GET_RNG_SEED and a matching feature bit

[Paolo Bonzini]

Il 24/07/2014 06:57, Andy Lutomirski ha scritto:
> This adds a simple interface to allow a guest to request 64 bits of
> host nonblocking entropy.  This is independent of virtio-rng for a
> couple of reasons:
> 
>  - It's intended to be usable during early boot, when a trivial
>    synchronous interface is needed.
> 
>  - virtio-rng gives blocking entropy, and making guest boot wait for
>    the host's /dev/random will cause problems.
> 
> MSR_KVM_GET_RNG_SEED is intended to provide 64 bits of best-effort
> cryptographically secure data for use as a seed.  It provides no
> guarantee that the result contains any actual entropy.
> 
> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> ---
>  Documentation/virtual/kvm/cpuid.txt  | 3 +++
>  arch/x86/include/uapi/asm/kvm_para.h | 2 ++
>  arch/x86/kvm/cpuid.c                 | 3 ++-
>  arch/x86/kvm/x86.c                   | 4 ++++
>  4 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt
> index 3c65feb..0ab043b 100644
> --- a/Documentation/virtual/kvm/cpuid.txt
> +++ b/Documentation/virtual/kvm/cpuid.txt
> @@ -54,6 +54,9 @@ KVM_FEATURE_PV_UNHALT              ||     7 || guest checks this feature bit
>                                     ||       || before enabling paravirtualized
>                                     ||       || spinlock support.
>  ------------------------------------------------------------------------------
> +KVM_FEATURE_GET_RNG_SEED           ||     8 || host provides rng seed data via
> +                                   ||       || MSR_KVM_GET_RNG_SEED.
> +------------------------------------------------------------------------------
>  KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||    24 || host will warn if no guest-side
>                                     ||       || per-cpu warps are expected in
>                                     ||       || kvmclock.
> diff --git a/arch/x86/include/uapi/asm/kvm_para.h b/arch/x86/include/uapi/asm/kvm_para.h
> index 94dc8ca..e2eaf93 100644
> --- a/arch/x86/include/uapi/asm/kvm_para.h
> +++ b/arch/x86/include/uapi/asm/kvm_para.h
> @@ -24,6 +24,7 @@
>  #define KVM_FEATURE_STEAL_TIME		5
>  #define KVM_FEATURE_PV_EOI		6
>  #define KVM_FEATURE_PV_UNHALT		7
> +#define KVM_FEATURE_GET_RNG_SEED	8
>  
>  /* The last 8 bits are used to indicate how to interpret the flags field
>   * in pvclock structure. If no bits are set, all flags are ignored.
> @@ -40,6 +41,7 @@
>  #define MSR_KVM_ASYNC_PF_EN 0x4b564d02
>  #define MSR_KVM_STEAL_TIME  0x4b564d03
>  #define MSR_KVM_PV_EOI_EN      0x4b564d04
> +#define MSR_KVM_GET_RNG_SEED 0x4b564d05
>  
>  struct kvm_steal_time {
>  	__u64 steal;
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 38a0afe..40d6763 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -479,7 +479,8 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
>  			     (1 << KVM_FEATURE_ASYNC_PF) |
>  			     (1 << KVM_FEATURE_PV_EOI) |
>  			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
> -			     (1 << KVM_FEATURE_PV_UNHALT);
> +			     (1 << KVM_FEATURE_PV_UNHALT) |
> +			     (1 << KVM_FEATURE_GET_RNG_SEED);
>  
>  		if (sched_info_on())
>  			entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index f644933..4e81853 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -48,6 +48,7 @@
>  #include <linux/pci.h>
>  #include <linux/timekeeper_internal.h>
>  #include <linux/pvclock_gtod.h>
> +#include <linux/random.h>
>  #include <trace/events/kvm.h>
>  
>  #define CREATE_TRACE_POINTS
> @@ -2480,6 +2481,9 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata)
>  	case MSR_KVM_PV_EOI_EN:
>  		data = vcpu->arch.pv_eoi.msr_val;
>  		break;
> +	case MSR_KVM_GET_RNG_SEED:
> +		get_random_bytes(&data, sizeof(data));
> +		break;
>  	case MSR_IA32_P5_MC_ADDR:
>  	case MSR_IA32_P5_MC_TYPE:
>  	case MSR_IA32_MCG_CAP:
> 

Acked-by: Paolo Bonzini <pbonzini@redhat.com>

Re: [PATCH v5 2/5] random: Add and use arch_get_rng_seed

[Theodore Ts'o]

On Wed, Jul 23, 2014 at 09:57:28PM -0700, Andy Lutomirski wrote:
> Currently, init_std_data contains its own logic for using arch
> random sources.  This replaces that logic with a generic function
> arch_get_rng_seed that allows arch code to supply its own logic.
> The default implementation tries arch_get_random_seed_long and
> arch_get_random_long individually.
> 
> The only functional change here is that random_get_entropy() is used
> unconditionally instead of being used only when the arch sources
> fail.  This may add a tiny amount of security.
> 
> Signed-off-by: Andy Lutomirski <luto@amacapital.net>

Acked-by: Theodore Ts'o <tytso@mit.edu>

							- Ted

Re: [PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm

[Andy Lutomirski]

On Wed, Jul 23, 2014 at 9:57 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> This introduces and uses a very simple synchronous mechanism to get
> /dev/urandom-style bits appropriate for initial KVM PV guest RNG
> seeding.
>
> It also re-works the way that architectural random data is fed into
> random.c's pools.  I added a new arch hook called arch_get_rng_seed.
> The default implementation is more or less the same as the current
> code, except that random_get_entropy is now called unconditionally.
>
> x86 gets a custom arch_get_rng_seed.  It will use KVM_GET_RNG_SEED
> if available, and, if it does anything, it will log the number of
> bits collected from each available architectural source.  If more
> paravirt seed sources show up, it will be a natural place to add
> them.
>
> I sent the corresponding kvm-unit-tests and qemu changes separately.

What's the status of this series?  I assume that it's too late for at
least patches 2-5 to make it into 3.17.

--Andy

>
> Changes from v4:
>  - Got rid of the RDRAND behavior change.  If this series is accepted,
>    I may resend it separately, but I think it's an unrelated issue.
>  - Fix up the changelog entries -- I misunderstood how the old code
>    worked.
>  - Avoid lots of failed attempts to use KVM_GET_RNG_SEED if it's not
>    available.
>
> Changes from v3:
>  - Other than KASLR, the guest pieces are completely rewritten.
>    Patches 2-4 have essentially nothing in common with v2.
>
> Changes from v2:
>  - Bisection fix (patch 2 had a misplaced brace).  The final states is
>    identical to that of v2.
>  - Improve the 0/5 description a little bit.
>
> Changes from v1:
>  - Split patches 2 and 3
>  - Log all arch sources in init_std_data
>  - Fix the 32-bit kaslr build
>
> Andy Lutomirski (5):
>   x86,kvm: Add MSR_KVM_GET_RNG_SEED and a matching feature bit
>   random: Add and use arch_get_rng_seed
>   x86,random: Add an x86 implementation of arch_get_rng_seed
>   x86,random,kvm: Use KVM_GET_RNG_SEED in arch_get_rng_seed
>   x86,kaslr: Use MSR_KVM_GET_RNG_SEED for KASLR if available
>
>  Documentation/virtual/kvm/cpuid.txt  |  3 ++
>  arch/x86/Kconfig                     |  4 ++
>  arch/x86/boot/compressed/aslr.c      | 27 +++++++++++++
>  arch/x86/include/asm/archrandom.h    |  6 +++
>  arch/x86/include/asm/kvm_guest.h     |  9 +++++
>  arch/x86/include/asm/processor.h     | 21 ++++++++--
>  arch/x86/include/uapi/asm/kvm_para.h |  2 +
>  arch/x86/kernel/Makefile             |  2 +
>  arch/x86/kernel/archrandom.c         | 74 ++++++++++++++++++++++++++++++++++++
>  arch/x86/kernel/kvm.c                | 10 +++++
>  arch/x86/kvm/cpuid.c                 |  3 +-
>  arch/x86/kvm/x86.c                   |  4 ++
>  drivers/char/random.c                | 14 +++++--
>  include/linux/random.h               | 40 +++++++++++++++++++
>  14 files changed, 212 insertions(+), 7 deletions(-)
>  create mode 100644 arch/x86/kernel/archrandom.c
>
> --
> 1.9.3
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm

[Theodore Ts'o]

On Tue, Aug 12, 2014 at 12:11:29PM -0700, Andy Lutomirski wrote:
> 
> What's the status of this series?  I assume that it's too late for at
> least patches 2-5 to make it into 3.17.

Which tree were you hoping this patch series to go through?  I was
assuming it would go through the x86 tree since the bulk of the
changes in the x86 subsystem (hence my Acked-by).

IIRC, Peter had some concerns, and I don't remember if they were all
addressed.  Peter?

						- Ted

Re: [PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm

[Andy Lutomirski]

On Tue, Aug 12, 2014 at 12:17 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Tue, Aug 12, 2014 at 12:11:29PM -0700, Andy Lutomirski wrote:
>>
>> What's the status of this series?  I assume that it's too late for at
>> least patches 2-5 to make it into 3.17.
>
> Which tree were you hoping this patch series to go through?  I was
> assuming it would go through the x86 tree since the bulk of the
> changes in the x86 subsystem (hence my Acked-by).

There's some argument that patch 1 should go through the kvm tree.
There's no real need for patch 1 and 2-5 to end up in the same kernel
release, either.

>
> IIRC, Peter had some concerns, and I don't remember if they were all
> addressed.  Peter?
>

I don't know.  I rewrite one thing he didn't like and undid the other,
but there's plenty of opportunity for this version to be problematic, too.

--Andy

Re: [PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm

[H. Peter Anvin]

On 08/12/2014 12:22 PM, Andy Lutomirski wrote:
> On Tue, Aug 12, 2014 at 12:17 PM, Theodore Ts'o <tytso@mit.edu> wrote:
>> On Tue, Aug 12, 2014 at 12:11:29PM -0700, Andy Lutomirski wrote:
>>>
>>> What's the status of this series?  I assume that it's too late for at
>>> least patches 2-5 to make it into 3.17.
>>
>> Which tree were you hoping this patch series to go through?  I was
>> assuming it would go through the x86 tree since the bulk of the
>> changes in the x86 subsystem (hence my Acked-by).
> 
> There's some argument that patch 1 should go through the kvm tree.
> There's no real need for patch 1 and 2-5 to end up in the same kernel
> release, either.
> 
>>
>> IIRC, Peter had some concerns, and I don't remember if they were all
>> addressed.  Peter?
>>
> 
> I don't know.  I rewrite one thing he didn't like and undid the other,
> but there's plenty of opportunity for this version to be problematic, too.
> 

Sorry, I have been heads down on the current merge window.  I will look
at this for 3.18, presumably after Kernel Summit.

The proposed arch_get_rng_seed() is not really what it claims to be; it
most definitely does not produce seed-grade randomness, instead it seems
to be an arch function for best-effort initialization of the entropy
pools -- which is fine, it is just something quite different.

I want to look over it more carefully before acking it, though.

Andy, are you going to be in Chicago?

	-hpa

Re: [PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm

[Andy Lutomirski]

On Aug 13, 2014 12:48 AM, "H. Peter Anvin" <hpa@zytor.com> wrote:
>
> On 08/12/2014 12:22 PM, Andy Lutomirski wrote:
> > On Tue, Aug 12, 2014 at 12:17 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> >> On Tue, Aug 12, 2014 at 12:11:29PM -0700, Andy Lutomirski wrote:
> >>>
> >>> What's the status of this series?  I assume that it's too late for at
> >>> least patches 2-5 to make it into 3.17.
> >>
> >> Which tree were you hoping this patch series to go through?  I was
> >> assuming it would go through the x86 tree since the bulk of the
> >> changes in the x86 subsystem (hence my Acked-by).
> >
> > There's some argument that patch 1 should go through the kvm tree.
> > There's no real need for patch 1 and 2-5 to end up in the same kernel
> > release, either.
> >
> >>
> >> IIRC, Peter had some concerns, and I don't remember if they were all
> >> addressed.  Peter?
> >>
> >
> > I don't know.  I rewrite one thing he didn't like and undid the other,
> > but there's plenty of opportunity for this version to be problematic, too.
> >
>
> Sorry, I have been heads down on the current merge window.  I will look
> at this for 3.18, presumably after Kernel Summit.
>
> The proposed arch_get_rng_seed() is not really what it claims to be; it
> most definitely does not produce seed-grade randomness, instead it seems
> to be an arch function for best-effort initialization of the entropy
> pools -- which is fine, it is just something quite different.

Fair enough.  I meant "seed" as in something that initialized a PRNG
(think srand), not "seed" as in a
promised-to-be-cryptographically-secure seed for a DRBG.

I can rename it, update the comment, or otherwise tweak it to make the
intent clearer.

>
> I want to look over it more carefully before acking it, though.

It would also be nice for someone with a Haswell box (and an RDSEED
box) to test it.  I have neither.

>
> Andy, are you going to be in Chicago?

Yes.

>
>         -hpa
>

Re: [PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm

[Theodore Ts'o]

On Wed, Aug 13, 2014 at 12:48:41AM -0700, H. Peter Anvin wrote:
> The proposed arch_get_rng_seed() is not really what it claims to be; it
> most definitely does not produce seed-grade randomness, instead it seems
> to be an arch function for best-effort initialization of the entropy
> pools -- which is fine, it is just something quite different.

Without getting into an argument about which definition of "seed" is
correct --- it's certainly confusing and different form the RDSEED
usage of the word "seed".

Do we expect that anyone else besides arch_get_rnd_seed() would
actually want to use it?  I'd argue no; we want the rest of the kernel
to either use get_random_bytes() or prandom_u32().  Given that, maybe
we should just call it arch_random_init(), and expect that the only
user of this interface would be drivers/char/random.c?

					- Ted

Re: [PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm

[Andy Lutomirski]

On Wed, Aug 13, 2014 at 7:32 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Wed, Aug 13, 2014 at 12:48:41AM -0700, H. Peter Anvin wrote:
>> The proposed arch_get_rng_seed() is not really what it claims to be; it
>> most definitely does not produce seed-grade randomness, instead it seems
>> to be an arch function for best-effort initialization of the entropy
>> pools -- which is fine, it is just something quite different.
>
> Without getting into an argument about which definition of "seed" is
> correct --- it's certainly confusing and different form the RDSEED
> usage of the word "seed".
>
> Do we expect that anyone else besides arch_get_rnd_seed() would
> actually want to use it?

If you mean random.c instead of arch_get_rnd_seed, then I don't expect
there to be other users.  Aside from the "best-effort" bit causing
this to be basically useless on old bare metal, the interface is
really awkward for anything other than the use in random.c.

> I'd argue no; we want the rest of the kernel
> to either use get_random_bytes() or prandom_u32().  Given that, maybe
> we should just call it arch_random_init(), and expect that the only
> user of this interface would be drivers/char/random.c?

Sounds good to me.

FWIW, I'd like to see a second use added in random.c: I think that we
should do this, or even all of init_std_data, on resume from suspend
and especially on resume from hibernate / kexec.

--Andy

Re: [PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm

[H. Peter Anvin]

On 08/13/2014 09:13 AM, Andy Lutomirski wrote:
> 
> Sounds good to me.
> 
> FWIW, I'd like to see a second use added in random.c: I think that we
> should do this, or even all of init_std_data, on resume from suspend
> and especially on resume from hibernate / kexec.
> 

Yes, we should.  We also need to make it possible to do this after
cloning a VM.

	-hpa

Re: [PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm

[Theodore Ts'o]

On Wed, Aug 13, 2014 at 10:45:25AM -0700, H. Peter Anvin wrote:
> On 08/13/2014 09:13 AM, Andy Lutomirski wrote:
> > 
> > Sounds good to me.
> > 
> > FWIW, I'd like to see a second use added in random.c: I think that we
> > should do this, or even all of init_std_data, on resume from suspend
> > and especially on resume from hibernate / kexec.
> > 
> 
> Yes, we should.  We also need to make it possible to do this after
> cloning a VM.

Agreed.  Can you send a patch?

I can carry the commits to add arch_random_init() the generic version,
and the patch to call it after suspend/resume.  I'll do this at the
very head of the random tree, and make sure it gets pushed to Linus
early during the next merge window.

Does that sound like a plan?  Or does someone want to suggest
something different?  I'm flexible...

						- Ted

Re: [PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm

[Andy Lutomirski]

On Wed, Aug 13, 2014 at 11:22 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Wed, Aug 13, 2014 at 10:45:25AM -0700, H. Peter Anvin wrote:
>> On 08/13/2014 09:13 AM, Andy Lutomirski wrote:
>> >
>> > Sounds good to me.
>> >
>> > FWIW, I'd like to see a second use added in random.c: I think that we
>> > should do this, or even all of init_std_data, on resume from suspend
>> > and especially on resume from hibernate / kexec.
>> >
>>
>> Yes, we should.  We also need to make it possible to do this after
>> cloning a VM.
>
> Agreed.  Can you send a patch?
>
> I can carry the commits to add arch_random_init() the generic version,
> and the patch to call it after suspend/resume.  I'll do this at the
> very head of the random tree, and make sure it gets pushed to Linus
> early during the next merge window.
>
> Does that sound like a plan?  Or does someone want to suggest
> something different?  I'm flexible...

OK.  Here's a proposal.  I'll split the series into two parts.  The
first part will be the arch_random_init generic change and code to
call it after suspend/resume (once I figure out the right callback).
I'll send that to you.

The second part will be the KVM and x86 code, which will look just
like this version (v5) except for the rename.  If needed, hpa and I
can hash the details we need at KS.

As for doing arch_random_init after clone/migration, I think we'll
need another KVM extension for that, since, AFAIK, we don't actually
get notified that we were cloned or migrated.  That will be
nontrivial.  Maybe we can figure that out at KS, too.

--Andy

>
>                                                 - Ted



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm

[H. Peter Anvin]

On 08/13/2014 11:33 AM, Andy Lutomirski wrote:
> 
> As for doing arch_random_init after clone/migration, I think we'll
> need another KVM extension for that, since, AFAIK, we don't actually
> get notified that we were cloned or migrated.  That will be
> nontrivial.  Maybe we can figure that out at KS, too.
> 

We don't need a reset when migrated (although it might be a good idea
under some circumstances, i.e. if the pools might somehow have gotten
exposed) but definitely when cloned.

	-hpa

Re: [PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm

[H. Peter Anvin]

On 08/13/2014 11:44 AM, H. Peter Anvin wrote:
> On 08/13/2014 11:33 AM, Andy Lutomirski wrote:
>>
>> As for doing arch_random_init after clone/migration, I think we'll
>> need another KVM extension for that, since, AFAIK, we don't actually
>> get notified that we were cloned or migrated.  That will be
>> nontrivial.  Maybe we can figure that out at KS, too.
>>
> 
> We don't need a reset when migrated (although it might be a good idea
> under some circumstances, i.e. if the pools might somehow have gotten
> exposed) but definitely when cloned.
> 

But yes, we need a notification.  For obvious reasons there is no
suspend event (one can snapshot a running VM) but we need to be notified
upon wakeup, *or* we need to give KVM a way to update the necessary state.

	-hpa

Re: [PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm

[Andy Lutomirski]

On Wed, Aug 13, 2014 at 7:41 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 08/13/2014 11:44 AM, H. Peter Anvin wrote:
>> On 08/13/2014 11:33 AM, Andy Lutomirski wrote:
>>>
>>> As for doing arch_random_init after clone/migration, I think we'll
>>> need another KVM extension for that, since, AFAIK, we don't actually
>>> get notified that we were cloned or migrated.  That will be
>>> nontrivial.  Maybe we can figure that out at KS, too.
>>>
>>
>> We don't need a reset when migrated (although it might be a good idea
>> under some circumstances, i.e. if the pools might somehow have gotten
>> exposed) but definitely when cloned.
>>
>
> But yes, we need a notification.  For obvious reasons there is no
> suspend event (one can snapshot a running VM) but we need to be notified
> upon wakeup, *or* we need to give KVM a way to update the necessary state.

This could presumably use the interrupt mechanism on virtio-rng if
we're willing to depend on having host support for virtio-rng.

v6 (coming in a few minutes) will at least get it right when the
kernel goes through the resume path (i.e. not KVM/QEMU suspend, and
maybe not S0ix either).

--Andy

Re: [PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm

[Paolo Bonzini]

Il 13/08/2014 20:33, Andy Lutomirski ha scritto:
> As for doing arch_random_init after clone/migration, I think we'll
> need another KVM extension for that, since, AFAIK, we don't actually
> get notified that we were cloned or migrated.  That will be
> nontrivial.  Maybe we can figure that out at KS, too.

Migration doesn't need an arch_random_init, only cloning does.

MS has an ACPI-based specification for this they call the "VM Generation
ID", which QEMU should be implementing it sooner rather than later.  In
Linux we could add a generic notifier, and an x86 platform driver that
implements the VM Generation ID specification and invokes the notifier.

http://go.microsoft.com/fwlink/p/?LinkID=260709 (warning, .docx ahead)

KY, would you be interested in looking at this?

Paolo