1. 12 Jul, 2017 2 commits
    • Kees Cook's avatar
      kexec_file: adjust declaration of kexec_purgatory · e2ae8ab4
      Kees Cook authored
      Defining kexec_purgatory as a zero-length char array upsets compile time
      size checking.  Since this is built on a per-arch basis, define it as an
      unsized char array (like is done for other similar things, e.g.  linker
      sections).  This silences the warning generated by the future
      CONFIG_FORTIFY_SOURCE, which did not like the memcmp() of a "0 byte"
      array.  This drops the __weak and uses an extern instead, since both
      users define kexec_purgatory.
      
      Link: http://lkml.kernel.org/r/1497903987-21002-4-git-send-email-keescook@chromium.orgSigned-off-by: 's avatarKees Cook <keescook@chromium.org>
      Acked-by: 's avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Daniel Micay <danielmicay@gmail.com>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      e2ae8ab4
    • Xunlei Pang's avatar
      kdump: protect vmcoreinfo data under the crash memory · 1229384f
      Xunlei Pang authored
      Currently vmcoreinfo data is updated at boot time subsys_initcall(), it
      has the risk of being modified by some wrong code during system is
      running.
      
      As a result, vmcore dumped may contain the wrong vmcoreinfo.  Later on,
      when using "crash", "makedumpfile", etc utility to parse this vmcore, we
      probably will get "Segmentation fault" or other unexpected errors.
      
      E.g.  1) wrong code overwrites vmcoreinfo_data; 2) further crashes the
      system; 3) trigger kdump, then we obviously will fail to recognize the
      crash context correctly due to the corrupted vmcoreinfo.
      
      Now except for vmcoreinfo, all the crash data is well
      protected(including the cpu note which is fully updated in the crash
      path, thus its correctness is guaranteed).  Given that vmcoreinfo data
      is a large chunk prepared for kdump, we better protect it as well.
      
      To solve this, we relocate and copy vmcoreinfo_data to the crash memory
      when kdump is loading via kexec syscalls.  Because the whole crash
      memory will be protected by existing arch_kexec_protect_crashkres()
      mechanism, we naturally protect vmcoreinfo_data from write(even read)
      access under kernel direct mapping after kdump is loaded.
      
      Since kdump is usually loaded at the very early stage after boot, we can
      trust the correctness of the vmcoreinfo data copied.
      
      On the other hand, we still need to operate the vmcoreinfo safe copy
      when crash happens to generate vmcoreinfo_note again, we rely on vmap()
      to map out a new kernel virtual address and update to use this new one
      instead in the following crash_save_vmcoreinfo().
      
      BTW, we do not touch vmcoreinfo_note, because it will be fully updated
      using the protected vmcoreinfo_data after crash which is surely correct
      just like the cpu crash note.
      
      Link: http://lkml.kernel.org/r/1493281021-20737-3-git-send-email-xlpang@redhat.comSigned-off-by: 's avatarXunlei Pang <xlpang@redhat.com>
      Tested-by: 's avatarMichael Holzheu <holzheu@linux.vnet.ibm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: Hari Bathini <hbathini@linux.vnet.ibm.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      1229384f
  2. 30 Jun, 2017 1 commit
  3. 10 Mar, 2017 1 commit
    • Thomas Gleixner's avatar
      kexec, x86/purgatory: Unbreak it and clean it up · 40c50c1f
      Thomas Gleixner authored
      The purgatory code defines global variables which are referenced via a
      symbol lookup in the kexec code (core and arch).
      
      A recent commit addressing sparse warnings made these static and thereby
      broke kexec_file.
      
      Why did this happen? Simply because the whole machinery is undocumented and
      lacks any form of forward declarations. The variable names are unspecific
      and lack a prefix, so adding forward declarations creates shadow variables
      in the core code. Aside of that the code relies on magic constants and
      duplicate struct definitions with no way to ensure that these things stay
      in sync. The section placement of the purgatory variables happened by
      chance and not by design.
      
      Unbreak kexec and cleanup the mess:
      
       - Add proper forward declarations and document the usage
       - Use common struct definition
       - Use the proper common defines instead of magic constants
       - Add a purgatory_ prefix to have a proper name space
       - Use ARRAY_SIZE() instead of a homebrewn reimplementation
       - Add proper sections to the purgatory variables [ From Mike ]
      
      Fixes: 72042a8c ("x86/purgatory: Make functions and variables static")
      Reported-by: 's avatarMike Galbraith <&lt;efault@gmx.de>
      Signed-off-by: 's avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Nicholas Mc Guire <der.herr@hofr.at>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: "Tobin C. Harding" <me@tobin.cc>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1703101315140.3681@nanosSigned-off-by: 's avatarThomas Gleixner <tglx@linutronix.de>
      40c50c1f
  4. 20 Dec, 2016 1 commit
  5. 30 Nov, 2016 3 commits
  6. 02 Sep, 2016 1 commit
    • Thiago Jung Bauermann's avatar
      kexec: fix double-free when failing to relocate the purgatory · 070c43ee
      Thiago Jung Bauermann authored
      If kexec_apply_relocations fails, kexec_load_purgatory frees pi->sechdrs
      and pi->purgatory_buf.  This is redundant, because in case of error
      kimage_file_prepare_segments calls kimage_file_post_load_cleanup, which
      will also free those buffers.
      
      This causes two warnings like the following, one for pi->sechdrs and the
      other for pi->purgatory_buf:
      
        kexec-bzImage64: Loading purgatory failed
        ------------[ cut here ]------------
        WARNING: CPU: 1 PID: 2119 at mm/vmalloc.c:1490 __vunmap+0xc1/0xd0
        Trying to vfree() nonexistent vm area (ffffc90000e91000)
        Modules linked in:
        CPU: 1 PID: 2119 Comm: kexec Not tainted 4.8.0-rc3+ #5
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
        Call Trace:
          dump_stack+0x4d/0x65
          __warn+0xcb/0xf0
          warn_slowpath_fmt+0x4f/0x60
          ? find_vmap_area+0x19/0x70
          ? kimage_file_post_load_cleanup+0x47/0xb0
          __vunmap+0xc1/0xd0
          vfree+0x2e/0x70
          kimage_file_post_load_cleanup+0x5e/0xb0
          SyS_kexec_file_load+0x448/0x680
          ? putname+0x54/0x60
          ? do_sys_open+0x190/0x1f0
          entry_SYSCALL_64_fastpath+0x13/0x8f
        ---[ end trace 158bb74f5950ca2b ]---
      
      Fix by setting pi->sechdrs an pi->purgatory_buf to NULL, since vfree
      won't try to free a NULL pointer.
      
      Link: http://lkml.kernel.org/r/1472083546-23683-1-git-send-email-bauerman@linux.vnet.ibm.comSigned-off-by: 's avatarThiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
      Acked-by: 's avatarBaoquan He <bhe@redhat.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      070c43ee
  7. 24 May, 2016 1 commit
    • Xunlei Pang's avatar
      kexec: introduce a protection mechanism for the crashkernel reserved memory · 9b492cf5
      Xunlei Pang authored
      For the cases that some kernel (module) path stamps the crash reserved
      memory(already mapped by the kernel) where has been loaded the second
      kernel data, the kdump kernel will probably fail to boot when panic
      happens (or even not happens) leaving the culprit at large, this is
      unacceptable.
      
      The patch introduces a mechanism for detecting such cases:
      
      1) After each crash kexec loading, it simply marks the reserved memory
         regions readonly since we no longer access it after that.  When someone
         stamps the region, the first kernel will panic and trigger the kdump.
         The weak arch_kexec_protect_crashkres() is introduced to do the actual
         protection.
      
      2) To allow multiple loading, once 1) was done we also need to remark
         the reserved memory to readwrite each time a system call related to
         kdump is made.  The weak arch_kexec_unprotect_crashkres() is introduced
         to do the actual protection.
      
      The architecture can make its specific implementation by overriding
      arch_kexec_protect_crashkres() and arch_kexec_unprotect_crashkres().
      Signed-off-by: 's avatarXunlei Pang <xlpang@redhat.com>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Minfei Huang <mhuang@redhat.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Baoquan He <bhe@redhat.com>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      9b492cf5
  8. 21 Feb, 2016 1 commit
  9. 30 Jan, 2016 2 commits
    • Toshi Kani's avatar
      x86, kexec, nvdimm: Use walk_iomem_res_desc() for iomem search · f0f4711a
      Toshi Kani authored
      Change the callers of walk_iomem_res() scanning for the
      following resources by name to use walk_iomem_res_desc()
      instead.
      
       "ACPI Tables"
       "ACPI Non-volatile Storage"
       "Persistent Memory (legacy)"
       "Crash kernel"
      
      Note, the caller of walk_iomem_res() with "GART" will be removed
      in a later patch.
      Signed-off-by: 's avatarToshi Kani <toshi.kani@hpe.com>
      Signed-off-by: 's avatarBorislav Petkov <bp@suse.de>
      Reviewed-by: 's avatarDave Young <dyoung@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Chun-Yi <joeyli.kernel@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Lee, Chun-Yi <joeyli.kernel@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Minfei Huang <mnfhuang@gmail.com>
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Takao Indoh <indou.takao@jp.fujitsu.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: kexec@lists.infradead.org
      Cc: linux-arch@vger.kernel.org
      Cc: linux-mm <linux-mm@kvack.org>
      Cc: linux-nvdimm@lists.01.org
      Link: http://lkml.kernel.org/r/1453841853-11383-15-git-send-email-bp@alien8.deSigned-off-by: 's avatarIngo Molnar <mingo@kernel.org>
      f0f4711a
    • Toshi Kani's avatar
      kexec: Set IORESOURCE_SYSTEM_RAM for System RAM · 1a085d07
      Toshi Kani authored
      Set proper ioresource flags and types for crash kernel
      reservation areas.
      Signed-off-by: 's avatarToshi Kani <toshi.kani@hpe.com>
      Signed-off-by: 's avatarBorislav Petkov <bp@suse.de>
      Reviewed-by: 's avatarDave Young <dyoung@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Baoquan He <bhe@redhat.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: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Minfei Huang <mnfhuang@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: kexec@lists.infradead.org
      Cc: linux-arch@vger.kernel.org
      Cc: linux-mm <linux-mm@kvack.org>
      Link: http://lkml.kernel.org/r/1453841853-11383-8-git-send-email-bp@alien8.deSigned-off-by: 's avatarIngo Molnar <mingo@kernel.org>
      1a085d07
  10. 21 Jan, 2016 1 commit
  11. 07 Nov, 2015 1 commit
  12. 10 Sep, 2015 1 commit
    • Dave Young's avatar
      kexec: split kexec_file syscall code to kexec_file.c · a43cac0d
      Dave Young authored
      Split kexec_file syscall related code to another file kernel/kexec_file.c
      so that the #ifdef CONFIG_KEXEC_FILE in kexec.c can be dropped.
      
      Sharing variables and functions are moved to kernel/kexec_internal.h per
      suggestion from Vivek and Petr.
      
      [akpm@linux-foundation.org: fix bisectability]
      [akpm@linux-foundation.org: declare the various arch_kexec functions]
      [akpm@linux-foundation.org: fix build]
      Signed-off-by: 's avatarDave Young <dyoung@redhat.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Petr Tesarik <ptesarik@suse.cz>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: Josh Boyer <jwboyer@fedoraproject.org>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      a43cac0d