linux-stable.git/arch/x86/kernel/kvmclock.c, branch linux-3.16.y

x86/vdso: Remove pvclock fixmap machinery

2018-02-13T18:42:35+00:00

commit cc1e24fdb064d3126a494716f22ad4fc39306742 upstream.

Signed-off-by: Andy Lutomirski 
Reviewed-by: Paolo Bonzini 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/4933029991103ae44672c82b97a20035f5c1fe4f.1449702533.git.luto@kernel.org
Signed-off-by: Ingo Molnar 
[bwh: Backported to 3.16: adjust filenames, context]
Signed-off-by: Ben Hutchings

Revert "x86: kvmclock: Disable use from vDSO if KPTI is enabled"

2018-02-13T18:42:34+00:00

This reverts commit abe3029e4febfa18e4a9562a792465182b3992a0.

Signed-off-by: Juerg Haefliger 
Signed-off-by: Ben Hutchings

x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap

2018-02-13T18:42:34+00:00

commit dac16fba6fc590fa7239676b35ed75dae4c4cd2b upstream.

Signed-off-by: Andy Lutomirski 
Reviewed-by: Paolo Bonzini 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/9d37826fdc7e2d2809efe31d5345f97186859284.1449702533.git.luto@kernel.org
Signed-off-by: Ingo Molnar 
[bwh: Backported to 3.16: adjust filenames]
Signed-off-by: Ben Hutchings

x86: kvmclock: Disable use from vDSO if KPTI is enabled

2018-01-09T00:35:14+00:00

Currently the pvclock pages aren't being added to user-space page
tables, and my attempt to fix this didn't work.

Signed-off-by: Ben Hutchings

x86, kvm: Clear paravirt_enabled on KVM guests for espfix32's benefit

2015-01-15T10:43:49+00:00

commit 29fa6825463c97e5157284db80107d1bfac5d77b upstream.

paravirt_enabled has the following effects:

 - Disables the F00F bug workaround warning.  There is no F00F bug
   workaround any more because Linux's standard IDT handling already
   works around the F00F bug, but the warning still exists.  This
   is only cosmetic, and, in any event, there is no such thing as
   KVM on a CPU with the F00F bug.

 - Disables 32-bit APM BIOS detection.  On a KVM paravirt system,
   there should be no APM BIOS anyway.

 - Disables tboot.  I think that the tboot code should check the
   CPUID hypervisor bit directly if it matters.

 - paravirt_enabled disables espfix32.  espfix32 should *not* be
   disabled under KVM paravirt.

The last point is the purpose of this patch.  It fixes a leak of the
high 16 bits of the kernel stack address on 32-bit KVM paravirt
guests.  Fixes CVE-2014-8134.

Suggested-by: Konrad Rzeszutek Wilk 
Signed-off-by: Andy Lutomirski 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Luis Henriques

kvm: remove redundant registration of BSP's hv_clock area

2014-02-22T14:53:32+00:00

These days hv_clock allocation is memblock based (i.e. the percpu
allocator is not involved), which means that the physical address
of each of the per-cpu hv_clock areas is guaranteed to remain
unchanged through all its lifetime and we do not need to update
its location after CPU bring-up.

Signed-off-by: Fernando Luis Vazquez Cao 
Signed-off-by: Paolo Bonzini

pvclock: detect watchdog reset at pvclock read

2013-11-06T07:48:43+00:00

Implement reset of kernel watchdogs at pvclock read time. This avoids
adding special code to every watchdog.

This is possible for watchdogs which measure time based on sched_clock() or
ktime_get() variants.

Suggested by Don Zickus.

Acked-by: Don Zickus 
Acked-by: Paolo Bonzini 
Signed-off-by: Marcelo Tosatti 
Signed-off-by: Gleb Natapov

x86: delete __cpuinit usage from all x86 files

2013-07-14T23:36:56+00:00

The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications.  For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.

After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out.  Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.

Note that some harmless section mismatch warnings may result, since
notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
are flagged as __cpuinit  -- so if we remove the __cpuinit from
arch specific callers, we will also get section mismatch warnings.
As an intermediate step, we intend to turn the linux/init.h cpuinit
content into no-ops as early as possible, since that will get rid
of these warnings.  In any case, they are temporary and harmless.

This removes all the arch/x86 uses of the __cpuinit macros from
all C files.  x86 only had the one __CPUINIT used in assembly files,
and it wasn't paired off with a .previous or a __FINIT, so we can
delete it directly w/o any corresponding additional change there.

[1] https://lkml.org/lkml/2013/5/20/589

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x86@kernel.org
Acked-by: Ingo Molnar 
Acked-by: Thomas Gleixner 
Acked-by: H. Peter Anvin 
Signed-off-by: Paul Gortmaker

Merge branch 'timers/posix-cpu-timers-for-tglx' of

2013-07-04T21:11:22+00:00

git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks into timers/core

Frederic sayed: "Most of these patches have been hanging around for
several month now, in -mmotm for a significant chunk. They already
missed a few releases."

Signed-off-by: Thomas Gleixner

x86: kvmclock: zero initialize pvclock shared memory area

2013-06-19T10:25:28+00:00

kernel might hung in pvclock_clocksource_read() due to
uninitialized memory might contain odd version value in
following cycle:

        do {
                version = __pvclock_read_cycles(src, &ret, &flags);
        } while ((src->version & 1) || version != src->version);

if secondary kvmclock is accessed before it's registered with kvm.

Clear garbage in pvclock shared memory area right after it's
allocated to avoid this issue.

Ref: https://bugzilla.kernel.org/show_bug.cgi?id=59521
Signed-off-by: Igor Mammedov 
[See BZ for analysis.  We may want a different fix for 3.11, but
 this is the safest for now - Paolo]
Cc:  # 3.8
Signed-off-by: Paolo Bonzini