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 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 curre
On Thu, Jan 3, 2013 at 5:41 AM, Marcelo Tosatti 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 space.
>
> Sig
ideas?
I'll try 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 wrote:
> On (Tue) 14 Feb 2012 [08:26:22], Andy Lutomirski wrote:
>> On Tue, Feb 14, 2012 at 4:22 AM, Amit Shah wrote:
>> Can you try booting t
On Thu, Feb 16, 2012 at 8:17 AM, Avi Kivity 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
>> wi
On Thu, Feb 16, 2012 at 9:14 AM, Avi Kivity 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 d
ional -- it's how
vsyscall emulation works.
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 t
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
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
---
I'm not 100% sure what's happening in the KVM code. Can someone fam
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 someb
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
>
ng 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
This should help solve the problem of guests starting out with
predictable RNG state.
Signed-off-by: Andy Lutomirski
---
drivers/char/random.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 0a7ac0a..bd88a24
boot 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
---
arch/x86/Kconfig | 4
arch/x86/includ
It's considerably better than any of the alternatives on KVM.
Signed-off-by: Andy Lutomirski
---
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
index fc
Signed-off-by: Andy Lutomirski
---
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/get_rng_seed.c
diff --git a
On Wed, Jul 16, 2014 at 12:36 AM, Paolo Bonzini 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:
>>>>
>>>> v
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
---
linux-headers/asm-x86/kvm_para.h | 2 ++
target-i386/cpu.c| 5 +++--
2 files changed, 5 insertions(+), 2 deletions(-)
On Wed, Jul 16, 2014 at 7:32 AM, Paolo Bonzini 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 RDRA
, 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
.c results in a flood of
unrelated errors, and fixing it might be messy.
Signed-off-by: Andy Lutomirski
---
arch/x86/boot/compressed/aslr.c | 27 +++
arch/x86/include/asm/processor.h | 21 ++---
2 files changed, 45 insertions(+), 3 deletions(-)
diff --git
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
---
drivers/char/random.c | 14 +++---
1 file changed, 11 insertions
boot 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
---
arch/x86/Kconfig | 4
arch/x86/includ
This should help solve the problem of guests starting out with
predictable RNG state.
Signed-off-by: Andy Lutomirski
---
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 100644
--- a/drivers
n the same 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_GE
On Wed, Jul 16, 2014 at 11:02 AM, Bandan Das wrote:
> Andy Lutomirski 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 al
On Wed, Jul 16, 2014 at 1:20 PM, H. Peter Anvin 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
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,x86: Add arch_get_slow_rng_u64
ra
This should help solve the problem of guests starting out with
predictable RNG state.
Signed-off-by: Andy Lutomirski
---
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 100644
--- a/drivers
boot 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
---
arch/x86/Kconfig | 4
arch/x86/includ
.c results in a flood of
unrelated errors, and fixing it might be messy.
Signed-off-by: Andy Lutomirski
---
arch/x86/boot/compressed/aslr.c | 27 +++
arch/x86/include/asm/processor.h | 21 ++---
2 files changed, 45 insertions(+), 3 deletions(-)
diff --git
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
---
drivers/char/random.c | 15 ---
1 file changed, 12 insertions
, 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
On Wed, Jul 16, 2014 at 2:59 PM, H. Peter Anvin 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/n
On Wed, Jul 16, 2014 at 3:13 PM, Andy Lutomirski 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 w
On Jul 16, 2014 4:00 PM, "H. Peter Anvin" wrote:
>
> On 07/16/2014 03:40 PM, Andy Lutomirski wrote:
> > On Wed, Jul 16, 2014 at 3:13 PM, Andy Lutomirski
> > wrote:
> >> My personal preference is to defer this until some user shows up. I
> >> thi
On Thu, Jul 17, 2014 at 9:39 AM, H. Peter Anvin 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
On Thu, Jul 17, 2014 at 10:32 AM, Theodore Ts'o 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
On Thu, Jul 17, 2014 at 10:43 AM, Andrew Honig 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 prng, this w
a sensible non-architecture-specific use of it
that wouldn't be better served by arch_get_rng_seed.
Signed-off-by: Andy Lutomirski
---
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
.c results in a flood of
unrelated errors, and fixing it might be messy.
Signed-off-by: Andy Lutomirski
---
arch/x86/boot/compressed/aslr.c | 27 +++
arch/x86/include/asm/processor.h | 21 ++---
2 files changed, 45 insertions(+), 3 deletions(-)
diff --git
rrect logic on x86.
Signed-off-by: Andy Lutomirski
---
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..be
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 ar
ff-by: Andy Lutomirski
---
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(-)
diff --git a/arc
On Thu, Jul 17, 2014 at 11:42 AM, Hannes Frederic Sowa
wrote:
>
>
> On Thu, Jul 17, 2014, at 19:34, Andy Lutomirski wrote:
>> On Thu, Jul 17, 2014 at 10:32 AM, Theodore Ts'o wrote:
>> > On Thu, Jul 17, 2014 at 10:12:27AM -0700, Andy Lutomirski wrote:
>> >>
On Tue, Jul 22, 2014 at 6:59 AM, Theodore Ts'o 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
On Tue, Jul 22, 2014 at 1:57 PM, H. Peter Anvin 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 se
On Tue, Jul 22, 2014 at 2:08 PM, H. Peter Anvin 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
ntially 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 ka
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
---
drivers/char/random.c | 14 +++---
include/linux/random.h | 40
.c results in a flood of
unrelated errors, and fixing it might be messy.
Reviewed-by: Kees Cook
Signed-off-by: Andy Lutomirski
---
arch/x86/boot/compressed/aslr.c | 27 +++
arch/x86/include/asm/processor.h | 21 ++---
2 files changed, 45 insertions(
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
---
arch/
ff-by: Andy Lutomirski
---
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
, 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
On Wed, Jul 23, 2014 at 9:57 PM, 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 implemen
On Wed, Jul 23, 2014 at 9:57 PM, Andy Lutomirski 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
>
On Tue, Aug 12, 2014 at 12:17 PM, Theodore Ts'o 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 tr
On Aug 13, 2014 12:48 AM, "H. Peter Anvin" wrote:
>
> On 08/12/2014 12:22 PM, Andy Lutomirski wrote:
> > On Tue, Aug 12, 2014 at 12:17 PM, Theodore Ts'o wrote:
> >> On Tue, Aug 12, 2014 at 12:11:29PM -0700, Andy Lutomirski wrote:
> >>>
> >&g
On Wed, Aug 13, 2014 at 7:32 AM, Theodore Ts'o 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 f
On Wed, Aug 13, 2014 at 11:22 AM, Theodore Ts'o 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 secon
On Wed, Aug 13, 2014 at 7:41 PM, H. Peter Anvin 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 e
iption 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 (7):
random: Add and use arch_rng_init
random, timekeeping: Collect timekeeping entropy in the timekeeping
code
random: Reseed pools on r
.c results in a flood of
unrelated errors, and fixing it might be messy.
Reviewed-by: Kees Cook
Acked-by: Paolo Bonzini
Signed-off-by: Andy Lutomirski
---
arch/x86/boot/compressed/aslr.c | 27 +++
arch/x86/include/asm/processor.h | 21 ++---
2 fi
ed-by: Paolo Bonzini
Signed-off-by: Andy Lutomirski
---
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(
ed-by: Paolo Bonzini
Signed-off-by: Andy Lutomirski
---
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(
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
---
arch/x86/include/a
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
---
drivers/char/random.c | 26
Signed-off-by: Andy Lutomirski
---
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/v
appropriate
add_device_randomness calls to timekeeping.c instead.
Cc: John Stultz
Signed-off-by: Andy Lutomirski
---
drivers/char/random.c | 2 --
kernel/time/timekeeping.c | 11 +++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char
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
Signed-off-by: Andy Lutomirski
---
drivers/char/random.c | 14 +++---
include/
On Wed, Aug 13, 2014 at 10:43 PM, Andy Lutomirski 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 time
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 ques
On Aug 28, 2014 7:17 AM, "Gleb Natapov" 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
On Thu, Aug 28, 2014 at 12:46 PM, Paolo Bonzini 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 a
Enabling CONFIG_PARAVIRT had an unintended side effect: rdmsr turned
into rdmsr_safe and wrmsr turned into wrmsr_safe, even on bare
metal. Undo that by using the new unsafe paravirt MSR hooks.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/paravirt.h | 9 +++--
1 file changed, 3
These hooks match the _safe variants, so name them accordingly.
This will make room for unsafe PV hooks.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/paravirt.h | 33 +
arch/x86/include/asm/paravirt_types.h | 8
arch/x86/kernel
n. I think that
should be done separately by the Xen maintainers.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/paravirt.h | 11 +++
arch/x86/include/asm/paravirt_types.h | 10 --
arch/x86/kernel/paravirt.c| 2 ++
arch/x86/xen/enlighten.c
would probably make
Arjan and the rest of the Clear Containers people happy :)
Andy Lutomirski (3):
x86/paravirt: Add _safe to the read_msr and write_msr PV hooks
x86/paravirt: Add paravirt_{read,write}_msr
x86/paravirt: Make "unsafe" MSR accesses unsafe even if PARAVIRT=y
arch/x
On Sep 17, 2015 5:33 AM, "Peter Zijlstra" wrote:
>
> On Thu, Sep 17, 2015 at 01:40:30PM +0200, Paolo Bonzini wrote:
> >
> >
> > On 17/09/2015 10:58, Peter Zijlstra wrote:
> > > But the far greater problem I have with the whole virt thing is that
> > > you cannot use rdmsr_safe() to probe if an MSR
On Thu, Sep 17, 2015 at 12:19 AM, Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
>> Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently
>> turns all rdmsr and wrmsr operations into the safe variants without
>> any checks that the operations actually
On Thu, Sep 17, 2015 at 8:17 AM, Peter Zijlstra wrote:
> On Thu, Sep 17, 2015 at 08:17:18AM -0700, Andy Lutomirski wrote:
>
>> > Ah, that would be good news. Andy earlier argued I could not rely on
>> > rdmsr_safe() faulting on unknown MSRs. If practically we can ther
On Thu, Sep 17, 2015 at 10:30 AM, Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
>> On Thu, Sep 17, 2015 at 12:19 AM, Ingo Molnar wrote:
>> >
>> > * Andy Lutomirski wrote:
>> >
>> >> Setting CONFIG_PARAVIRT=y has an unintended si
On Thu, Sep 17, 2015 at 1:10 PM, Konrad Rzeszutek Wilk
wrote:
> On Wed, Sep 16, 2015 at 06:39:03PM -0400, Cole Robinson wrote:
>> On 09/16/2015 05:08 PM, Konrad Rzeszutek Wilk wrote:
>> > On Wed, Sep 16, 2015 at 05:04:31PM -0400, Cole Robinson wrote:
>> >> On 09/16/2015 04:07 PM, M A Young wrote:
This applies on top of my earlier MSR series.
Andy Lutomirski (2):
x86/msr: Carry on after a non-"safe" MSR access fails without
!panic_on_oops
x86/msr: Set the return value to zero when native_rdmsr_safe fails
arch/x86/include/asm/msr.h | 5 -
arch/x86/kernel/traps
This will cause unchecked native_rdmsr_safe failures to return
deterministic results.
We could poison the results with something other than zero, but that
would increase code size.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/msr.h | 5 -
1 file changed, 4 insertions(+), 1
o minimize the chance of nasty undebuggable failures due on
systems that used to work due to a now-fixed CONFIG_PARAVIRT=y bug.
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/traps.c | 51 +
1 file changed, 51 insertions(+)
diff --git a/arch/
On Fri, Sep 18, 2015 at 6:54 AM, Borislav Petkov wrote:
> On Thu, Sep 17, 2015 at 01:23:31PM -0700, Andy Lutomirski wrote:
>> Cc: Borislav. Is TSEG guaranteed to exist? Can we defer that until
>
> Why not? It is the tseg base address.
>
> I think this is kvm injecti
This will cause unchecked native_rdmsr_safe failures to return
deterministic results.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/msr.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 77d8b284e4a7
This applies on top of my earlier paravirt MSR series.
Changes from v1:
- Return zero instead of poison on bad RDMSRs.
Andy Lutomirski (2):
x86/msr: Carry on after a non-"safe" MSR access fails without
!panic_on_oops
x86/msr: Set the return value to zero when native_rdmsr_
chance of nasty undebuggable failures due on
systems that used to work due to a now-fixed CONFIG_PARAVIRT=y bug.
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/traps.c | 55 +
1 file changed, 55 insertions(+)
diff --git a/arch/x86/kernel/trap
On Sep 20, 2015 5:15 PM, "Linus Torvalds" wrote:
>
> On Sun, Sep 20, 2015 at 5:02 PM, Andy Lutomirski wrote:
> > This demotes an OOPS and likely panic due to a failed non-"safe" MSR
> > access to a WARN_ON_ONCE and a return of zero (in the RDMSR cas
On Fri, Sep 18, 2015 at 12:04 PM, Borislav Petkov wrote:
> On Fri, Sep 18, 2015 at 08:20:46AM -0700, Andy Lutomirski wrote:
>> In any event, Borislav, you must have typed rdmsr_safe for a reason :)
>
> Wasn't me:
>
> 6c62aa4a3c12 ("x86: make amd.c have 64bit suppo
On Mon, Sep 21, 2015 at 9:49 AM, Arjan van de Ven wrote:
> On 9/21/2015 9:36 AM, Linus Torvalds wrote:
>>
>> On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote:
>>>
>>>
>>> Linus, what's your preference?
>>
>>
>> So quite frankly, is there any reason we don't just implement
>> native_read_msr() a
On Mon, Sep 21, 2015 at 9:36 AM, Linus Torvalds
wrote:
> On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote:
>>
>> Linus, what's your preference?
>
> So quite frankly, is there any reason we don't just implement
> native_read_msr() as just
>
>unsigned long long native_read_msr(unsigned int ms
On Tue, Sep 22, 2015 at 11:23 AM, Konrad Rzeszutek Wilk
wrote:
> On Sun, Sep 20, 2015 at 09:49:04PM -0700, Andy Lutomirski wrote:
>> On Fri, Sep 18, 2015 at 12:04 PM, Borislav Petkov wrote:
>> > On Fri, Sep 18, 2015 at 08:20:46AM -0700, Andy Lutomirski wrote:
>> >&g
On Sep 29, 2015 2:01 AM, "Ingo Molnar" wrote:
>
>
> * Denys Vlasenko wrote:
>
> > On 09/28/2015 09:58 AM, Ingo Molnar wrote:
> > >
> > > * Denys Vlasenko wrote:
> > >
> > >> On 09/26/2015 09:50 PM, H. Peter Anvin wrote:
> > >>> NAK. We really should map the GDT read-only on all 64 bit systems,
On Tue, Sep 29, 2015 at 10:50 AM, Linus Torvalds
wrote:
> On Tue, Sep 29, 2015 at 1:35 PM, Andy Lutomirski wrote:
>>
>> Does anyone know what happens if you stick a non-accessed segment in
>> the GDT, map the GDT RO, and access it?
>
> You should get a #PF, as you gues
On Tue, Sep 29, 2015 at 11:18 AM, H. Peter Anvin wrote:
> SGDT would be easy to use, and it is logical that it is faster since it reads
> an internal register. SIDT does too but unlike the GDT has a secondary limit
> (it can never be larger than 4096 bytes) and so all limits in the range
> 409
1 - 100 of 392 matches
Mail list logo
