1. 05 Dec, 2018 21 commits
  2. 27 Nov, 2018 2 commits
    • Kirill A. Shutemov's avatar
      x86/ldt: Unmap PTEs for the slot before freeing LDT pages · a17989cb
      Kirill A. Shutemov authored
      commit a0e6e083 upstream
      
      modify_ldt(2) leaves the old LDT mapped after switching over to the new
      one. The old LDT gets freed and the pages can be re-used.
      
      Leaving the mapping in place can have security implications. The mapping is
      present in the userspace page tables and Meltdown-like attacks can read
      these freed and possibly reused pages.
      
      It's relatively simple to fix: unmap the old LDT and flush TLB before
      freeing the old LDT memory.
      
      This further allows to avoid flushing the TLB in map_ldt_struct() as the
      slot is unmapped and flushed by unmap_ldt_struct() or has never been mapped
      at all.
      
      [ tglx: Massaged changelog and removed the needless line breaks ]
      
      Fixes: f55f0501 ("x86/pti: Put the LDT in its own PGD if PTI is on")
      Signed-off-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: bp@alien8.de
      Cc: hpa@zytor.com
      Cc: dave.hansen@linux.intel.com
      Cc: luto@kernel.org
      Cc: peterz@infradead.org
      Cc: boris.ostrovsky@oracle.com
      Cc: jgross@suse.com
      Cc: bhe@redhat.com
      Cc: willy@infradead.org
      Cc: linux-mm@kvack.org
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20181026122856.66224-3-kirill.shutemov@linux.intel.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      a17989cb
    • Feng Tang's avatar
      x86/earlyprintk: Add a force option for pciserial device · ad2e60ff
      Feng Tang authored
      [ Upstream commit d2266bbf ]
      
      The "pciserial" earlyprintk variant helps much on many modern x86
      platforms, but unfortunately there are still some platforms with PCI
      UART devices which have the wrong PCI class code. In that case, the
      current class code check does not allow for them to be used for logging.
      
      Add a sub-option "force" which overrides the class code check and thus
      the use of such device can be enforced.
      
       [ bp: massage formulations. ]
      Suggested-by: default avatarBorislav Petkov <bp@alien8.de>
      Signed-off-by: default avatarFeng Tang <feng.tang@intel.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: "Stuart R . Anderson" <stuart.r.anderson@intel.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Feng Tang <feng.tang@intel.com>
      Cc: Frederic Weisbecker <frederic@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: H Peter Anvin <hpa@linux.intel.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
      Cc: Kate Stewart <kstewart@linuxfoundation.org>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Philippe Ombredanne <pombredanne@nexb.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Thymo van Beers <thymovanbeers@gmail.com>
      Cc: alan@linux.intel.com
      Cc: linux-doc@vger.kernel.org
      Link: http://lkml.kernel.org/r/20181002164921.25833-1-feng.tang@intel.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      ad2e60ff
  3. 23 Nov, 2018 1 commit
  4. 21 Nov, 2018 2 commits
  5. 13 Nov, 2018 4 commits
    • Sebastian Andrzej Siewior's avatar
      x86/fpu: Remove second definition of fpu in __fpu__restore_sig() · bd79c781
      Sebastian Andrzej Siewior authored
      [ Upstream commit 6aa67676 ]
      
      Commit:
      
        c5bedc68 ("x86/fpu: Get rid of PF_USED_MATH usage, convert it to fpu->fpstate_active")
      
      introduced the 'fpu' variable at top of __restore_xstate_sig(),
      which now shadows the other definition:
      
        arch/x86/kernel/fpu/signal.c:318:28: warning: symbol 'fpu' shadows an earlier one
        arch/x86/kernel/fpu/signal.c:271:20: originally declared here
      
      Remove the shadowed definition of 'fpu', as the two definitions are the same.
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Reviewed-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: c5bedc68 ("x86/fpu: Get rid of PF_USED_MATH usage, convert it to fpu->fpstate_active")
      Link: http://lkml.kernel.org/r/20181016202525.29437-3-bigeasy@linutronix.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bd79c781
    • Sai Praneeth's avatar
      x86/speculation: Support Enhanced IBRS on future CPUs · a7051265
      Sai Praneeth authored
      commit 706d5168 upstream.
      
      Future Intel processors will support "Enhanced IBRS" which is an "always
      on" mode i.e. IBRS bit in SPEC_CTRL MSR is enabled once and never
      disabled.
      
      From the specification [1]:
      
       "With enhanced IBRS, the predicted targets of indirect branches
        executed cannot be controlled by software that was executed in a less
        privileged predictor mode or on another logical processor. As a
        result, software operating on a processor with enhanced IBRS need not
        use WRMSR to set IA32_SPEC_CTRL.IBRS after every transition to a more
        privileged predictor mode. Software can isolate predictor modes
        effectively simply by setting the bit once. Software need not disable
        enhanced IBRS prior to entering a sleep state such as MWAIT or HLT."
      
      If Enhanced IBRS is supported by the processor then use it as the
      preferred spectre v2 mitigation mechanism instead of Retpoline. Intel's
      Retpoline white paper [2] states:
      
       "Retpoline is known to be an effective branch target injection (Spectre
        variant 2) mitigation on Intel processors belonging to family 6
        (enumerated by the CPUID instruction) that do not have support for
        enhanced IBRS. On processors that support enhanced IBRS, it should be
        used for mitigation instead of retpoline."
      
      The reason why Enhanced IBRS is the recommended mitigation on processors
      which support it is that these processors also support CET which
      provides a defense against ROP attacks. Retpoline is very similar to ROP
      techniques and might trigger false positives in the CET defense.
      
      If Enhanced IBRS is selected as the mitigation technique for spectre v2,
      the IBRS bit in SPEC_CTRL MSR is set once at boot time and never
      cleared. Kernel also has to make sure that IBRS bit remains set after
      VMEXIT because the guest might have cleared the bit. This is already
      covered by the existing x86_spec_ctrl_set_guest() and
      x86_spec_ctrl_restore_host() speculation control functions.
      
      Enhanced IBRS still requires IBPB for full mitigation.
      
      [1] Speculative-Execution-Side-Channel-Mitigations.pdf
      [2] Retpoline-A-Branch-Target-Injection-Mitigation.pdf
      Both documents are available at:
      https://bugzilla.kernel.org/show_bug.cgi?id=199511Originally-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: default avatarSai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Tim C Chen <tim.c.chen@intel.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Ravi Shankar <ravi.v.shankar@intel.com>
      Link: https://lkml.kernel.org/r/1533148945-24095-1-git-send-email-sai.praneeth.prakhya@intel.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a7051265
    • He Zhe's avatar
      x86/corruption-check: Fix panic in memory_corruption_check() when boot option... · f2e58b04
      He Zhe authored
      x86/corruption-check: Fix panic in memory_corruption_check() when boot option without value is provided
      
      commit ccde460b upstream.
      
      memory_corruption_check[{_period|_size}]()'s handlers do not check input
      argument before passing it to kstrtoul() or simple_strtoull(). The argument
      would be a NULL pointer if each of the kernel parameters, without its
      value, is set in command line and thus cause the following panic.
      
      PANIC: early exception 0xe3 IP 10:ffffffff73587c22 error 0 cr2 0x0
      [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.18-rc8+ #2
      [    0.000000] RIP: 0010:kstrtoull+0x2/0x10
      ...
      [    0.000000] Call Trace
      [    0.000000]  ? set_corruption_check+0x21/0x49
      [    0.000000]  ? do_early_param+0x4d/0x82
      [    0.000000]  ? parse_args+0x212/0x330
      [    0.000000]  ? rdinit_setup+0x26/0x26
      [    0.000000]  ? parse_early_options+0x20/0x23
      [    0.000000]  ? rdinit_setup+0x26/0x26
      [    0.000000]  ? parse_early_param+0x2d/0x39
      [    0.000000]  ? setup_arch+0x2f7/0xbf4
      [    0.000000]  ? start_kernel+0x5e/0x4c2
      [    0.000000]  ? load_ucode_bsp+0x113/0x12f
      [    0.000000]  ? secondary_startup_64+0xa5/0xb0
      
      This patch adds checks to prevent the panic.
      Signed-off-by: default avatarHe Zhe <zhe.he@windriver.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: gregkh@linuxfoundation.org
      Cc: kstewart@linuxfoundation.org
      Cc: pombredanne@nexb.com
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/1534260823-87917-1-git-send-email-zhe.he@windriver.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      f2e58b04
    • Jiri Kosina's avatar
      x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation · 8a13906a
      Jiri Kosina authored
      commit 53c613fe upstream.
      
      STIBP is a feature provided by certain Intel ucodes / CPUs. This feature
      (once enabled) prevents cross-hyperthread control of decisions made by
      indirect branch predictors.
      
      Enable this feature if
      
      - the CPU is vulnerable to spectre v2
      - the CPU supports SMT and has SMT siblings online
      - spectre_v2 mitigation autoselection is enabled (default)
      
      After some previous discussion, this leaves STIBP on all the time, as wrmsr
      on crossing kernel boundary is a no-no. This could perhaps later be a bit
      more optimized (like disabling it in NOHZ, experiment with disabling it in
      idle, etc) if needed.
      
      Note that the synchronization of the mask manipulation via newly added
      spec_ctrl_mutex is currently not strictly needed, as the only updater is
      already being serialized by cpu_add_remove_lock, but let's make this a
      little bit more future-proof.
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc:  "WoodhouseDavid" <dwmw@amazon.co.uk>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc:  "SchauflerCasey" <casey.schaufler@intel.com>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/nycvar.YFH.7.76.1809251438240.15880@cbobk.fhfr.pmSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8a13906a
  6. 10 Nov, 2018 3 commits
    • Nathan Chancellor's avatar
      x86/time: Correct the attribute on jiffies' definition · 70931375
      Nathan Chancellor authored
      commit 53c13ba8 upstream.
      
      Clang warns that the declaration of jiffies in include/linux/jiffies.h
      doesn't match the definition in arch/x86/time/kernel.c:
      
      arch/x86/kernel/time.c:29:42: warning: section does not match previous declaration [-Wsection]
      __visible volatile unsigned long jiffies __cacheline_aligned = INITIAL_JIFFIES;
                                               ^
      ./include/linux/cache.h:49:4: note: expanded from macro '__cacheline_aligned'
                       __section__(".data..cacheline_aligned")))
                       ^
      ./include/linux/jiffies.h:81:31: note: previous attribute is here
      extern unsigned long volatile __cacheline_aligned_in_smp __jiffy_arch_data jiffies;
                                    ^
      ./arch/x86/include/asm/cache.h:20:2: note: expanded from macro '__cacheline_aligned_in_smp'
              __page_aligned_data
              ^
      ./include/linux/linkage.h:39:29: note: expanded from macro '__page_aligned_data'
      #define __page_aligned_data     __section(.data..page_aligned) __aligned(PAGE_SIZE)
                                      ^
      ./include/linux/compiler_attributes.h:233:56: note: expanded from macro '__section'
      #define __section(S)                    __attribute__((__section__(#S)))
                                                             ^
      1 warning generated.
      
      The declaration was changed in commit 7c30f352 ("jiffies.h: declare
      jiffies and jiffies_64 with ____cacheline_aligned_in_smp") but wasn't
      updated here. Make them match so Clang no longer warns.
      
      Fixes: 7c30f352 ("jiffies.h: declare jiffies and jiffies_64 with ____cacheline_aligned_in_smp")
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20181013005311.28617-1-natechancellor@gmail.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      70931375
    • Zhimin Gu's avatar
      x86, hibernate: Fix nosave_regions setup for hibernation · 7f6273f5
      Zhimin Gu authored
      commit cc55f753 upstream.
      
      On 32bit systems, nosave_regions(non RAM areas) located between
      max_low_pfn and max_pfn are not excluded from hibernation snapshot
      currently, which may result in a machine check exception when
      trying to access these unsafe regions during hibernation:
      
      [  612.800453] Disabling lock debugging due to kernel taint
      [  612.805786] mce: [Hardware Error]: CPU 0: Machine Check Exception: 5 Bank 6: fe00000000801136
      [  612.814344] mce: [Hardware Error]: RIP !INEXACT! 60:<00000000d90be566> {swsusp_save+0x436/0x560}
      [  612.823167] mce: [Hardware Error]: TSC 1f5939fe276 ADDR dd000000 MISC 30e0000086
      [  612.830677] mce: [Hardware Error]: PROCESSOR 0:306c3 TIME 1529487426 SOCKET 0 APIC 0 microcode 24
      [  612.839581] mce: [Hardware Error]: Run the above through 'mcelog --ascii'
      [  612.846394] mce: [Hardware Error]: Machine check: Processor context corrupt
      [  612.853380] Kernel panic - not syncing: Fatal machine check
      [  612.858978] Kernel Offset: 0x18000000 from 0xc1000000 (relocation range: 0xc0000000-0xf7ffdfff)
      
      This is because on 32bit systems, pages above max_low_pfn are regarded
      as high memeory, and accessing unsafe pages might cause expected MCE.
      On the problematic 32bit system, there are reserved memory above low
      memory, which triggered the MCE:
      
      e820 memory mapping:
      [    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009d7ff] usable
      [    0.000000] BIOS-e820: [mem 0x000000000009d800-0x000000000009ffff] reserved
      [    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
      [    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000d160cfff] usable
      [    0.000000] BIOS-e820: [mem 0x00000000d160d000-0x00000000d1613fff] ACPI NVS
      [    0.000000] BIOS-e820: [mem 0x00000000d1614000-0x00000000d1a44fff] usable
      [    0.000000] BIOS-e820: [mem 0x00000000d1a45000-0x00000000d1ecffff] reserved
      [    0.000000] BIOS-e820: [mem 0x00000000d1ed0000-0x00000000d7eeafff] usable
      [    0.000000] BIOS-e820: [mem 0x00000000d7eeb000-0x00000000d7ffffff] reserved
      [    0.000000] BIOS-e820: [mem 0x00000000d8000000-0x00000000d875ffff] usable
      [    0.000000] BIOS-e820: [mem 0x00000000d8760000-0x00000000d87fffff] reserved
      [    0.000000] BIOS-e820: [mem 0x00000000d8800000-0x00000000d8fadfff] usable
      [    0.000000] BIOS-e820: [mem 0x00000000d8fae000-0x00000000d8ffffff] ACPI data
      [    0.000000] BIOS-e820: [mem 0x00000000d9000000-0x00000000da71bfff] usable
      [    0.000000] BIOS-e820: [mem 0x00000000da71c000-0x00000000da7fffff] ACPI NVS
      [    0.000000] BIOS-e820: [mem 0x00000000da800000-0x00000000dbb8bfff] usable
      [    0.000000] BIOS-e820: [mem 0x00000000dbb8c000-0x00000000dbffffff] reserved
      [    0.000000] BIOS-e820: [mem 0x00000000dd000000-0x00000000df1fffff] reserved
      [    0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
      [    0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
      [    0.000000] BIOS-e820: [mem 0x00000000fed00000-0x00000000fed03fff] reserved
      [    0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
      [    0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
      [    0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
      [    0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000041edfffff] usable
      
      Fix this problem by changing pfn limit from max_low_pfn to max_pfn.
      This fix does not impact 64bit system because on 64bit max_low_pfn
      is the same as max_pfn.
      Signed-off-by: default avatarZhimin Gu <kookoo.gu@intel.com>
      Acked-by: default avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarChen Yu <yu.c.chen@intel.com>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: All applicable <stable@vger.kernel.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7f6273f5
    • Peter Zijlstra's avatar
      x86/tsc: Force inlining of cyc2ns bits · 1595a964
      Peter Zijlstra authored
      commit 4907c68a upstream.
      
      Looking at the asm for native_sched_clock() I noticed we don't inline
      enough. Mostly caused by sharing code with cyc2ns_read_begin(), which
      we didn't used to do. So mark all that __force_inline to make it DTRT.
      
      Fixes: 59eaef78 ("x86/tsc: Remodel cyc2ns to use seqcount_latch()")
      Reported-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: hpa@zytor.com
      Cc: eric.dumazet@gmail.com
      Cc: bp@alien8.de
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20181011104019.695196158@infradead.orgSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1595a964
  7. 04 Nov, 2018 1 commit
  8. 04 Oct, 2018 2 commits
  9. 26 Sep, 2018 1 commit
  10. 19 Sep, 2018 2 commits
  11. 09 Sep, 2018 1 commit