29 Jul, 2020

1 commit

  • Some architectures may have special memory regions, within the given
    memory range, which can't be used for the buffer in a kexec segment.
    Implement weak arch_kexec_locate_mem_hole() definition which arch code
    may override, to take care of special regions, while trying to locate
    a memory hole.

    Also, add the missing declarations for arch overridable functions and
    and drop the __weak descriptors in the declarations to avoid non-weak
    definitions from becoming weak.

    Signed-off-by: Hari Bathini
    Tested-by: Pingfan Liu
    Reviewed-by: Thiago Jung Bauermann
    Acked-by: Dave Young
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/159602273603.575379.17665852963340380839.stgit@hbathini

    Hari Bathini
     

16 Jun, 2020

1 commit

  • There is a regular need in the kernel to provide a way to declare having a
    dynamically sized set of trailing elements in a structure. Kernel code should
    always use “flexible array members”[1] for these cases. The older style of
    one-element or zero-length arrays should no longer be used[2].

    [1] https://en.wikipedia.org/wiki/Flexible_array_member
    [2] https://github.com/KSPP/linux/issues/21

    Signed-off-by: Gustavo A. R. Silva

    Gustavo A. R. Silva
     

28 Sep, 2019

1 commit

  • Pull kernel lockdown mode from James Morris:
    "This is the latest iteration of the kernel lockdown patchset, from
    Matthew Garrett, David Howells and others.

    From the original description:

    This patchset introduces an optional kernel lockdown feature,
    intended to strengthen the boundary between UID 0 and the kernel.
    When enabled, various pieces of kernel functionality are restricted.
    Applications that rely on low-level access to either hardware or the
    kernel may cease working as a result - therefore this should not be
    enabled without appropriate evaluation beforehand.

    The majority of mainstream distributions have been carrying variants
    of this patchset for many years now, so there's value in providing a
    doesn't meet every distribution requirement, but gets us much closer
    to not requiring external patches.

    There are two major changes since this was last proposed for mainline:

    - Separating lockdown from EFI secure boot. Background discussion is
    covered here: https://lwn.net/Articles/751061/

    - Implementation as an LSM, with a default stackable lockdown LSM
    module. This allows the lockdown feature to be policy-driven,
    rather than encoding an implicit policy within the mechanism.

    The new locked_down LSM hook is provided to allow LSMs to make a
    policy decision around whether kernel functionality that would allow
    tampering with or examining the runtime state of the kernel should be
    permitted.

    The included lockdown LSM provides an implementation with a simple
    policy intended for general purpose use. This policy provides a coarse
    level of granularity, controllable via the kernel command line:

    lockdown={integrity|confidentiality}

    Enable the kernel lockdown feature. If set to integrity, kernel features
    that allow userland to modify the running kernel are disabled. If set to
    confidentiality, kernel features that allow userland to extract
    confidential information from the kernel are also disabled.

    This may also be controlled via /sys/kernel/security/lockdown and
    overriden by kernel configuration.

    New or existing LSMs may implement finer-grained controls of the
    lockdown features. Refer to the lockdown_reason documentation in
    include/linux/security.h for details.

    The lockdown feature has had signficant design feedback and review
    across many subsystems. This code has been in linux-next for some
    weeks, with a few fixes applied along the way.

    Stephen Rothwell noted that commit 9d1f8be5cf42 ("bpf: Restrict bpf
    when kernel lockdown is in confidentiality mode") is missing a
    Signed-off-by from its author. Matthew responded that he is providing
    this under category (c) of the DCO"

    * 'next-lockdown' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (31 commits)
    kexec: Fix file verification on S390
    security: constify some arrays in lockdown LSM
    lockdown: Print current->comm in restriction messages
    efi: Restrict efivar_ssdt_load when the kernel is locked down
    tracefs: Restrict tracefs when the kernel is locked down
    debugfs: Restrict debugfs when the kernel is locked down
    kexec: Allow kexec_file() with appropriate IMA policy when locked down
    lockdown: Lock down perf when in confidentiality mode
    bpf: Restrict bpf when kernel lockdown is in confidentiality mode
    lockdown: Lock down tracing and perf kprobes when in confidentiality mode
    lockdown: Lock down /proc/kcore
    x86/mmiotrace: Lock down the testmmiotrace module
    lockdown: Lock down module params that specify hardware parameters (eg. ioport)
    lockdown: Lock down TIOCSSERIAL
    lockdown: Prohibit PCMCIA CIS storage when the kernel is locked down
    acpi: Disable ACPI table override if the kernel is locked down
    acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down
    ACPI: Limit access to custom_method when the kernel is locked down
    x86/msr: Restrict MSR access when the kernel is locked down
    x86: Lock down IO port access when the kernel is locked down
    ...

    Linus Torvalds
     

26 Sep, 2019

1 commit

  • arch_kexec_kernel_image_probe function declaration has been removed by
    commit 9ec4ecef0af7 ("kexec_file,x86,powerpc: factor out kexec_file_ops
    functions"). Still this function is overridden by couple of architectures
    and proper prototype declaration is therefore important, so bring it back.
    This fixes the following sparse warning on s390:
    arch/s390/kernel/machine_kexec_file.c:333:5: warning: symbol
    'arch_kexec_kernel_image_probe' was not declared. Should it be static?

    Link: http://lkml.kernel.org/r/patch.git-ff1c9045ebdc.your-ad-here.call-01564402297-ext-5690@work.hours
    Signed-off-by: Vasily Gorbik
    Acked-by: Dave Young
    Reviewed-by: Bhupesh Sharma
    Cc: Eric Biederman
    Cc: AKASHI Takahiro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Vasily Gorbik
     

07 Sep, 2019

2 commits


20 Aug, 2019

1 commit

  • This is a preparatory patch for kexec_file_load() lockdown. A locked down
    kernel needs to prevent unsigned kernel images from being loaded with
    kexec_file_load(). Currently, the only way to force the signature
    verification is compiling with KEXEC_VERIFY_SIG. This prevents loading
    usigned images even when the kernel is not locked down at runtime.

    This patch splits KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE.
    Analogous to the MODULE_SIG and MODULE_SIG_FORCE for modules, KEXEC_SIG
    turns on the signature verification but allows unsigned images to be
    loaded. KEXEC_SIG_FORCE disallows images without a valid signature.

    Signed-off-by: Jiri Bohac
    Signed-off-by: David Howells
    Signed-off-by: Matthew Garrett
    cc: kexec@lists.infradead.org
    Signed-off-by: James Morris

    Jiri Bohac
     

27 Dec, 2018

1 commit

  • Pull x86 cleanups from Ingo Molnar:
    "Misc cleanups"

    * 'x86-cleanups-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
    x86/kprobes: Remove trampoline_handler() prototype
    x86/kernel: Fix more -Wmissing-prototypes warnings
    x86: Fix various typos in comments
    x86/headers: Fix -Wmissing-prototypes warning
    x86/process: Avoid unnecessary NULL check in get_wchan()
    x86/traps: Complete prototype declarations
    x86/mce: Fix -Wmissing-prototypes warnings
    x86/gart: Rewrite early_gart_iommu_check() comment

    Linus Torvalds
     

06 Dec, 2018

3 commits

  • Memblock list is another source for usable system memory layout.
    So move powerpc's arch_kexec_walk_mem() to common code so that other
    memblock-based architectures, particularly arm64, can also utilise it.
    A moved function is now renamed to kexec_walk_memblock() and integrated
    into kexec_locate_mem_hole(), which will now be usable for all
    architectures with no need for overriding arch_kexec_walk_mem().

    With this change, arch_kexec_walk_mem() need no longer be a weak function,
    and was now renamed to kexec_walk_resources().

    Since powerpc doesn't support kdump in its kexec_file_load(), the current
    kexec_walk_memblock() won't work for kdump either in this form, this will
    be fixed in the next patch.

    Signed-off-by: AKASHI Takahiro
    Cc: "Eric W. Biederman"
    Acked-by: Dave Young
    Cc: Vivek Goyal
    Cc: Baoquan He
    Acked-by: James Morse
    Signed-off-by: Will Deacon

    AKASHI Takahiro
     
  • Since s390 already knows where to locate buffers, calling
    arch_kexec_mem_walk() has no sense. So we can just drop it as kbuf->mem
    indicates this while all other architectures sets it to 0 initially.

    This change is a preparatory work for the next patch, where all the
    variant memory walks, either on system resource or memblock, will be
    put in one common place so that it will satisfy all the architectures'
    need.

    Signed-off-by: AKASHI Takahiro
    Reviewed-by: Philipp Rudo
    Cc: Martin Schwidefsky
    Cc: Heiko Carstens
    Cc: Dave Young
    Cc: Vivek Goyal
    Cc: Baoquan He
    Signed-off-by: Will Deacon

    AKASHI Takahiro
     
  • Change this function from static to global so that arm64 can implement
    its own arch_kimage_file_post_load_cleanup() later using
    kexec_image_post_load_cleanup_default().

    Signed-off-by: AKASHI Takahiro
    Acked-by: Dave Young
    Cc: Vivek Goyal
    Cc: Baoquan He
    Signed-off-by: Will Deacon

    AKASHI Takahiro
     

23 Nov, 2018

1 commit

  • When building the kernel with W=1 we get a lot of -Wmissing-prototypes
    warnings, which are trivial in nature and easy to fix - and which may
    mask some real future bugs if the prototypes get out of sync with
    the function definition.

    This patch fixes most of -Wmissing-prototypes warnings which
    are in the root directory of arch/x86/kernel, not including
    the subdirectories.

    These are the warnings fixed in this patch:

    arch/x86/kernel/signal.c:865:17: warning: no previous prototype for ‘sys32_x32_rt_sigreturn’ [-Wmissing-prototypes]
    arch/x86/kernel/signal_compat.c:164:6: warning: no previous prototype for ‘sigaction_compat_abi’ [-Wmissing-prototypes]
    arch/x86/kernel/traps.c:625:46: warning: no previous prototype for ‘sync_regs’ [-Wmissing-prototypes]
    arch/x86/kernel/traps.c:640:24: warning: no previous prototype for ‘fixup_bad_iret’ [-Wmissing-prototypes]
    arch/x86/kernel/traps.c:929:13: warning: no previous prototype for ‘trap_init’ [-Wmissing-prototypes]
    arch/x86/kernel/irq.c:270:28: warning: no previous prototype for ‘smp_x86_platform_ipi’ [-Wmissing-prototypes]
    arch/x86/kernel/irq.c:301:16: warning: no previous prototype for ‘smp_kvm_posted_intr_ipi’ [-Wmissing-prototypes]
    arch/x86/kernel/irq.c:314:16: warning: no previous prototype for ‘smp_kvm_posted_intr_wakeup_ipi’ [-Wmissing-prototypes]
    arch/x86/kernel/irq.c:328:16: warning: no previous prototype for ‘smp_kvm_posted_intr_nested_ipi’ [-Wmissing-prototypes]
    arch/x86/kernel/irq_work.c:16:28: warning: no previous prototype for ‘smp_irq_work_interrupt’ [-Wmissing-prototypes]
    arch/x86/kernel/irqinit.c:79:13: warning: no previous prototype for ‘init_IRQ’ [-Wmissing-prototypes]
    arch/x86/kernel/quirks.c:672:13: warning: no previous prototype for ‘early_platform_quirks’ [-Wmissing-prototypes]
    arch/x86/kernel/tsc.c:1499:15: warning: no previous prototype for ‘calibrate_delay_is_known’ [-Wmissing-prototypes]
    arch/x86/kernel/process.c:653:13: warning: no previous prototype for ‘arch_post_acpi_subsys_init’ [-Wmissing-prototypes]
    arch/x86/kernel/process.c:717:15: warning: no previous prototype for ‘arch_randomize_brk’ [-Wmissing-prototypes]
    arch/x86/kernel/process.c:784:6: warning: no previous prototype for ‘do_arch_prctl_common’ [-Wmissing-prototypes]
    arch/x86/kernel/reboot.c:869:6: warning: no previous prototype for ‘nmi_panic_self_stop’ [-Wmissing-prototypes]
    arch/x86/kernel/smp.c:176:27: warning: no previous prototype for ‘smp_reboot_interrupt’ [-Wmissing-prototypes]
    arch/x86/kernel/smp.c:260:28: warning: no previous prototype for ‘smp_reschedule_interrupt’ [-Wmissing-prototypes]
    arch/x86/kernel/smp.c:281:28: warning: no previous prototype for ‘smp_call_function_interrupt’ [-Wmissing-prototypes]
    arch/x86/kernel/smp.c:291:28: warning: no previous prototype for ‘smp_call_function_single_interrupt’ [-Wmissing-prototypes]
    arch/x86/kernel/ftrace.c:840:6: warning: no previous prototype for ‘arch_ftrace_update_trampoline’ [-Wmissing-prototypes]
    arch/x86/kernel/ftrace.c:934:7: warning: no previous prototype for ‘arch_ftrace_trampoline_func’ [-Wmissing-prototypes]
    arch/x86/kernel/ftrace.c:946:6: warning: no previous prototype for ‘arch_ftrace_trampoline_free’ [-Wmissing-prototypes]
    arch/x86/kernel/crash.c:114:6: warning: no previous prototype for ‘crash_smp_send_stop’ [-Wmissing-prototypes]
    arch/x86/kernel/crash.c:351:5: warning: no previous prototype for ‘crash_setup_memmap_entries’ [-Wmissing-prototypes]
    arch/x86/kernel/crash.c:424:5: warning: no previous prototype for ‘crash_load_segments’ [-Wmissing-prototypes]
    arch/x86/kernel/machine_kexec_64.c:372:7: warning: no previous prototype for ‘arch_kexec_kernel_image_load’ [-Wmissing-prototypes]
    arch/x86/kernel/paravirt-spinlocks.c:12:16: warning: no previous prototype for ‘__native_queued_spin_unlock’ [-Wmissing-prototypes]
    arch/x86/kernel/paravirt-spinlocks.c:18:6: warning: no previous prototype for ‘pv_is_native_spin_unlock’ [-Wmissing-prototypes]
    arch/x86/kernel/paravirt-spinlocks.c:24:16: warning: no previous prototype for ‘__native_vcpu_is_preempted’ [-Wmissing-prototypes]
    arch/x86/kernel/paravirt-spinlocks.c:30:6: warning: no previous prototype for ‘pv_is_native_vcpu_is_preempted’ [-Wmissing-prototypes]
    arch/x86/kernel/kvm.c:258:1: warning: no previous prototype for ‘do_async_page_fault’ [-Wmissing-prototypes]
    arch/x86/kernel/jailhouse.c:200:6: warning: no previous prototype for ‘jailhouse_paravirt’ [-Wmissing-prototypes]
    arch/x86/kernel/check.c:91:13: warning: no previous prototype for ‘setup_bios_corruption_check’ [-Wmissing-prototypes]
    arch/x86/kernel/check.c:139:6: warning: no previous prototype for ‘check_for_bios_corruption’ [-Wmissing-prototypes]
    arch/x86/kernel/devicetree.c:32:13: warning: no previous prototype for ‘early_init_dt_scan_chosen_arch’ [-Wmissing-prototypes]
    arch/x86/kernel/devicetree.c:42:13: warning: no previous prototype for ‘add_dtb’ [-Wmissing-prototypes]
    arch/x86/kernel/devicetree.c:108:6: warning: no previous prototype for ‘x86_of_pci_init’ [-Wmissing-prototypes]
    arch/x86/kernel/devicetree.c:314:13: warning: no previous prototype for ‘x86_dtb_init’ [-Wmissing-prototypes]
    arch/x86/kernel/tracepoint.c:16:5: warning: no previous prototype for ‘trace_pagefault_reg’ [-Wmissing-prototypes]
    arch/x86/kernel/tracepoint.c:22:6: warning: no previous prototype for ‘trace_pagefault_unreg’ [-Wmissing-prototypes]
    arch/x86/kernel/head64.c:113:22: warning: no previous prototype for ‘__startup_64’ [-Wmissing-prototypes]
    arch/x86/kernel/head64.c:262:15: warning: no previous prototype for ‘__startup_secondary_64’ [-Wmissing-prototypes]
    arch/x86/kernel/head64.c:350:12: warning: no previous prototype for ‘early_make_pgtable’ [-Wmissing-prototypes]

    [ mingo: rewrote the changelog, fixed build errors. ]

    Signed-off-by: Yi Wang
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: akataria@vmware.com
    Cc: akpm@linux-foundation.org
    Cc: andy.shevchenko@gmail.com
    Cc: anton@enomsg.org
    Cc: ard.biesheuvel@linaro.org
    Cc: bhe@redhat.com
    Cc: bhelgaas@google.com
    Cc: bp@alien8.de
    Cc: ccross@android.com
    Cc: devicetree@vger.kernel.org
    Cc: douly.fnst@cn.fujitsu.com
    Cc: dwmw@amazon.co.uk
    Cc: dyoung@redhat.com
    Cc: ebiederm@xmission.com
    Cc: frank.rowand@sony.com
    Cc: frowand.list@gmail.com
    Cc: ivan.gorinov@intel.com
    Cc: jailhouse-dev@googlegroups.com
    Cc: jan.kiszka@siemens.com
    Cc: jgross@suse.com
    Cc: jroedel@suse.de
    Cc: keescook@chromium.org
    Cc: kexec@lists.infradead.org
    Cc: konrad.wilk@oracle.com
    Cc: kvm@vger.kernel.org
    Cc: linux-efi@vger.kernel.org
    Cc: linux-pci@vger.kernel.org
    Cc: luto@kernel.org
    Cc: m.mizuma@jp.fujitsu.com
    Cc: namit@vmware.com
    Cc: oleg@redhat.com
    Cc: pasha.tatashin@oracle.com
    Cc: pbonzini@redhat.com
    Cc: prarit@redhat.com
    Cc: pravin.shedge4linux@gmail.com
    Cc: rajvi.jingar@intel.com
    Cc: rkrcmar@redhat.com
    Cc: robh+dt@kernel.org
    Cc: robh@kernel.org
    Cc: rostedt@goodmis.org
    Cc: takahiro.akashi@linaro.org
    Cc: thomas.lendacky@amd.com
    Cc: tony.luck@intel.com
    Cc: up2wing@gmail.com
    Cc: virtualization@lists.linux-foundation.org
    Cc: zhe.he@windriver.com
    Cc: zhong.weidong@zte.com.cn
    Link: http://lkml.kernel.org/r/1542852249-19820-1-git-send-email-wang.yi59@zte.com.cn
    Signed-off-by: Ingo Molnar

    Yi Wang
     

14 Apr, 2018

6 commits

  • For s390 new kernels are loaded to fixed addresses in memory before they
    are booted. With the current code this is a problem as it assumes the
    kernel will be loaded to an 'arbitrary' address. In particular,
    kexec_locate_mem_hole searches for a large enough memory region and sets
    the load address (kexec_bufer->mem) to it.

    Luckily there is a simple workaround for this problem. By returning 1
    in arch_kexec_walk_mem, kexec_locate_mem_hole is turned off. This
    allows the architecture to set kbuf->mem by hand. While the trick works
    fine for the kernel it does not for the purgatory as here the
    architectures don't have access to its kexec_buffer.

    Give architectures access to the purgatories kexec_buffer by changing
    kexec_load_purgatory to take a pointer to it. With this change
    architectures have access to the buffer and can edit it as they need.

    A nice side effect of this change is that we can get rid of the
    purgatory_info->purgatory_load_address field. As now the information
    stored there can directly be accessed from kbuf->mem.

    Link: http://lkml.kernel.org/r/20180321112751.22196-11-prudo@linux.vnet.ibm.com
    Signed-off-by: Philipp Rudo
    Reviewed-by: Martin Schwidefsky
    Acked-by: Dave Young
    Cc: AKASHI Takahiro
    Cc: Eric Biederman
    Cc: Heiko Carstens
    Cc: Ingo Molnar
    Cc: Michael Ellerman
    Cc: Thiago Jung Bauermann
    Cc: Vivek Goyal
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Philipp Rudo
     
  • When the relocations are applied to the purgatory only the section the
    relocations are applied to is writable. The other sections, i.e. the
    symtab and .rel/.rela, are in read-only kexec_purgatory. Highlight this
    by marking the corresponding variables as 'const'.

    While at it also change the signatures of arch_kexec_apply_relocations* to
    take section pointers instead of just the index of the relocation section.
    This removes the second lookup and sanity check of the sections in arch
    code.

    Link: http://lkml.kernel.org/r/20180321112751.22196-6-prudo@linux.vnet.ibm.com
    Signed-off-by: Philipp Rudo
    Acked-by: Dave Young
    Cc: AKASHI Takahiro
    Cc: Eric Biederman
    Cc: Heiko Carstens
    Cc: Ingo Molnar
    Cc: Martin Schwidefsky
    Cc: Michael Ellerman
    Cc: Thiago Jung Bauermann
    Cc: Vivek Goyal
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Philipp Rudo
     
  • The kexec_purgatory buffer is read-only. Thus all pointers into
    kexec_purgatory are read-only, too. Point this out by explicitly
    marking purgatory_info->ehdr as 'const' and update the comments in
    purgatory_info.

    Link: http://lkml.kernel.org/r/20180321112751.22196-4-prudo@linux.vnet.ibm.com
    Signed-off-by: Philipp Rudo
    Acked-by: Dave Young
    Cc: AKASHI Takahiro
    Cc: Eric Biederman
    Cc: Heiko Carstens
    Cc: Ingo Molnar
    Cc: Martin Schwidefsky
    Cc: Michael Ellerman
    Cc: Thiago Jung Bauermann
    Cc: Vivek Goyal
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Philipp Rudo
     
  • Patch series "kexec_file: Clean up purgatory load", v2.

    Following the discussion with Dave and AKASHI, here are the common code
    patches extracted from my recent patch set (Add kexec_file_load support
    to s390) [1]. The patches were extracted to allow upstream integration
    together with AKASHI's common code patches before the arch code gets
    adjusted to the new base.

    The reason for this series is to prepare common code for adding
    kexec_file_load to s390 as well as cleaning up the mis-use of the
    sh_offset field during purgatory load. In detail this series contains:

    Patch #1&2: Minor cleanups/fixes.

    Patch #3-9: Clean up the purgatory load/relocation code. Especially
    remove the mis-use of the purgatory_info->sechdrs->sh_offset field,
    currently holding a pointer into either kexec_purgatory (ro) or
    purgatory_buf (rw) depending on the section. With these patches the
    section address will be calculated verbosely and sh_offset will contain
    the offset of the section in the stripped purgatory binary
    (purgatory_buf).

    Patch #10: Allows architectures to set the purgatory load address. This
    patch is important for s390 as the kernel and purgatory have to be
    loaded to fixed addresses. In current code this is impossible as the
    purgatory load is opaque to the architecture.

    Patch #11: Moves x86 purgatories sha implementation to common lib/
    directory to allow reuse in other architectures.

    This patch (of 11)

    When building the kernel with CONFIG_KEXEC_FILE enabled gcc prints a
    compile warning multiple times.

    In file included from /linux/init/initramfs.c:526:0:
    /include/linux/kexec.h:120:9: warning: `struct kimage' declared inside parameter list [enabled by default]
    unsigned long cmdline_len);
    ^

    This is because the typedefs for kexec_file_load uses struct kimage
    before it is declared. Fix this by simply forward declaring struct
    kimage.

    Link: http://lkml.kernel.org/r/20180321112751.22196-2-prudo@linux.vnet.ibm.com
    Signed-off-by: Philipp Rudo
    Acked-by: Dave Young
    Cc: Eric Biederman
    Cc: Vivek Goyal
    Cc: Michael Ellerman
    Cc: Thiago Jung Bauermann
    Cc: Martin Schwidefsky
    Cc: Heiko Carstens
    Cc: AKASHI Takahiro
    Cc: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Philipp Rudo
     
  • In the previous patches, commonly-used routines, exclude_mem_range() and
    prepare_elf64_headers(), were carved out. Now place them in kexec
    common code. A prefix "crash_" is given to each of their names to avoid
    possible name collisions.

    Link: http://lkml.kernel.org/r/20180306102303.9063-8-takahiro.akashi@linaro.org
    Signed-off-by: AKASHI Takahiro
    Acked-by: Dave Young
    Tested-by: Dave Young
    Cc: Vivek Goyal
    Cc: Baoquan He
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    AKASHI Takahiro
     
  • As arch_kexec_kernel_image_{probe,load}(),
    arch_kimage_file_post_load_cleanup() and arch_kexec_kernel_verify_sig()
    are almost duplicated among architectures, they can be commonalized with
    an architecture-defined kexec_file_ops array. So let's factor them out.

    Link: http://lkml.kernel.org/r/20180306102303.9063-3-takahiro.akashi@linaro.org
    Signed-off-by: AKASHI Takahiro
    Acked-by: Dave Young
    Tested-by: Dave Young
    Cc: Vivek Goyal
    Cc: Baoquan He
    Cc: Michael Ellerman
    Cc: Thiago Jung Bauermann
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    AKASHI Takahiro
     

03 Apr, 2018

1 commit


07 Nov, 2017

1 commit

  • In preperation for a new function that will need additional resource
    information during the resource walk, update the resource walk callback to
    pass the resource structure. Since the current callback start and end
    arguments are pulled from the resource structure, the callback functions
    can obtain them from the resource structure directly.

    Signed-off-by: Tom Lendacky
    Signed-off-by: Brijesh Singh
    Signed-off-by: Thomas Gleixner
    Reviewed-by: Kees Cook
    Reviewed-by: Borislav Petkov
    Tested-by: Borislav Petkov
    Cc: kvm@vger.kernel.org
    Cc: Benjamin Herrenschmidt
    Cc: Borislav Petkov
    Cc: linuxppc-dev@lists.ozlabs.org
    Link: https://lkml.kernel.org/r/20171020143059.3291-10-brijesh.singh@amd.com

    Tom Lendacky
     

02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

18 Jul, 2017

1 commit

  • Provide support so that kexec can be used to boot a kernel when SME is
    enabled.

    Support is needed to allocate pages for kexec without encryption. This
    is needed in order to be able to reboot in the kernel in the same manner
    as originally booted.

    Additionally, when shutting down all of the CPUs we need to be sure to
    flush the caches and then halt. This is needed when booting from a state
    where SME was not active into a state where SME is active (or vice-versa).
    Without these steps, it is possible for cache lines to exist for the same
    physical location but tagged both with and without the encryption bit. This
    can cause random memory corruption when caches are flushed depending on
    which cacheline is written last.

    Signed-off-by: Tom Lendacky
    Reviewed-by: Thomas Gleixner
    Reviewed-by: Borislav Petkov
    Cc:
    Cc: Alexander Potapenko
    Cc: Andrey Ryabinin
    Cc: Andy Lutomirski
    Cc: Arnd Bergmann
    Cc: Borislav Petkov
    Cc: Brijesh Singh
    Cc: Dave Young
    Cc: Dmitry Vyukov
    Cc: Jonathan Corbet
    Cc: Konrad Rzeszutek Wilk
    Cc: Larry Woodman
    Cc: Linus Torvalds
    Cc: Matt Fleming
    Cc: Michael S. Tsirkin
    Cc: Paolo Bonzini
    Cc: Peter Zijlstra
    Cc: Radim Krčmář
    Cc: Rik van Riel
    Cc: Toshimitsu Kani
    Cc: kasan-dev@googlegroups.com
    Cc: kvm@vger.kernel.org
    Cc: linux-arch@vger.kernel.org
    Cc: linux-doc@vger.kernel.org
    Cc: linux-efi@vger.kernel.org
    Cc: linux-mm@kvack.org
    Link: http://lkml.kernel.org/r/b95ff075db3e7cd545313f2fb609a49619a09625.1500319216.git.thomas.lendacky@amd.com
    Signed-off-by: Ingo Molnar

    Tom Lendacky
     

13 Jul, 2017

1 commit

  • 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.com
    Signed-off-by: Xunlei Pang
    Tested-by: Michael Holzheu
    Cc: Benjamin Herrenschmidt
    Cc: Dave Young
    Cc: Eric Biederman
    Cc: Hari Bathini
    Cc: Juergen Gross
    Cc: Mahesh Salgaonkar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Xunlei Pang
     

05 Jul, 2017

1 commit

  • After commmit 692f66f26a4c19 ("crash: move crashkernel parsing and vmcore
    related code under CONFIG_CRASH_CORE") the KEXEC_NOTE_BYTES macro is not
    used anymore and for s390 we create the ELF header in the new kernel
    anyway. Therefore remove the macro.

    Reported-by: Xunlei Pang
    Reviewed-by: Mikhail Zaslonko
    Signed-off-by: Michael Holzheu
    Signed-off-by: Martin Schwidefsky

    Michael Holzheu
     

09 May, 2017

1 commit

  • Patch series "kexec/fadump: remove dependency with CONFIG_KEXEC and
    reuse crashkernel parameter for fadump", v4.

    Traditionally, kdump is used to save vmcore in case of a crash. Some
    architectures like powerpc can save vmcore using architecture specific
    support instead of kexec/kdump mechanism. Such architecture specific
    support also needs to reserve memory, to be used by dump capture kernel.
    crashkernel parameter can be a reused, for memory reservation, by such
    architecture specific infrastructure.

    This patchset removes dependency with CONFIG_KEXEC for crashkernel
    parameter and vmcoreinfo related code as it can be reused without kexec
    support. Also, crashkernel parameter is reused instead of
    fadump_reserve_mem to reserve memory for fadump.

    The first patch moves crashkernel parameter parsing and vmcoreinfo
    related code under CONFIG_CRASH_CORE instead of CONFIG_KEXEC_CORE. The
    second patch reuses the definitions of append_elf_note() & final_note()
    functions under CONFIG_CRASH_CORE in IA64 arch code. The third patch
    removes dependency on CONFIG_KEXEC for firmware-assisted dump (fadump)
    in powerpc. The next patch reuses crashkernel parameter for reserving
    memory for fadump, instead of the fadump_reserve_mem parameter. This
    has the advantage of using all syntaxes crashkernel parameter supports,
    for fadump as well. The last patch updates fadump kernel documentation
    about use of crashkernel parameter.

    This patch (of 5):

    Traditionally, kdump is used to save vmcore in case of a crash. Some
    architectures like powerpc can save vmcore using architecture specific
    support instead of kexec/kdump mechanism. Such architecture specific
    support also needs to reserve memory, to be used by dump capture kernel.
    crashkernel parameter can be a reused, for memory reservation, by such
    architecture specific infrastructure.

    But currently, code related to vmcoreinfo and parsing of crashkernel
    parameter is built under CONFIG_KEXEC_CORE. This patch introduces
    CONFIG_CRASH_CORE and moves the above mentioned code under this config,
    allowing code reuse without dependency on CONFIG_KEXEC. There is no
    functional change with this patch.

    Link: http://lkml.kernel.org/r/149035338104.6881.4550894432615189948.stgit@hbathini.in.ibm.com
    Signed-off-by: Hari Bathini
    Acked-by: Dave Young
    Cc: Fenghua Yu
    Cc: Tony Luck
    Cc: Eric Biederman
    Cc: Mahesh Salgaonkar
    Cc: Vivek Goyal
    Cc: Michael Ellerman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hari Bathini
     

17 Dec, 2016

1 commit

  • Pull powerpc updates from Michael Ellerman:
    "Highlights include:

    - Support for the kexec_file_load() syscall, which is a prereq for
    secure and trusted boot.

    - Prevent kernel execution of userspace on P9 Radix (similar to
    SMEP/PXN).

    - Sort the exception tables at build time, to save time at boot, and
    store them as relative offsets to save space in the kernel image &
    memory.

    - Allow building the kernel with thin archives, which should allow us
    to build an allyesconfig once some other fixes land.

    - Build fixes to allow us to correctly rebuild when changing the
    kernel endian from big to little or vice versa.

    - Plumbing so that we can avoid doing a full mm TLB flush on P9
    Radix.

    - Initial stack protector support (-fstack-protector).

    - Support for dumping the radix (aka. Linux) and hash page tables via
    debugfs.

    - Fix an oops in cxl coredump generation when cxl_get_fd() is used.

    - Freescale updates from Scott: "Highlights include 8xx hugepage
    support, qbman fixes/cleanup, device tree updates, and some misc
    cleanup."

    - Many and varied fixes and minor enhancements as always.

    Thanks to:
    Alexey Kardashevskiy, Andrew Donnellan, Aneesh Kumar K.V, Anshuman
    Khandual, Anton Blanchard, Balbir Singh, Bartlomiej Zolnierkiewicz,
    Christophe Jaillet, Christophe Leroy, Denis Kirjanov, Elimar
    Riesebieter, Frederic Barrat, Gautham R. Shenoy, Geliang Tang, Geoff
    Levand, Jack Miller, Johan Hovold, Lars-Peter Clausen, Libin,
    Madhavan Srinivasan, Michael Neuling, Nathan Fontenot, Naveen N.
    Rao, Nicholas Piggin, Pan Xinhui, Peter Senna Tschudin, Rashmica
    Gupta, Rui Teng, Russell Currey, Scott Wood, Simon Guo, Suraj
    Jitindar Singh, Thiago Jung Bauermann, Tobias Klauser, Vaibhav Jain"

    [ And thanks to Michael, who took time off from a new baby to get this
    pull request done. - Linus ]

    * tag 'powerpc-4.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: (174 commits)
    powerpc/fsl/dts: add FMan node for t1042d4rdb
    powerpc/fsl/dts: add sg_2500_aqr105_phy4 alias on t1024rdb
    powerpc/fsl/dts: add QMan and BMan nodes on t1024
    powerpc/fsl/dts: add QMan and BMan nodes on t1023
    soc/fsl/qman: test: use DEFINE_SPINLOCK()
    powerpc/fsl-lbc: use DEFINE_SPINLOCK()
    powerpc/8xx: Implement support of hugepages
    powerpc: get hugetlbpage handling more generic
    powerpc: port 64 bits pgtable_cache to 32 bits
    powerpc/boot: Request no dynamic linker for boot wrapper
    soc/fsl/bman: Use resource_size instead of computation
    soc/fsl/qe: use builtin_platform_driver
    powerpc/fsl_pmc: use builtin_platform_driver
    powerpc/83xx/suspend: use builtin_platform_driver
    powerpc/ftrace: Fix the comments for ftrace_modify_code
    powerpc/perf: macros for power9 format encoding
    powerpc/perf: power9 raw event format encoding
    powerpc/perf: update attribute_group data structure
    powerpc/perf: factor out the event format field
    powerpc/mm/iommu, vfio/spapr: Put pages on VFIO container shutdown
    ...

    Linus Torvalds
     

15 Dec, 2016

1 commit

  • This reverts commit 0549a3c02efb ("kdump, vmcoreinfo: report memory
    sections virtual addresses").

    Commit 0549a3c02efb tells the userspace utility makedumpfile the
    randomized base address of these memmory sections when mm kaslr is
    enabled. However the following patch "kexec: export the value of
    phys_base instead of symbol address" makes makedumpfile not need these
    addresses any more.

    Besides we should use VMCOREINFO_NUMBER to export the value of the
    variable so that we can use the existing number_table mechanism of
    Makedumpfile to fetch it. So revert it now. If needed we can add it
    later.

    http://lists.infradead.org/pipermail/kexec/2016-October/017540.html
    Link: http://lkml.kernel.org/r/1478568596-30060-1-git-send-email-bhe@redhat.com
    Signed-off-by: Baoquan He
    Cc: Thomas Garnier
    Cc: Baoquan He
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: "H . Peter Anvin"
    Cc: Eric Biederman
    Cc: Xunlei Pang
    Cc: HATAYAMA Daisuke
    Cc: Kees Cook
    Cc: Eugene Surovegin
    Cc: Dave Young
    Cc: AKASHI Takahiro
    Cc: Atsushi Kumagai
    Cc: Dave Anderson
    Cc: Pratyush Anand
    Cc: Vivek Goyal
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Baoquan He
     

30 Nov, 2016

3 commits


12 Oct, 2016

1 commit

  • KASLR memory randomization can randomize the base of the physical memory
    mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap
    (VMEMMAP_START). Adding these variables on VMCOREINFO so tools can easily
    identify the base of each memory section.

    Link: http://lkml.kernel.org/r/1471531632-23003-1-git-send-email-thgarnie@google.com
    Signed-off-by: Thomas Garnier
    Acked-by: Baoquan He
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: "H . Peter Anvin"
    Cc: Eric Biederman
    Cc: Xunlei Pang
    Cc: HATAYAMA Daisuke
    Cc: Kees Cook
    Cc: Eugene Surovegin
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Thomas Garnier
     

03 Aug, 2016

4 commits

  • Provide a wrapper function to be used by kernel code to check whether a
    crash kernel is loaded. It returns the same value that can be seen in
    /sys/kernel/kexec_crash_loaded by userspace programs.

    I'm exporting the function, because it will be used by Xen, and it is
    possible to compile Xen modules separately to enable the use of PV
    drivers with unmodified bare-metal kernels.

    Link: http://lkml.kernel.org/r/20160713121955.14969.69080.stgit@hananiah.suse.cz
    Signed-off-by: Petr Tesarik
    Cc: Juergen Gross
    Cc: Josh Triplett
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: Eric Biederman
    Cc: "H. Peter Anvin"
    Cc: Boris Ostrovsky
    Cc: "Paul E. McKenney"
    Cc: Dave Young
    Cc: David Vrabel
    Cc: Vivek Goyal
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Petr Tesarik
     
  • kexec physical addresses are the boot-time view of the system. For
    certain ARM systems (such as Keystone 2), the boot view of the system
    does not match the kernel's view of the system: the boot view uses a
    special alias in the lower 4GB of the physical address space.

    To cater for these kinds of setups, we need to translate between the
    boot view physical addresses and the normal kernel view physical
    addresses. This patch extracts the current transation points into
    linux/kexec.h, and allows an architecture to override the functions.

    Due to the translations required, we unfortunately end up with six
    translation functions, which are reduced down to four that the
    architecture can override.

    [akpm@linux-foundation.org: kexec.h needs asm/io.h for phys_to_virt()]
    Link: http://lkml.kernel.org/r/E1b8koP-0004HZ-Vf@rmk-PC.armlinux.org.uk
    Signed-off-by: Russell King
    Cc: Keerthy
    Cc: Pratyush Anand
    Cc: Vitaly Andrianov
    Cc: Eric Biederman
    Cc: Dave Young
    Cc: Baoquan He
    Cc: Vivek Goyal
    Cc: Simon Horman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Russell King
     
  • On PAE systems (eg, ARM LPAE) the vmcore note may be located above 4GB
    physical on 32-bit architectures, so we need a wider type than "unsigned
    long" here. Arrange for paddr_vmcoreinfo_note() to return a
    phys_addr_t, thereby allowing it to be located above 4GB.

    This makes no difference for kexec-tools, as they already assume a
    64-bit type when reading from this file.

    Link: http://lkml.kernel.org/r/E1b8koK-0004HS-K9@rmk-PC.armlinux.org.uk
    Signed-off-by: Russell King
    Reviewed-by: Pratyush Anand
    Acked-by: Baoquan He
    Cc: Keerthy
    Cc: Vitaly Andrianov
    Cc: Eric Biederman
    Cc: Dave Young
    Cc: Vivek Goyal
    Cc: Simon Horman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Russell King
     
  • If we are unable to find a suitable page when allocating the control
    page, do not invoke the OOM-killer: killing processes probably isn't
    going to help.

    Link: http://lkml.kernel.org/r/E1b8ko9-0004HG-R5@rmk-PC.armlinux.org.uk
    Signed-off-by: Russell King
    Reviewed-by: Pratyush Anand
    Acked-by: Baoquan He
    Cc: Keerthy
    Cc: Vitaly Andrianov
    Cc: Eric Biederman
    Cc: Dave Young
    Cc: Vivek Goyal
    Cc: Simon Horman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Russell King
     

24 May, 2016

2 commits

  • …unprotect)_crashkres()

    Commit 3f625002581b ("kexec: introduce a protection mechanism for the
    crashkernel reserved memory") is a similar mechanism for protecting the
    crash kernel reserved memory to previous crash_map/unmap_reserved_pages()
    implementation, the new one is more generic in name and cleaner in code
    (besides, some arch may not be allowed to unmap the pgtable).

    Therefore, this patch consolidates them, and uses the new
    arch_kexec_protect(unprotect)_crashkres() to replace former
    crash_map/unmap_reserved_pages() which by now has been only used by
    S390.

    The consolidation work needs the crash memory to be mapped initially,
    this is done in machine_kdump_pm_init() which is after
    reserve_crashkernel(). Once kdump kernel is loaded, the new
    arch_kexec_protect_crashkres() implemented for S390 will actually
    unmap the pgtable like before.

    Signed-off-by: Xunlei Pang <xlpang@redhat.com>
    Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
    Acked-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Minfei Huang <mhuang@redhat.com>
    Cc: Vivek Goyal <vgoyal@redhat.com>
    Cc: Dave Young <dyoung@redhat.com>
    Cc: Baoquan He <bhe@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

    Xunlei Pang
     
  • 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: Xunlei Pang
    Cc: Eric Biederman
    Cc: Dave Young
    Cc: Minfei Huang
    Cc: Vivek Goyal
    Cc: Baoquan He
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Xunlei Pang
     

21 Jan, 2016

1 commit


19 Dec, 2015

1 commit

  • Currently, panic() and crash_kexec() can be called at the same time.
    For example (x86 case):

    CPU 0:
    oops_end()
    crash_kexec()
    mutex_trylock() // acquired
    nmi_shootdown_cpus() // stop other CPUs

    CPU 1:
    panic()
    crash_kexec()
    mutex_trylock() // failed to acquire
    smp_send_stop() // stop other CPUs
    infinite loop

    If CPU 1 calls smp_send_stop() before nmi_shootdown_cpus(), kdump
    fails.

    In another case:

    CPU 0:
    oops_end()
    crash_kexec()
    mutex_trylock() // acquired

    io_check_error()
    panic()
    crash_kexec()
    mutex_trylock() // failed to acquire
    infinite loop

    Clearly, this is an undesirable result.

    To fix this problem, this patch changes crash_kexec() to exclude others
    by using the panic_cpu atomic.

    Signed-off-by: Hidehiro Kawai
    Acked-by: Michal Hocko
    Cc: Andrew Morton
    Cc: Baoquan He
    Cc: Dave Young
    Cc: "Eric W. Biederman"
    Cc: HATAYAMA Daisuke
    Cc: "H. Peter Anvin"
    Cc: Ingo Molnar
    Cc: Jonathan Corbet
    Cc: kexec@lists.infradead.org
    Cc: linux-doc@vger.kernel.org
    Cc: Martin Schwidefsky
    Cc: Masami Hiramatsu
    Cc: Minfei Huang
    Cc: Peter Zijlstra
    Cc: Seth Jennings
    Cc: Steven Rostedt
    Cc: Thomas Gleixner
    Cc: Vitaly Kuznetsov
    Cc: Vivek Goyal
    Cc: x86-ml
    Link: http://lkml.kernel.org/r/20151210014630.25437.94161.stgit@softrs
    Signed-off-by: Borislav Petkov
    Signed-off-by: Thomas Gleixner

    Hidehiro Kawai
     

11 Sep, 2015

1 commit

  • There are two kexec load syscalls, kexec_load another and kexec_file_load.
    kexec_file_load has been splited as kernel/kexec_file.c. In this patch I
    split kexec_load syscall code to kernel/kexec.c.

    And add a new kconfig option KEXEC_CORE, so we can disable kexec_load and
    use kexec_file_load only, or vice verse.

    The original requirement is from Ted Ts'o, he want kexec kernel signature
    being checked with CONFIG_KEXEC_VERIFY_SIG enabled. But kexec-tools use
    kexec_load syscall can bypass the checking.

    Vivek Goyal proposed to create a common kconfig option so user can compile
    in only one syscall for loading kexec kernel. KEXEC/KEXEC_FILE selects
    KEXEC_CORE so that old config files still work.

    Because there's general code need CONFIG_KEXEC_CORE, so I updated all the
    architecture Kconfig with a new option KEXEC_CORE, and let KEXEC selects
    KEXEC_CORE in arch Kconfig. Also updated general kernel code with to
    kexec_load syscall.

    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: Dave Young
    Cc: Eric W. Biederman
    Cc: Vivek Goyal
    Cc: Petr Tesarik
    Cc: Theodore Ts'o
    Cc: Josh Boyer
    Cc: David Howells
    Cc: Geert Uytterhoeven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave Young