shacky wrote:
Hi.
Is it possible to have 32-bit color graphic on KVM virtual machines?
I installed a Windows virtual machine, but it allows me to configure
only 24-bit color display and it does not have any display driver
installed.
24-bit means 8 bits per RGB channel. 32-bit means 8 bits per
On 3.7.0 + irrelevant patches, I get this on boot. I've seen it on
and off on earlier kernels, I think (although I'm not currently
getting it on 3.5).
[ 10.230054] PERCPU: allocation failed, size=304 align=32, alloc
from reserved chunk failed
[ 10.230059] Pid: 1026, comm: modprobe Tainted: G
On Fri, Dec 14, 2012 at 5:03 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Thu, Dec 13, 2012 at 09:43:23PM -0800, Andy Lutomirski wrote:
On 3.7.0 + irrelevant patches, I get this on boot. I've seen it on
and off on earlier kernels, I think (although I'm not currently
getting it on 3.5
to reproduce on a non-ept host later on, but that will
involve finding one.
On Wed, Feb 15, 2012 at 3:01 AM, Amit Shah amit.s...@redhat.com wrote:
On (Tue) 14 Feb 2012 [08:26:22], Andy Lutomirski wrote:
On Tue, Feb 14, 2012 at 4:22 AM, Amit Shah amit.s...@redhat.com wrote:
Can you try booting
On Thu, Feb 16, 2012 at 8:17 AM, Avi Kivity a...@redhat.com wrote:
On 02/15/2012 09:36 PM, Andy Lutomirski wrote:
Hi, kvm people-
Here's a strange failure. It could be a bug in something
RHEL6-specific, but it could be a generic issue that only triggers
with a paravirt guest with old
On Thu, Feb 16, 2012 at 9:14 AM, Avi Kivity a...@redhat.com wrote:
On 02/16/2012 06:45 PM, Andy Lutomirski wrote:
So I could have messed up, or there could be a subtle
bug somewhere. Any ideas?
What's the code trying to do? Execute an instruction from an
non-executable page, trap
.
I think it's unintentional that some kvm versions apparently forget to
set the PF_INSTR bit.
--Andy
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
Andy Lutomirski
AMA Capital Management, LLC
Office: (310) 553
On Thu, Jan 3, 2013 at 5:41 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
Andy, Mike, can you confirm whether this fixes the percpu allocation
failures when loading kvm.ko? TIA
Use dynamic percpu allocations for the shared msrs structure,
to avoid using the limited reserved percpu
The idea is that the kernel can be much more careful fixing up
uaccess exceptions -- page faults on user addresses are the only
legitimate reason for a uaccess instruction to fault.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
I'm not 100% sure what's happening in the KVM code. Can
On 03/29/2014 01:47 AM, Zhanghailiang wrote:
Hi,
I found when Guest is idle, VDSO pvclock may increase host consumption.
We can calcutate as follow, Correct me if I am wrong.
(Host)250 * update_pvclock_gtod = 1500 * gettimeofday(Guest)
In Host, VDSO pvclock introduce a notifier chain,
On Mar 31, 2014 8:45 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Mon, Mar 31, 2014 at 10:52:25AM -0700, Andy Lutomirski wrote:
On 03/29/2014 01:47 AM, Zhanghailiang wrote:
Hi,
I found when Guest is idle, VDSO pvclock may increase host consumption.
We can calcutate as follow
On Tue, Apr 1, 2014 at 11:01 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Mon, Mar 31, 2014 at 10:33:41PM -0700, Andy Lutomirski wrote:
On Mar 31, 2014 8:45 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Mon, Mar 31, 2014 at 10:52:25AM -0700, Andy Lutomirski wrote:
On 03/29/2014
On Tue, Apr 1, 2014 at 5:12 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Tue, Apr 01, 2014 at 12:17:16PM -0700, Andy Lutomirski wrote:
On Tue, Apr 1, 2014 at 11:01 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Mon, Mar 31, 2014 at 10:33:41PM -0700, Andy Lutomirski wrote:
On Mar 31
On Tue, Apr 1, 2014 at 5:29 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Tue, Apr 01, 2014 at 12:17:16PM -0700, Andy Lutomirski wrote:
On Tue, Apr 1, 2014 at 11:01 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Mon, Mar 31, 2014 at 10:33:41PM -0700, Andy Lutomirski wrote:
On Mar 31
On Wed, Apr 2, 2014 at 3:05 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Tue, Apr 01, 2014 at 05:46:34PM -0700, Andy Lutomirski wrote:
On Tue, Apr 1, 2014 at 5:29 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Tue, Apr 01, 2014 at 12:17:16PM -0700, Andy Lutomirski wrote:
On Tue, Apr
On Thu, May 1, 2014 at 8:35 AM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, May 1, 2014 at 8:05 AM, ty...@mit.edu wrote:
On Wed, Apr 30, 2014 at 09:05:00PM -0700, H. Peter Anvin wrote:
Giving the guest a seed would be highly useful, though. There are a
number of ways to do
On Thu, May 1, 2014 at 11:59 AM, H. Peter Anvin h...@zytor.com wrote:
On 05/01/2014 11:53 AM, Andy Lutomirski wrote:
A CPUID leaf or an MSR advertised by a CPUID leaf has another
advantage: it's easy to use in the ASLR code -- I don't think there's
a real IDT, so there's nothing like
On May 1, 2014 12:26 PM, ty...@mit.edu wrote:
On Thu, May 01, 2014 at 12:02:49PM -0700, Andy Lutomirski wrote:
Is RDSEED really reasonable here? Won't it slow down by several
orders of magnitude?
That is I think the biggest problem; RDRAND and RDSEED are fast if
they are native
PDT, Andy Lutomirski l...@amacapital.net wrote:
On May 1, 2014 12:26 PM, ty...@mit.edu wrote:
On Thu, May 01, 2014 at 12:02:49PM -0700, Andy Lutomirski wrote:
Is RDSEED really reasonable here? Won't it slow down by several
orders of magnitude?
That is I think the biggest problem; RDRAND
On Thu, May 1, 2014 at 1:39 PM, ty...@mit.edu wrote:
On Thu, May 01, 2014 at 01:32:55PM -0700, Andy Lutomirski wrote:
On Thu, May 1, 2014 at 1:30 PM, H. Peter Anvin h...@zytor.com wrote:
RDSEED is not synchronous. It is, however, nonblocking.
What I mean is: IIUC it's reasonable to call
On Thu, May 1, 2014 at 2:01 PM, H. Peter Anvin h...@zytor.com wrote:
On 05/01/2014 01:56 PM, Andy Lutomirski wrote:
Even if we could emulate RDSEED effectively**, I don't really
understand what the guest is expected to do with it. And I generally
dislike defining an interface with no known
On Thu, May 1, 2014 at 3:28 PM, ty...@mit.edu wrote:
On Thu, May 01, 2014 at 02:06:13PM -0700, Andy Lutomirski wrote:
I still don't see the point. What does this do better than virtio-rng?
I believe you had been complaining about how complicated it was to set
up virtio
On Thu, May 1, 2014 at 3:46 PM, H. Peter Anvin h...@zytor.com wrote:
On 05/01/2014 03:32 PM, Andy Lutomirski wrote:
On Thu, May 1, 2014 at 3:28 PM, ty...@mit.edu wrote:
On Thu, May 01, 2014 at 02:06:13PM -0700, Andy Lutomirski wrote:
I still don't see the point. What does this do better
I'm testing 39bfe90706ab0f588db7cb4d1c0e6d1181e1d2f9. I'm not sure
what's going on here.
voffset.h contains:
#define VO__end 0x8111c7a0
#define VO__end 0x8db9a000
#define VO__text 0x8100
because
$ nm vmlinux|grep ' _end'
8111c7a0 t _end
8db9a000 B
On 07/02/2014 09:50 AM, Andrea Arcangeli wrote:
Hello everyone,
There's a large CC list for this RFC because this adds two new
syscalls (userfaultfd and remap_anon_pages) and
MADV_USERFAULT/MADV_NOUSERFAULT, so suggestions on changes to the API
or on a completely different API if somebody
On 07/02/2014 09:50 AM, Andrea Arcangeli wrote:
Once an userfaultfd is created MADV_USERFAULT regions talks through
the userfaultfd protocol with the thread responsible for doing the
memory externalization of the process.
The protocol starts by userland writing the requested/preferred
it asynchronously means that
/dev/urandom might be predictable when userspace starts.
This introduces a very simple synchronous mechanism to get
/dev/urandom-style bits.
This is a KVM change: am I supposed to write a unit test somewhere?
Andy Lutomirski (4):
x86,kvm: Add MSR_KVM_GET_RNG_SEED
, 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 l
This should help solve the problem of guests starting out with
predictable RNG state.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers/char/random.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
without any noticeable slowdown.
This initial implementation backs it with MSR_KVM_GET_RNG_SEED if
available. The intent is for other hypervisor guest implementations
to implement this interface.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/Kconfig | 4
It's considerably better than any of the alternatives on KVM.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/boot/compressed/aslr.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/x86/boot/compressed/aslr.c b/arch/x86/boot/compressed/aslr.c
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
config/config-x86-common.mak | 5 -
x86/get_rng_seed.c | 50
x86/unittests.cfg| 3 +++
3 files changed, 57 insertions(+), 1 deletion(-)
create mode 100644 x86
On Wed, Jul 16, 2014 at 12:36 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 16/07/2014 09:10, Daniel Borkmann ha scritto:
On 07/16/2014 08:41 AM, Gleb Natapov wrote:
On Tue, Jul 15, 2014 at 07:48:06PM -0700, Andy Lutomirski wrote:
virtio-rng is both too complicated and insufficient
This updates x86's kvm_para.h for the feature bit definition and
target-i386/cpu.c for the feature name and default.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
linux-headers/asm-x86/kvm_para.h | 2 ++
target-i386/cpu.c| 5 +++--
2 files changed, 5 insertions(+), 2
On Wed, Jul 16, 2014 at 7:32 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 16/07/2014 16:07, Andy Lutomirski ha scritto:
This patch has nothing whatsoever to do with how much I trust the CPU
vs the hypervisor. It's for the enormous installed base of machines
without RDRAND.
Ok. I think
, 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 l
in a flood of
unrelated errors, and fixing it might be messy.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/boot/compressed/aslr.c | 27 +++
arch/x86/include/asm/processor.h | 21 ++---
2 files changed, 45 insertions(+), 3 deletions(-)
diff
This is useful for making sure that init_std_data is working
correctly and for allaying fear when this happens:
random: xyz urandom read with SMALL_NUMBER bits of entropy available
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers/char/random.c | 14 +++---
1 file
without any noticeable slowdown.
This initial implementation backs it with MSR_KVM_GET_RNG_SEED if
available. The intent is for other hypervisor guest implementations
to implement this interface.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/Kconfig | 4
This should help solve the problem of guests starting out with
predictable RNG state.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers/char/random.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 0a7ac0a..e2c3d02
arch_get_slow_rng_u64. I
considered arch_get_rng_seed_u64, but that could be confused with
arch_get_random_seed_long, which is not interchangeable.
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
On Wed, Jul 16, 2014 at 11:02 AM, Bandan Das b...@redhat.com wrote:
Andy Lutomirski l...@amacapital.net writes:
virtio-rng is both too complicated and insufficient for initial rng
seeding. It's far too complicated to use for KASLR or any other
early boot random number needs. It also
On Wed, Jul 16, 2014 at 1:20 PM, H. Peter Anvin h...@zytor.com wrote:
On 07/16/2014 09:21 AM, Gleb Natapov wrote:
On Wed, Jul 16, 2014 at 09:13:23AM -0700, H. Peter Anvin wrote:
On 07/16/2014 09:08 AM, Paolo Bonzini wrote:
Il 16/07/2014 18:03, H. Peter Anvin ha scritto:
I suggested emulating
.
- 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,x86: Add arch_get_slow_rng_u64
random: Seed
This should help solve the problem of guests starting out with
predictable RNG state.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers/char/random.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 0a7ac0a..17ad33d
without any noticeable slowdown.
This initial implementation backs it with MSR_KVM_GET_RNG_SEED if
available. The intent is for other hypervisor guest implementations
to implement this interface.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/Kconfig | 4
in a flood of
unrelated errors, and fixing it might be messy.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/boot/compressed/aslr.c | 27 +++
arch/x86/include/asm/processor.h | 21 ++---
2 files changed, 45 insertions(+), 3 deletions(-)
diff
This is useful for making sure that init_std_data is working
correctly and for allaying fear when this happens:
random: xyz urandom read with SMALL_NUMBER bits of entropy available
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers/char/random.c | 15 ---
1 file
, 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 l
On Wed, Jul 16, 2014 at 2:59 PM, H. Peter Anvin h...@zytor.com wrote:
On 07/16/2014 02:45 PM, Andy Lutomirski wrote:
diff --git a/arch/x86/include/asm/archslowrng.h
b/arch/x86/include/asm/archslowrng.h
new file mode 100644
index 000..c8e8d0d
--- /dev/null
+++ b/arch/x86/include/asm
On Wed, Jul 16, 2014 at 3:13 PM, Andy Lutomirski l...@amacapital.net wrote:
My personal preference is to defer this until some user shows up. I
think that even this would be too complicated for KASLR, which is the
only extremely early-boot user that I found.
Hmm. Does the prandom stuff want
On Jul 16, 2014 4:00 PM, H. Peter Anvin h...@zytor.com wrote:
On 07/16/2014 03:40 PM, Andy Lutomirski wrote:
On Wed, Jul 16, 2014 at 3:13 PM, Andy Lutomirski l...@amacapital.net
wrote:
My personal preference is to defer this until some user shows up. I
think that even this would be too
On Thu, Jul 17, 2014 at 9:39 AM, H. Peter Anvin h...@zytor.com wrote:
On 07/17/2014 03:33 AM, Theodore Ts'o wrote:
On Wed, Jul 16, 2014 at 09:55:15PM -0700, H. Peter Anvin wrote:
On 07/16/2014 05:03 PM, Andy Lutomirski wrote:
I meant that prandom isn't using rdrand for early seeding.
We
On Thu, Jul 17, 2014 at 10:32 AM, Theodore Ts'o ty...@mit.edu wrote:
On Thu, Jul 17, 2014 at 10:12:27AM -0700, Andy Lutomirski wrote:
Unless I'm reading the code wrong, the prandom_reseed_late call can
happen after userspace is running.
But there is also the prandom_reseed() call, which
On Thu, Jul 17, 2014 at 10:43 AM, Andrew Honig aho...@google.com wrote:
+ case MSR_KVM_GET_RNG_SEED:
+ get_random_bytes(data, sizeof(data));
+ break;
Should this be rate limited in the interest of conserving randomness?
If there ever is an attack on the
-architecture-specific use of it
that wouldn't be better served by arch_get_rng_seed.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/include/asm/archrandom.h | 6 +++
arch/x86/kernel/Makefile | 2 +
arch/x86/kernel/archrandom.c | 79
, 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 l
in a flood of
unrelated errors, and fixing it might be messy.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/boot/compressed/aslr.c | 27 +++
arch/x86/include/asm/processor.h | 21 ++---
2 files changed, 45 insertions(+), 3 deletions(-)
diff
logic on x86.
Signed-off-by: Andy Lutomirski l...@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
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
-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/Kconfig | 4
arch/x86/include/asm/kvm_guest.h | 9 +
arch/x86/kernel/archrandom.c | 22 +-
arch/x86/kernel/kvm.c| 10 ++
4 files changed, 44 insertions(+), 1 deletion
On Thu, Jul 17, 2014 at 11:42 AM, Hannes Frederic Sowa
han...@stressinduktion.org wrote:
On Thu, Jul 17, 2014, at 19:34, Andy Lutomirski wrote:
On Thu, Jul 17, 2014 at 10:32 AM, Theodore Ts'o ty...@mit.edu wrote:
On Thu, Jul 17, 2014 at 10:12:27AM -0700, Andy Lutomirski wrote:
Unless I'm
On Tue, Jul 22, 2014 at 6:59 AM, Theodore Ts'o ty...@mit.edu wrote:
On Thu, Jul 17, 2014 at 11:22:17AM -0700, Andy Lutomirski wrote:
Currently, init_std_data contains its own logic for using arch
random sources. This logic is a bit strange: it reads one long of
arch random data per byte
On Tue, Jul 22, 2014 at 1:57 PM, H. Peter Anvin h...@zytor.com wrote:
On 07/22/2014 01:44 PM, Andy Lutomirski wrote:
But, if you Intel's hardware does, in fact, work as documented, then
the current code will collect very little entropy on RDSEED-less
hardware. I see no great reason that we
On Tue, Jul 22, 2014 at 2:08 PM, H. Peter Anvin h...@zytor.com wrote:
On 07/22/2014 02:04 PM, Andy Lutomirski wrote:
Just to check: do you mean the RDRAND is very likely to work (i.e.
arch_get_random_long will return true) or that RDRAND will actually
reseed several times during
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
.
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 l...@amacapital.net
---
drivers/char/random.c | 14 +++---
include/linux/random.h
in a flood of
unrelated errors, and fixing it might be messy.
Reviewed-by: Kees Cook keesc...@chromium.org
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/boot/compressed/aslr.c | 27 +++
arch/x86/include/asm/processor.h | 21 ++---
2 files
, 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 l...@amacapital.net
---
arch/x86
-by: Andy Lutomirski l...@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
, 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 l
On Wed, Jul 23, 2014 at 9:57 PM, Andy Lutomirski l...@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
On Wed, Jul 23, 2014 at 9:57 PM, Andy Lutomirski l...@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
On Tue, Aug 12, 2014 at 12:17 PM, Theodore Ts'o ty...@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
On Aug 13, 2014 12:48 AM, H. Peter Anvin h...@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 ty...@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
On Wed, Aug 13, 2014 at 7:32 AM, Theodore Ts'o ty...@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
On Wed, Aug 13, 2014 at 11:22 AM, Theodore Ts'o ty...@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
On Wed, Aug 13, 2014 at 7:41 PM, H. Peter Anvin h...@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
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 (7):
random: Add and use arch_rng_init
random, timekeeping: Collect timekeeping entropy in the timekeeping
code
random: Reseed pools on resume
x86,kvm
in a flood of
unrelated errors, and fixing it might be messy.
Reviewed-by: Kees Cook keesc...@chromium.org
Acked-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/boot/compressed/aslr.c | 27 +++
arch/x86/include/asm
-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Andy Lutomirski l...@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
-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Andy Lutomirski l...@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
, 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_rng_init.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86
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
...@redhat.com
Signed-off-by: Andy Lutomirski l...@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
the appropriate
add_device_randomness calls to timekeeping.c instead.
Cc: John Stultz john.stu...@linaro.org
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers/char/random.c | 2 --
kernel/time/timekeeping.c | 11 +++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git
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.
Acked-by: Theodore Ts'o ty...@mit.edu
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers/char/random.c | 14
On Wed, Aug 13, 2014 at 10:43 PM, Andy Lutomirski l...@amacapital.net wrote:
Currently, init_std_data calls ktime_get_real(). This imposes
awkward constraints on when init_std_data can be called, and
init_std_data is unlikely to collect the full unpredictable data
available to the timekeeping
hpa pointed out that the ABI that I chose (an MSR from the KVM range
and a KVM cpuid bit) is unnecessarily KVM-specific. It would be nice
to allocate an MSR that everyone involved can agree on and, rather
than relying on a cpuid bit, just have the guest probe for the MSR.
This leads to a few
On Aug 28, 2014 7:17 AM, Gleb Natapov g...@kernel.org wrote:
On Tue, Aug 26, 2014 at 04:58:34PM -0700, Andy Lutomirski wrote:
hpa pointed out that the ABI that I chose (an MSR from the KVM range
and a KVM cpuid bit) is unnecessarily KVM-specific. It would be nice
to allocate an MSR
On Thu, Aug 28, 2014 at 12:46 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 28/08/2014 18:22, Andy Lutomirski ha scritto:
Is there a non-cpuid interface between QEMU and KVM for this?
No.
Hmm. Then, assuming that someone manages to allocate a
cross-hypervisor MSR number for this, what am I
mechanism.
If we do the latter, I don't know what that mechanism would be.
NB: This thread will be cc'd to Microsoft and possibly Hyper-V people
shortly. I very much appreciate Jun Nakajima's help with this!
Thanks,
Andy
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from
probably need something new.
--Andy
-hpa
--
Andy Lutomirski
AMA Capital Management, LLC
--
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
On Thu, Sep 18, 2014 at 8:38 AM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, Sep 18, 2014 at 7:43 AM, H. Peter Anvin h...@zytor.com wrote:
On 09/18/2014 07:40 AM, KY Srinivasan wrote:
The main questions are what MSR index to use and how to detect the
presence of the MSR. I've played
, 2014 10:18 AM
To: Nakajima, Jun; KY Srinivasan
Cc: Mathew John; Theodore Ts'o; John Starks; kvm list; Gleb Natapov; Niels
Ferguson; Andy Lutomirski; David Hepkin; H. Peter Anvin; Jake Oshins; Linux
Virtualization
Subject: Re: Standardizing an MSR or other hypercall to get an RNG seed?
Il 18/09
On Thu, Sep 18, 2014 at 11:54 AM, Niels Ferguson ni...@microsoft.com wrote:
Defining a standard way of transferring random numbers between the host and
the guest is an excellent idea.
As the person who writes the RNG code in Windows, I have a few comments:
DETECTION:
It should be possible
On Thu, Sep 18, 2014 at 11:58 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Actually, that MSR address range has been reserved for that purpose, along
with:
- CPUID.EAX=1 - ECX bit 31 (always returns 0 on bare metal)
- CPUID.EAX=4000_00xxH leaves (i.e. HYPERVISOR CPUID)
I don't know
On Thu, Sep 18, 2014 at 2:21 PM, Nakajima, Jun jun.nakaj...@intel.com wrote:
On Thu, Sep 18, 2014 at 12:07 PM, Andy Lutomirski l...@amacapital.net wrote:
Might Intel be willing to extend that range to 0x4000 -
0x400f? And would Microsoft be okay with using this mechanism
On Thu, Sep 18, 2014 at 2:46 PM, David Hepkin david...@microsoft.com wrote:
I'm not sure what you mean by this mechanism? Are you suggesting that each
hypervisor put CrossHVPara\0 somewhere in the 0x4000 - 0x400f CPUID
range, and an OS has to do a full scan of this CPUID range on
On Thu, Sep 18, 2014 at 2:57 PM, H. Peter Anvin h...@zytor.com wrote:
On 09/18/2014 02:46 PM, David Hepkin wrote:
I'm not sure what you mean by this mechanism? Are you suggesting that
each hypervisor put CrossHVPara\0 somewhere in the 0x4000 - 0x400f
CPUID range, and an OS has to do
1 - 100 of 391 matches
Mail list logo
