Levin, Alexander (Sasha Levin)
2abfcdf8e7
kmemcheck: remove annotations
...
commit 4950276672 upstream.
Patch series "kmemcheck: kill kmemcheck", v2.
As discussed at LSF/MM, kill kmemcheck.
KASan is a replacement that is able to work without the limitation of
kmemcheck (single CPU, slow). KASan is already upstream.
We are also not aware of any users of kmemcheck (or users who don't
consider KASan as a suitable replacement).
The only objection was that since KASAN wasn't supported by all GCC
versions provided by distros at that time we should hold off for 2
years, and try again.
Now that 2 years have passed, and all distros provide gcc that supports
KASAN, kill kmemcheck again for the very same reasons.
This patch (of 4):
Remove kmemcheck annotations, and calls to kmemcheck from the kernel.
[alexander.levin@verizon.com: correctly remove kmemcheck call from dma_map_sg_attrs]
Link: http://lkml.kernel.org/r/20171012192151.26531-1-alexander.levin@verizon.com
Link: http://lkml.kernel.org/r/20171007030159.22241-2-alexander.levin@verizon.com
Signed-off-by: Sasha Levin <alexander.levin@verizon.com >
Cc: Alexander Potapenko <glider@google.com >
Cc: Eric W. Biederman <ebiederm@xmission.com >
Cc: Michal Hocko <mhocko@kernel.org >
Cc: Pekka Enberg <penberg@kernel.org >
Cc: Steven Rostedt <rostedt@goodmis.org >
Cc: Tim Hansen <devtimhansen@gmail.com >
Cc: Vegard Nossum <vegardno@ifi.uio.no >
Signed-off-by: Andrew Morton <akpm@linux-foundation.org >
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:23 +01:00
Peter Zijlstra
1fed58f610
x86/speculation: Add <asm/msr-index.h> dependency
...
commit ea00f30128 upstream.
Joe Konno reported a compile failure resulting from using an MSR
without inclusion of <asm/msr-index.h>, and while the current code builds
fine (by accident) this needs fixing for future patches.
Reported-by: Joe Konno <joe.konno@linux.intel.com >
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: arjan@linux.intel.com
Cc: bp@alien8.de
Cc: dan.j.williams@intel.com
Cc: dave.hansen@linux.intel.com
Cc: dwmw2@infradead.org
Cc: dwmw@amazon.co.uk
Cc: gregkh@linuxfoundation.org
Cc: hpa@zytor.com
Cc: jpoimboe@redhat.com
Cc: linux-tip-commits@vger.kernel.org
Cc: luto@kernel.org
Fixes: 20ffa1caec ("x86/speculation: Add basic IBPB (Indirect Branch Prediction Barrier) support")
Link: http://lkml.kernel.org/r/20180213132819.GJ25201@hirez.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:23 +01:00
Will Deacon
8b4cdbbb29
nospec: Move array_index_nospec() parameter checking into separate macro
...
commit 8fa80c503b upstream.
For architectures providing their own implementation of
array_index_mask_nospec() in asm/barrier.h, attempting to use WARN_ONCE() to
complain about out-of-range parameters using WARN_ON() results in a mess
of mutually-dependent include files.
Rather than unpick the dependencies, simply have the core code in nospec.h
perform the checking for us.
Signed-off-by: Will Deacon <will.deacon@arm.com >
Acked-by: Thomas Gleixner <tglx@linutronix.de >
Cc: Dan Williams <dan.j.williams@intel.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Link: http://lkml.kernel.org/r/1517840166-15399-1-git-send-email-will.deacon@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:23 +01:00
Dan Williams
9d4cb4dc7a
x86/speculation: Fix up array_index_nospec_mask() asm constraint
...
commit be3233fbfc upstream.
Allow the compiler to handle @size as an immediate value or memory
directly rather than allocating a register.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org >
Signed-off-by: Dan Williams <dan.j.williams@intel.com >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Link: http://lkml.kernel.org/r/151797010204.1289.1510000292250184993.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:23 +01:00
Peter Zijlstra
41d3154825
x86/debug: Use UD2 for WARN()
...
commit 3b3a371cc9 upstream.
Since the Intel SDM added an ModR/M byte to UD0 and binutils followed
that specification, we now cannot disassemble our kernel anymore.
This now means Intel and AMD disagree on the encoding of UD0. And instead
of playing games with additional bytes that are valid ModR/M and single
byte instructions (0xd6 for instance), simply use UD2 for both WARN() and
BUG().
Requested-by: Linus Torvalds <torvalds@linux-foundation.org >
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org >
Acked-by: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Arjan van de Ven <arjan@linux.intel.com >
Cc: Borislav Petkov <bp@alien8.de >
Cc: Brian Gerst <brgerst@gmail.com >
Cc: Denys Vlasenko <dvlasenk@redhat.com >
Cc: H. Peter Anvin <hpa@zytor.com >
Cc: Josh Poimboeuf <jpoimboe@redhat.com >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Link: http://lkml.kernel.org/r/20180208194406.GD25181@hirez.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:23 +01:00
Josh Poimboeuf
4e0067c22d
x86/debug, objtool: Annotate WARN()-related UD2 as reachable
...
commit 2b5db66862 upstream.
By default, objtool assumes that a UD2 is a dead end. This is mainly
because GCC 7+ sometimes inserts a UD2 when it detects a divide-by-zero
condition.
Now that WARN() is moving back to UD2, annotate the code after it as
reachable so objtool can follow the code flow.
Reported-by: Borislav Petkov <bp@alien8.de >
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com >
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Arjan van de Ven <arjan@linux.intel.com >
Cc: Brian Gerst <brgerst@gmail.com >
Cc: Denys Vlasenko <dvlasenk@redhat.com >
Cc: H. Peter Anvin <hpa@zytor.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: kbuild test robot <fengguang.wu@intel.com >
Link: http://lkml.kernel.org/r/0e483379275a42626ba8898117f918e1bf661e40.1518130694.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:22 +01:00
Josh Poimboeuf
842a0d95ef
objtool: Fix segfault in ignore_unreachable_insn()
...
commit fe24e27128 upstream.
Peter Zijlstra's patch for converting WARN() to use UD2 triggered a
bunch of false "unreachable instruction" warnings, which then triggered
a seg fault in ignore_unreachable_insn().
The seg fault happened when it tried to dereference a NULL 'insn->func'
pointer. Thanks to static_cpu_has(), some functions can jump to a
non-function area in the .altinstr_aux section. That breaks
ignore_unreachable_insn()'s assumption that it's always inside the
original function.
Make sure ignore_unreachable_insn() only follows jumps within the
current function.
Reported-by: Borislav Petkov <bp@alien8.de >
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com >
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Arjan van de Ven <arjan@linux.intel.com >
Cc: Brian Gerst <brgerst@gmail.com >
Cc: Denys Vlasenko <dvlasenk@redhat.com >
Cc: H. Peter Anvin <hpa@zytor.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: kbuild test robot <fengguang.wu@intel.com >
Link: http://lkml.kernel.org/r/bace77a60d5af9b45eddb8f8fb9c776c8de657ef.1518130694.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:22 +01:00
Dominik Brodowski
410d273ecc
selftests/x86: Disable tests requiring 32-bit support on pure 64-bit systems
...
commit 9279ddf23c upstream.
The ldt_gdt and ptrace_syscall selftests, even in their 64-bit variant, use
hard-coded 32-bit syscall numbers and call "int $0x80".
This will fail on 64-bit systems with CONFIG_IA32_EMULATION=y disabled.
Therefore, do not build these tests if we cannot build 32-bit binaries
(which should be a good approximation for CONFIG_IA32_EMULATION=y being enabled).
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Dmitry Safonov <dsafonov@virtuozzo.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: linux-kselftest@vger.kernel.org
Cc: shuah@kernel.org
Link: http://lkml.kernel.org/r/20180211111013.16888-6-linux@dominikbrodowski.net
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:22 +01:00
Dominik Brodowski
8520ea2a04
selftests/x86: Do not rely on "int $0x80" in single_step_syscall.c
...
commit 4105c69703 upstream.
On 64-bit builds, we should not rely on "int $0x80" working (it only does if
CONFIG_IA32_EMULATION=y is enabled). To keep the "Set TF and check int80"
test running on 64-bit installs with CONFIG_IA32_EMULATION=y enabled, build
this test only if we can also build 32-bit binaries (which should be a
good approximation for that).
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Dmitry Safonov <dsafonov@virtuozzo.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: linux-kselftest@vger.kernel.org
Cc: shuah@kernel.org
Link: http://lkml.kernel.org/r/20180211111013.16888-5-linux@dominikbrodowski.net
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:22 +01:00
Dominik Brodowski
cf4db6342d
selftests/x86: Do not rely on "int $0x80" in test_mremap_vdso.c
...
commit 2cbc0d66de upstream.
On 64-bit builds, we should not rely on "int $0x80" working (it only does if
CONFIG_IA32_EMULATION=y is enabled).
Without this patch, the move test may succeed, but the "int $0x80" causes
a segfault, resulting in a false negative output of this self-test.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Dmitry Safonov <dsafonov@virtuozzo.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: linux-kselftest@vger.kernel.org
Cc: shuah@kernel.org
Link: http://lkml.kernel.org/r/20180211111013.16888-4-linux@dominikbrodowski.net
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:22 +01:00
Ingo Molnar
e6eced764e
selftests/x86/pkeys: Remove unused functions
...
commit ce676638fe upstream.
This also gets rid of two build warnings:
protection_keys.c: In function ‘dumpit’:
protection_keys.c:419:3: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
write(1, buf, nr_read);
^~~~~~~~~~~~~~~~~~~~~~
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: Dave Hansen <dave.hansen@linux.intel.com >
Cc: Shuah Khan <shuahkh@osg.samsung.com >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:22 +01:00
Dominik Brodowski
3eb95d5187
selftests/x86: Clean up and document sscanf() usage
...
commit d8e92de8ef upstream.
Replace a couple of magically connected buffer length literal constants with
a common definition that makes their relationship obvious. Also document
why our sscanf() usage is safe.
No intended functional changes.
Suggested-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net >
Cc: Andrew Lutomirski <luto@kernel.org >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: linux-kselftest@vger.kernel.org
Cc: shuah@kernel.org
Link: http://lkml.kernel.org/r/20180211205924.GA23210@light.dominikbrodowski.net
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:22 +01:00
Dominik Brodowski
301e6fe091
selftests/x86: Fix vDSO selftest segfault for vsyscall=none
...
commit 198ee8e175 upstream.
The vDSO selftest tries to execute a vsyscall unconditionally, even if it
is not present on the test system (e.g. if booted with vsyscall=none or
with CONFIG_LEGACY_VSYSCALL_NONE=y set. Fix this by copying (and tweaking)
the vsyscall check from test_vsyscall.c
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net >
Cc: Andrew Lutomirski <luto@kernel.org >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: linux-kselftest@vger.kernel.org
Cc: shuah@kernel.org
Link: http://lkml.kernel.org/r/20180211111013.16888-3-linux@dominikbrodowski.net
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:22 +01:00
Borislav Petkov
5cf7b883bc
x86/entry/64: Remove the unused 'icebp' macro
...
commit b498c26110 upstream.
That macro was touched around 2.5.8 times, judging by the full history
linux repo, but it was unused even then. Get rid of it already.
Signed-off-by: Borislav Petkov <bp@suse.de >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Borislav Petkov <bp@alien8.de >
Cc: Brian Gerst <brgerst@gmail.com >
Cc: Denys Vlasenko <dvlasenk@redhat.com >
Cc: H. Peter Anvin <hpa@zytor.com >
Cc: Josh Poimboeuf <jpoimboe@redhat.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: linux@dominikbrodowski.net
Link: http://lkml.kernel.org/r/20180212201318.GD14640@pd.tnic
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:22 +01:00
Josh Poimboeuf
bdcf05c64a
x86/entry/64: Fix paranoid_entry() frame pointer warning
...
commit b3ccefaed9 upstream.
With the following commit:
f09d160992d1 ("x86/entry/64: Get rid of the ALLOC_PT_GPREGS_ON_STACK and SAVE_AND_CLEAR_REGS macros")
... one of my suggested improvements triggered a frame pointer warning:
arch/x86/entry/entry_64.o: warning: objtool: paranoid_entry()+0x11: call without frame pointer save/setup
The warning is correct for the build-time code, but it's actually not
relevant at runtime because of paravirt patching. The paravirt swapgs
call gets replaced with either a SWAPGS instruction or NOPs at runtime.
Go back to the previous behavior by removing the ELF function annotation
for paranoid_entry() and adding an unwind hint, which effectively
silences the warning.
Reported-by: kbuild test robot <fengguang.wu@intel.com >
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com >
Cc: Dominik Brodowski <linux@dominikbrodowski.net >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: kbuild-all@01.org
Cc: tipbuild@zytor.com
Fixes: f09d160992d1 ("x86/entry/64: Get rid of the ALLOC_PT_GPREGS_ON_STACK and SAVE_AND_CLEAR_REGS macros")
Link: http://lkml.kernel.org/r/20180212174503.5acbymg5z6p32snu@treble
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:21 +01:00
Dominik Brodowski
a816dd2fa2
x86/entry/64: Indent PUSH_AND_CLEAR_REGS and POP_REGS properly
...
commit 92816f571a upstream.
... same as the other macros in arch/x86/entry/calling.h
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Borislav Petkov <bp@alien8.de >
Cc: Brian Gerst <brgerst@gmail.com >
Cc: Denys Vlasenko <dvlasenk@redhat.com >
Cc: H. Peter Anvin <hpa@zytor.com >
Cc: Josh Poimboeuf <jpoimboe@redhat.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: dan.j.williams@intel.com
Link: http://lkml.kernel.org/r/20180211104949.12992-8-linux@dominikbrodowski.net
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:21 +01:00
Dominik Brodowski
de66c3a3b0
x86/entry/64: Get rid of the ALLOC_PT_GPREGS_ON_STACK and SAVE_AND_CLEAR_REGS macros
...
commit dde3036d62 upstream.
Previously, error_entry() and paranoid_entry() saved the GP registers
onto stack space previously allocated by its callers. Combine these two
steps in the callers, and use the generic PUSH_AND_CLEAR_REGS macro
for that.
This adds a significant amount ot text size. However, Ingo Molnar points
out that:
"these numbers also _very_ significantly over-represent the
extra footprint. The assumptions that resulted in
us compressing the IRQ entry code have changed very
significantly with the new x86 IRQ allocation code we
introduced in the last year:
- IRQ vectors are usually populated in tightly clustered
groups.
With our new vector allocator code the typical per CPU
allocation percentage on x86 systems is ~3 device vectors
and ~10 fixed vectors out of ~220 vectors - i.e. a very
low ~6% utilization (!). [...]
The days where we allocated a lot of vectors on every
CPU and the compression of the IRQ entry code text
mattered are over.
- Another issue is that only a small minority of vectors
is frequent enough to actually matter to cache utilization
in practice: 3-4 key IPIs and 1-2 device IRQs at most - and
those vectors tend to be tightly clustered as well into about
two groups, and are probably already on 2-3 cache lines in
practice.
For the common case of 'cache cold' IRQs it's the depth of
the call chain and the fragmentation of the resulting I$
that should be the main performance limit - not the overall
size of it.
- The CPU side cost of IRQ delivery is still very expensive
even in the best, most cached case, as in 'over a thousand
cycles'. So much stuff is done that maybe contemporary x86
IRQ entry microcode already prefetches the IDT entry and its
expected call target address."[*]
[*] http://lkml.kernel.org/r/20180208094710.qnjixhm6hybebdv7@gmail.com
The "testb $3, CS(%rsp)" instruction in the idtentry macro does not need
modification. Previously, %rsp was manually decreased by 15*8; with
this patch, %rsp is decreased by 15 pushq instructions.
[jpoimboe@redhat.com: unwind hint improvements]
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dan.j.williams@intel.com
Link: http://lkml.kernel.org/r/20180211104949.12992-7-linux@dominikbrodowski.net
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:21 +01:00
Dominik Brodowski
bd25388691
x86/entry/64: Use PUSH_AND_CLEAN_REGS in more cases
...
commit 30907fd13b upstream.
entry_SYSCALL_64_after_hwframe() and nmi() can be converted to use
PUSH_AND_CLEAN_REGS instead of opencoded variants thereof. Due to
the interleaving, the additional XOR-based clearing of R8 and R9
in entry_SYSCALL_64_after_hwframe() should not have any noticeable
negative implications.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org >
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Borislav Petkov <bp@alien8.de >
Cc: Brian Gerst <brgerst@gmail.com >
Cc: Denys Vlasenko <dvlasenk@redhat.com >
Cc: H. Peter Anvin <hpa@zytor.com >
Cc: Josh Poimboeuf <jpoimboe@redhat.com >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: dan.j.williams@intel.com
Link: http://lkml.kernel.org/r/20180211104949.12992-6-linux@dominikbrodowski.net
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:21 +01:00
Dominik Brodowski
3ce4863a44
x86/entry/64: Introduce the PUSH_AND_CLEAN_REGS macro
...
commit 3f01daecd5 upstream.
Those instances where ALLOC_PT_GPREGS_ON_STACK is called just before
SAVE_AND_CLEAR_REGS can trivially be replaced by PUSH_AND_CLEAN_REGS.
This macro uses PUSH instead of MOV and should therefore be faster, at
least on newer CPUs.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org >
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Borislav Petkov <bp@alien8.de >
Cc: Brian Gerst <brgerst@gmail.com >
Cc: Denys Vlasenko <dvlasenk@redhat.com >
Cc: H. Peter Anvin <hpa@zytor.com >
Cc: Josh Poimboeuf <jpoimboe@redhat.com >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: dan.j.williams@intel.com
Link: http://lkml.kernel.org/r/20180211104949.12992-5-linux@dominikbrodowski.net
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:21 +01:00
Dominik Brodowski
47d9c905ae
x86/entry/64: Interleave XOR register clearing with PUSH instructions
...
commit f7bafa2b05 upstream.
Same as is done for syscalls, interleave XOR with PUSH instructions
for exceptions/interrupts, in order to minimize the cost of the
additional instructions required for register clearing.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Borislav Petkov <bp@alien8.de >
Cc: Brian Gerst <brgerst@gmail.com >
Cc: Denys Vlasenko <dvlasenk@redhat.com >
Cc: H. Peter Anvin <hpa@zytor.com >
Cc: Josh Poimboeuf <jpoimboe@redhat.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: dan.j.williams@intel.com
Link: http://lkml.kernel.org/r/20180211104949.12992-4-linux@dominikbrodowski.net
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:21 +01:00
Dominik Brodowski
bb68735527
x86/entry/64: Merge the POP_C_REGS and POP_EXTRA_REGS macros into a single POP_REGS macro
...
commit 502af0d708 upstream.
The two special, opencoded cases for POP_C_REGS can be handled by ASM
macros.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Borislav Petkov <bp@alien8.de >
Cc: Brian Gerst <brgerst@gmail.com >
Cc: Denys Vlasenko <dvlasenk@redhat.com >
Cc: H. Peter Anvin <hpa@zytor.com >
Cc: Josh Poimboeuf <jpoimboe@redhat.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: dan.j.williams@intel.com
Link: http://lkml.kernel.org/r/20180211104949.12992-3-linux@dominikbrodowski.net
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:21 +01:00
Dominik Brodowski
51209eec23
x86/entry/64: Merge SAVE_C_REGS and SAVE_EXTRA_REGS, remove unused extensions
...
commit 2e3f0098bc upstream.
All current code paths call SAVE_C_REGS and then immediately
SAVE_EXTRA_REGS. Therefore, merge these two macros and order the MOV
sequeneces properly.
While at it, remove the macros to save all except specific registers,
as these macros have been unused for a long time.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org >
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Borislav Petkov <bp@alien8.de >
Cc: Brian Gerst <brgerst@gmail.com >
Cc: Denys Vlasenko <dvlasenk@redhat.com >
Cc: H. Peter Anvin <hpa@zytor.com >
Cc: Josh Poimboeuf <jpoimboe@redhat.com >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: dan.j.williams@intel.com
Link: http://lkml.kernel.org/r/20180211104949.12992-2-linux@dominikbrodowski.net
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:21 +01:00
Dan Williams
d10d0bb86d
x86/entry/64: Clear registers for exceptions/interrupts, to reduce speculation attack surface
...
commit 3ac6d8c787 upstream.
Clear the 'extra' registers on entering the 64-bit kernel for exceptions
and interrupts. The common registers are not cleared since they are
likely clobbered well before they can be exploited in a speculative
execution attack.
Originally-From: Andi Kleen <ak@linux.intel.com >
Signed-off-by: Dan Williams <dan.j.williams@intel.com >
Cc: <stable@vger.kernel.org >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Borislav Petkov <bp@alien8.de >
Cc: Brian Gerst <brgerst@gmail.com >
Cc: Denys Vlasenko <dvlasenk@redhat.com >
Cc: H. Peter Anvin <hpa@zytor.com >
Cc: Josh Poimboeuf <jpoimboe@redhat.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Link: http://lkml.kernel.org/r/151787989146.7847.15749181712358213254.stgit@dwillia2-desk3.amr.corp.intel.com
[ Made small improvements to the changelog and the code comments. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:21 +01:00
Rafael J. Wysocki
e578fedba8
PM: cpuidle: Fix cpuidle_poll_state_init() prototype
...
commit d7212cfb05 upstream.
Commit f859422075 (x86: PM: Make APM idle driver initialize polling
state) made apm_init() call cpuidle_poll_state_init(), but that only
is defined for CONFIG_CPU_IDLE set, so make the empty stub of it
available for CONFIG_CPU_IDLE unset too to fix the resulting build
issue.
Fixes: f859422075 (x86: PM: Make APM idle driver initialize polling state)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:20 +01:00
Lukas Wunner
c59cce7943
PM / runtime: Update links_count also if !CONFIG_SRCU
...
commit 433986c2c2 upstream.
Commit baa8809f60 (PM / runtime: Optimize the use of device links)
added an invocation of pm_runtime_drop_link() to __device_link_del().
However there are two variants of that function, one for CONFIG_SRCU and
another for !CONFIG_SRCU, and the commit only modified the former.
Fixes: baa8809f60 (PM / runtime: Optimize the use of device links)
Cc: v4.10+ <stable@vger.kernel.org > # v4.10+
Signed-off-by: Lukas Wunner <lukas@wunner.de >
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:20 +01:00
Ingo Molnar
2efd067aa4
x86/speculation: Clean up various Spectre related details
...
commit 21e433bdb9 upstream.
Harmonize all the Spectre messages so that a:
dmesg | grep -i spectre
... gives us most Spectre related kernel boot messages.
Also fix a few other details:
- clarify a comment about firmware speculation control
- s/KPTI/PTI
- remove various line-breaks that made the code uglier
Acked-by: David Woodhouse <dwmw@amazon.co.uk >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Arjan van de Ven <arjan@linux.intel.com >
Cc: Borislav Petkov <bp@alien8.de >
Cc: Dan Williams <dan.j.williams@intel.com >
Cc: Dave Hansen <dave.hansen@linux.intel.com >
Cc: David Woodhouse <dwmw2@infradead.org >
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
Cc: Josh Poimboeuf <jpoimboe@redhat.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:20 +01:00
KarimAllah Ahmed
a15bdf6579
KVM/nVMX: Set the CPU_BASED_USE_MSR_BITMAPS if we have a valid L02 MSR bitmap
...
commit 3712caeb14 upstream.
We either clear the CPU_BASED_USE_MSR_BITMAPS and end up intercepting all
MSR accesses or create a valid L02 MSR bitmap and use that. This decision
has to be made every time we evaluate whether we are going to generate the
L02 MSR bitmap.
Before commit:
d28b387fb7 ("KVM/VMX: Allow direct access to MSR_IA32_SPEC_CTRL")
... this was probably OK since the decision was always identical.
This is no longer the case now since the MSR bitmap might actually
change once we decide to not intercept SPEC_CTRL and PRED_CMD.
Signed-off-by: KarimAllah Ahmed <karahmed@amazon.de >
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk >
Acked-by: Paolo Bonzini <pbonzini@redhat.com >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Arjan van de Ven <arjan@linux.intel.com >
Cc: Borislav Petkov <bp@alien8.de >
Cc: Dan Williams <dan.j.williams@intel.com >
Cc: Dave Hansen <dave.hansen@linux.intel.com >
Cc: David Woodhouse <dwmw2@infradead.org >
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
Cc: Josh Poimboeuf <jpoimboe@redhat.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Radim Krčmář <rkrcmar@redhat.com >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: arjan.van.de.ven@intel.com
Cc: dave.hansen@intel.com
Cc: jmattson@google.com
Cc: kvm@vger.kernel.org
Cc: sironi@amazon.de
Link: http://lkml.kernel.org/r/1518305967-31356-6-git-send-email-dwmw@amazon.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:20 +01:00
KarimAllah Ahmed
07a3a99ed7
X86/nVMX: Properly set spec_ctrl and pred_cmd before merging MSRs
...
commit 206587a9fb upstream.
These two variables should check whether SPEC_CTRL and PRED_CMD are
supposed to be passed through to L2 guests or not. While
msr_write_intercepted_l01 would return 'true' if it is not passed through.
So just invert the result of msr_write_intercepted_l01 to implement the
correct semantics.
Signed-off-by: KarimAllah Ahmed <karahmed@amazon.de >
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk >
Reviewed-by: Jim Mattson <jmattson@google.com >
Acked-by: Paolo Bonzini <pbonzini@redhat.com >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Arjan van de Ven <arjan@linux.intel.com >
Cc: Borislav Petkov <bp@alien8.de >
Cc: Dan Williams <dan.j.williams@intel.com >
Cc: Dave Hansen <dave.hansen@linux.intel.com >
Cc: David Woodhouse <dwmw2@infradead.org >
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
Cc: Josh Poimboeuf <jpoimboe@redhat.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Radim Krčmář <rkrcmar@redhat.com >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: arjan.van.de.ven@intel.com
Cc: dave.hansen@intel.com
Cc: kvm@vger.kernel.org
Cc: sironi@amazon.de
Fixes: 086e7d4118cc ("KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL")
Link: http://lkml.kernel.org/r/1518305967-31356-5-git-send-email-dwmw@amazon.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:20 +01:00
David Woodhouse
474bd0b82e
KVM/x86: Reduce retpoline performance impact in slot_handle_level_range(), by always inlining iterator helper methods
...
commit 928a4c3948 upstream.
With retpoline, tight loops of "call this function for every XXX" are
very much pessimised by taking a prediction miss *every* time. This one
is by far the biggest contributor to the guest launch time with retpoline.
By marking the iterator slot_handle_…() functions always_inline, we can
ensure that the indirect function call can be optimised away into a
direct call and it actually generates slightly smaller code because
some of the other conditionals can get optimised away too.
Performance is now pretty close to what we see with nospectre_v2 on
the command line.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org >
Tested-by: Filippo Sironi <sironi@amazon.de >
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk >
Reviewed-by: Filippo Sironi <sironi@amazon.de >
Acked-by: Paolo Bonzini <pbonzini@redhat.com >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Arjan van de Ven <arjan@linux.intel.com >
Cc: Borislav Petkov <bp@alien8.de >
Cc: Dan Williams <dan.j.williams@intel.com >
Cc: Dave Hansen <dave.hansen@linux.intel.com >
Cc: David Woodhouse <dwmw2@infradead.org >
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
Cc: Josh Poimboeuf <jpoimboe@redhat.com >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: arjan.van.de.ven@intel.com
Cc: dave.hansen@intel.com
Cc: jmattson@google.com
Cc: karahmed@amazon.de
Cc: kvm@vger.kernel.org
Cc: rkrcmar@redhat.com
Link: http://lkml.kernel.org/r/1518305967-31356-4-git-send-email-dwmw@amazon.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:20 +01:00
David Woodhouse
bdc69a2ffa
Revert "x86/speculation: Simplify indirect_branch_prediction_barrier()"
...
commit f208820a32 upstream.
This reverts commit 64e16720ea .
We cannot call C functions like that, without marking all the
call-clobbered registers as, well, clobbered. We might have got away
with it for now because the __ibp_barrier() function was *fairly*
unlikely to actually use any other registers. But no. Just no.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Arjan van de Ven <arjan@linux.intel.com >
Cc: Borislav Petkov <bp@alien8.de >
Cc: Dan Williams <dan.j.williams@intel.com >
Cc: Dave Hansen <dave.hansen@linux.intel.com >
Cc: David Woodhouse <dwmw2@infradead.org >
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
Cc: Josh Poimboeuf <jpoimboe@redhat.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: arjan.van.de.ven@intel.com
Cc: dave.hansen@intel.com
Cc: jmattson@google.com
Cc: karahmed@amazon.de
Cc: kvm@vger.kernel.org
Cc: pbonzini@redhat.com
Cc: rkrcmar@redhat.com
Cc: sironi@amazon.de
Link: http://lkml.kernel.org/r/1518305967-31356-3-git-send-email-dwmw@amazon.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:20 +01:00
David Woodhouse
b7451cb615
x86/speculation: Correct Speculation Control microcode blacklist again
...
commit d37fc6d360 upstream.
Arjan points out that the Intel document only clears the 0xc2 microcode
on *some* parts with CPUID 506E3 (INTEL_FAM6_SKYLAKE_DESKTOP stepping 3).
For the Skylake H/S platform it's OK but for Skylake E3 which has the
same CPUID it isn't (yet) cleared.
So removing it from the blacklist was premature. Put it back for now.
Also, Arjan assures me that the 0x84 microcode for Kaby Lake which was
featured in one of the early revisions of the Intel document was never
released to the public, and won't be until/unless it is also validated
as safe. So those can change to 0x80 which is what all *other* versions
of the doc have identified.
Once the retrospective testing of existing public microcodes is done, we
should be back into a mode where new microcodes are only released in
batches and we shouldn't even need to update the blacklist for those
anyway, so this tweaking of the list isn't expected to be a thing which
keeps happening.
Requested-by: Arjan van de Ven <arjan.van.de.ven@intel.com >
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Arjan van de Ven <arjan@linux.intel.com >
Cc: Borislav Petkov <bp@alien8.de >
Cc: Dan Williams <dan.j.williams@intel.com >
Cc: Dave Hansen <dave.hansen@linux.intel.com >
Cc: David Woodhouse <dwmw2@infradead.org >
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
Cc: Josh Poimboeuf <jpoimboe@redhat.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: arjan.van.de.ven@intel.com
Cc: dave.hansen@intel.com
Cc: kvm@vger.kernel.org
Cc: pbonzini@redhat.com
Link: http://lkml.kernel.org/r/1518449255-2182-1-git-send-email-dwmw@amazon.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:20 +01:00
David Woodhouse
d5a1b55923
x86/speculation: Update Speculation Control microcode blacklist
...
commit 1751342095 upstream.
Intel have retroactively blessed the 0xc2 microcode on Skylake mobile
and desktop parts, and the Gemini Lake 0x22 microcode is apparently fine
too. We blacklisted the latter purely because it was present with all
the other problematic ones in the 2018-01-08 release, but now it's
explicitly listed as OK.
We still list 0x84 for the various Kaby Lake / Coffee Lake parts, as
that appeared in one version of the blacklist and then reverted to
0x80 again. We can change it if 0x84 is actually announced to be safe.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Arjan van de Ven <arjan@linux.intel.com >
Cc: Borislav Petkov <bp@alien8.de >
Cc: Dan Williams <dan.j.williams@intel.com >
Cc: Dave Hansen <dave.hansen@linux.intel.com >
Cc: David Woodhouse <dwmw2@infradead.org >
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
Cc: Josh Poimboeuf <jpoimboe@redhat.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: arjan.van.de.ven@intel.com
Cc: jmattson@google.com
Cc: karahmed@amazon.de
Cc: kvm@vger.kernel.org
Cc: pbonzini@redhat.com
Cc: rkrcmar@redhat.com
Cc: sironi@amazon.de
Link: http://lkml.kernel.org/r/1518305967-31356-2-git-send-email-dwmw@amazon.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:20 +01:00
Nadav Amit
372ed44826
x86/mm/pti: Fix PTI comment in entry_SYSCALL_64()
...
commit 14b1fcc620 upstream.
The comment is confusing since the path is taken when
CONFIG_PAGE_TABLE_ISOLATION=y is disabled (while the comment says it is not
taken).
Signed-off-by: Nadav Amit <namit@vmware.com >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Arjan van de Ven <arjan@linux.intel.com >
Cc: Borislav Petkov <bp@alien8.de >
Cc: Dan Williams <dan.j.williams@intel.com >
Cc: Dave Hansen <dave.hansen@linux.intel.com >
Cc: David Woodhouse <dwmw2@infradead.org >
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
Cc: Josh Poimboeuf <jpoimboe@redhat.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: nadav.amit@gmail.com
Link: http://lkml.kernel.org/r/20180209170638.15161-1-namit@vmware.com
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:19 +01:00
Balbir Singh
b973685e70
powerpc/mm/radix: Split linear mapping on hot-unplug
...
commit 4dd5f8a99e upstream.
This patch splits the linear mapping if the hot-unplug range is
smaller than the mapping size. The code detects if the mapping needs
to be split into a smaller size and if so, uses the stop machine
infrastructure to clear the existing mapping and then remap the
remaining range using a smaller page size.
The code will skip any region of the mapping that overlaps with kernel
text and warn about it once. We don't want to remove a mapping where
the kernel text and the LMB we intend to remove overlap in the same
TLB mapping as it may affect the currently executing code.
I've tested these changes under a kvm guest with 2 vcpus, from a split
mapping point of view, some of the caveats mentioned above applied to
the testing I did.
Fixes: 4b5d62ca17 ("powerpc/mm: add radix__remove_section_mapping()")
Signed-off-by: Balbir Singh <bsingharora@gmail.com >
[mpe: Tweak change log to match updated behaviour]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:19 +01:00
Artem Savkov
14d87b7103
crypto: sun4i_ss_prng - convert lock to _bh in sun4i_ss_prng_generate
...
commit 2e7d1d61ea upstream.
Lockdep detects a possible deadlock in sun4i_ss_prng_generate() and
throws an "inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage" warning.
Disabling softirqs to fix this.
Fixes: b8ae5c7387 ("crypto: sun4i-ss - support the Security System PRNG")
Signed-off-by: Artem Savkov <artem.savkov@gmail.com >
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:19 +01:00
Artem Savkov
b3d33c5f29
crypto: sun4i_ss_prng - fix return value of sun4i_ss_prng_generate
...
commit dd78c832ff upstream.
According to crypto/rng.h generate function should return 0 on success
and < 0 on error.
Fixes: b8ae5c7387 ("crypto: sun4i-ss - support the Security System PRNG")
Signed-off-by: Artem Savkov <artem.savkov@gmail.com >
Acked-by: Corentin Labbe <clabbe.montjoie@gmail.com >
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:19 +01:00
Geert Uytterhoeven
fff8ad7c18
compiler-gcc.h: __nostackprotector needs gcc-4.4 and up
...
commit d9afaaa4ff upstream.
Gcc versions before 4.4 do not recognize the __optimize__ compiler
attribute:
warning: ‘__optimize__’ attribute directive ignored
Fixes: 7375ae3a0b ("compiler-gcc.h: Introduce __nostackprotector function attribute")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org >
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:19 +01:00
Geert Uytterhoeven
045e5161ab
compiler-gcc.h: Introduce __optimize function attribute
...
commit df5d45aa08 upstream.
Create a new function attribute __optimize, which allows to specify an
optimization level on a per-function basis.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org >
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org >
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:19 +01:00
Dan Williams
ec35f83de1
x86/entry/64/compat: Clear registers for compat syscalls, to reduce speculation attack surface
...
commit 6b8cf5cc99 upstream.
At entry userspace may have populated registers with values that could
otherwise be useful in a speculative execution attack. Clear them to
minimize the kernel's attack surface.
Originally-From: Andi Kleen <ak@linux.intel.com >
Signed-off-by: Dan Williams <dan.j.williams@intel.com >
Cc: <stable@vger.kernel.org >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Borislav Petkov <bp@alien8.de >
Cc: Brian Gerst <brgerst@gmail.com >
Cc: Denys Vlasenko <dvlasenk@redhat.com >
Cc: H. Peter Anvin <hpa@zytor.com >
Cc: Josh Poimboeuf <jpoimboe@redhat.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Link: http://lkml.kernel.org/r/151787989697.7847.4083702787288600552.stgit@dwillia2-desk3.amr.corp.intel.com
[ Made small improvements to the changelog. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:19 +01:00
Dan Williams
2bc19b518c
x86/entry/64: Clear extra registers beyond syscall arguments, to reduce speculation attack surface
...
commit 8e1eb3fa00 upstream.
At entry userspace may have (maliciously) populated the extra registers
outside the syscall calling convention with arbitrary values that could
be useful in a speculative execution (Spectre style) attack.
Clear these registers to minimize the kernel's attack surface.
Note, this only clears the extra registers and not the unused
registers for syscalls less than 6 arguments, since those registers are
likely to be clobbered well before their values could be put to use
under speculation.
Note, Linus found that the XOR instructions can be executed with
minimized cost if interleaved with the PUSH instructions, and Ingo's
analysis found that R10 and R11 should be included in the register
clearing beyond the typical 'extra' syscall calling convention
registers.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org >
Reported-by: Andi Kleen <ak@linux.intel.com >
Signed-off-by: Dan Williams <dan.j.williams@intel.com >
Cc: <stable@vger.kernel.org >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Borislav Petkov <bp@alien8.de >
Cc: Brian Gerst <brgerst@gmail.com >
Cc: Denys Vlasenko <dvlasenk@redhat.com >
Cc: H. Peter Anvin <hpa@zytor.com >
Cc: Josh Poimboeuf <jpoimboe@redhat.com >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Link: http://lkml.kernel.org/r/151787988577.7847.16733592218894189003.stgit@dwillia2-desk3.amr.corp.intel.com
[ Made small improvements to the changelog and the code comments. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:19 +01:00
Rafael J. Wysocki
43d38b079c
x86: PM: Make APM idle driver initialize polling state
...
commit f859422075 upstream.
Update the APM driver overlooked by commit 1b39e3f813 (cpuidle: Make
drivers initialize polling state) to initialize the polling state like
the other cpuidle drivers modified by that commit to prevent cpuidle
from crashing.
Fixes: 1b39e3f813 (cpuidle: Make drivers initialize polling state)
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Cc: 4.14+ <stable@vger.kernel.org > # 4.14+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:18 +01:00
Juergen Gross
41fd295d90
x86/xen: init %gs very early to avoid page faults with stack protector
...
commit 4f277295e5 upstream.
When running as Xen pv guest %gs is initialized some time after
C code is started. Depending on stack protector usage this might be
too late, resulting in page faults.
So setup %gs and MSR_GS_BASE in assembly code already.
Cc: stable@vger.kernel.org
Signed-off-by: Juergen Gross <jgross@suse.com >
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com >
Tested-by: Chris Patterson <cjp256@gmail.com >
Signed-off-by: Juergen Gross <jgross@suse.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:18 +01:00
Kirill A. Shutemov
04f048fad3
x86/kexec: Make kexec (mostly) work in 5-level paging mode
...
commit 5bf3031699 upstream.
Currently kexec() will crash when switching into a 5-level paging
enabled kernel.
I missed that we need to change relocate_kernel() to set CR4.LA57
flag if the kernel has 5-level paging enabled.
I avoided using #ifdef CONFIG_X86_5LEVEL here and inferred if we need to
enable 5-level paging from previous CR4 value. This way the code is
ready for boot-time switching between paging modes.
With this patch applied, in addition to kexec 4-to-4 which always worked,
we can kexec 4-to-5 and 5-to-5 - while 5-to-4 will need more work.
Reported-by: Baoquan He <bhe@redhat.com >
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com >
Tested-by: Baoquan He <bhe@redhat.com >
Cc: <stable@vger.kernel.org > # v4.14+
Cc: Borislav Petkov <bp@suse.de >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: linux-mm@kvack.org
Fixes: 77ef56e4f0 ("x86: Enable 5-level paging support via CONFIG_X86_5LEVEL=y")
Link: http://lkml.kernel.org/r/20180129110845.26633-1-kirill.shutemov@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:18 +01:00
Lucas De Marchi
0fe1e5ec1c
x86/gpu: add CFL to early quirks
...
commit 33aa69ed8a upstream.
CFL was missing from intel_early_ids[]. The PCI ID needs to be there to
allow the memory region to be stolen, otherwise we could have RAM being
arbitrarily overwritten if for example we keep using the UEFI framebuffer,
depending on how BIOS has set up the e820 map.
Fixes: b056f8f3d6 ("drm/i915/cfl: Add Coffee Lake PCI IDs for S Skus.")
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com >
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com >
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com >
Cc: Jani Nikula <jani.nikula@linux.intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: David Airlie <airlied@linux.ie >
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: Ingo Molnar <mingo@kernel.org >
Cc: H. Peter Anvin <hpa@zytor.com >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: x86@kernel.org
Cc: <stable@vger.kernel.org > # v4.13+ 0890540e21 drm/i915: add GT number to intel_device_info
Cc: <stable@vger.kernel.org > # v4.13+ 41693fd523 drm/i915/kbl: Change a KBL pci id to GT2 from GT1.5
Cc: <stable@vger.kernel.org > # v4.13+
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
Acked-by: Jani Nikula <jani.nikula@intel.com >
Acked-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20171213200425.2954-1-lucas.demarchi@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:18 +01:00
Anuj Phogat
ba86431b7b
drm/i915/kbl: Change a KBL pci id to GT2 from GT1.5
...
commit 41693fd523 upstream.
See Mesa commit 9c588ff
Cc: Matt Turner <mattst88@gmail.com >
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com >
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com >
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20170920203126.1323-1-anuj.phogat@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:18 +01:00
Lionel Landwerlin
cc2759b7bb
drm/i915: add GT number to intel_device_info
...
commit 0890540e21 upstream.
Up to Coffeelake we could deduce this GT number from the device ID.
This doesn't seem to be the case anymore. This change reorders pciids
per GT and adds a gt field to intel_device_info. We set this field on
the following platforms :
- SNB/IVB/HSW/BDW/SKL/KBL/CFL/CNL
Before & After :
$ modinfo drivers/gpu/drm/i915/i915.ko | grep ^alias | wc -l
209
v2: Add SNB & IVB (Chris)
v3: Fix compilation error in early-quirks (Lionel)
v4: Fix inconsistency between FEATURE/PLATFORM macros (Ville)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20170830161208.29221-2-lionel.g.landwerlin@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:18 +01:00
Viresh Kumar
ce6ec5b8dc
arm: spear13xx: Fix spics gpio controller's warning
...
commit f8975cb1b8 upstream.
This fixes the following warning by also sending the flags argument for
gpio controllers:
Property 'cs-gpios', cell 6 is not a phandle reference in
/ahb/apb/spi@e0100000
Fixes: 8113ba917d ("ARM: SPEAr: DT: Update device nodes")
Cc: stable@vger.kernel.org # v3.8+
Reported-by: Arnd Bergmann <arnd@arndb.de >
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org >
Signed-off-by: Olof Johansson <olof@lixom.net >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:18 +01:00
Viresh Kumar
349d03cb53
arm: spear13xx: Fix dmas cells
...
commit cdd1040991 upstream.
The "dmas" cells for the designware DMA controller need to have only 3
properties apart from the phandle: request line, src master and
destination master. But the commit 6e8887f60f updated it incorrectly
while moving from platform code to DT. Fix it.
Cc: stable@vger.kernel.org # v3.10+
Fixes: 6e8887f60f ("ARM: SPEAr13xx: Pass generic DW DMAC platform data from DT")
Reported-by: Arnd Bergmann <arnd@arndb.de >
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org >
Signed-off-by: Olof Johansson <olof@lixom.net >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:18 +01:00
Viresh Kumar
b1637c1236
arm: spear600: Add missing interrupt-parent of rtc
...
commit 6ffb5b4f24 upstream.
The interrupt-parent of rtc was missing, add it.
Fixes: 8113ba917d ("ARM: SPEAr: DT: Update device nodes")
Cc: stable@vger.kernel.org # v3.8+
Reported-by: Arnd Bergmann <arnd@arndb.de >
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org >
Signed-off-by: Olof Johansson <olof@lixom.net >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:18 +01:00
Sean Wang
cbcc2ff13a
arm: dts: mt7623: fix card detection issue on bananapi-r2
...
commit b96a696fb2 upstream.
Fix that bananapi-r2 booting from SD-card would fail since incorrect
polarity is applied to the previous setup with GPIO_ACTIVE_HIGH.
Cc: stable@vger.kernel.org
Fixes: 0eed8d0976 ("arm: dts: mt7623: Add SD-card and EMMC to bananapi-r2")
Signed-off-by: Sean Wang <sean.wang@mediatek.com >
Tested-by: Matthias Brugger <matthias.bgg@gmail.com >
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2018-02-22 15:42:17 +01:00