1. 06 Aug, 2020 1 commit
  2. 07 Jul, 2020 1 commit
  3. 17 Jun, 2020 1 commit
    • Arvind Sankar's avatar
      x86/purgatory: Add -fno-stack-protector · ff58155c
      Arvind Sankar authored
      The purgatory Makefile removes -fstack-protector options if they were
      configured in, but does not currently add -fno-stack-protector.
      
      If gcc was configured with the --enable-default-ssp configure option,
      this results in the stack protector still being enabled for the
      purgatory (absent distro-specific specs files that might disable it
      again for freestanding compilations), if the main kernel is being
      compiled with stack protection enabled (if it's disabled for the main
      kernel, the top-level Makefile will add -fno-stack-protector).
      
      This will break the build since commit
        e4160b2e
      
       ("x86/purgatory: Fail the build if purgatory.ro has missing symbols")
      and prior to that would have caused runtime failure when trying to use
      kexec.
      
      Explicitly add -fno-stack-protector to avoid this, as done in other
      Makefiles that need to disable the stack protector.
      Reported-by: default avatarGabriel C <nix.or.die@googlemail.com>
      Signed-off-by: default avatarArvind Sankar <nivedita@alum.mit.edu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ff58155c
  4. 17 Mar, 2020 2 commits
    • Hans de Goede's avatar
      x86/purgatory: Fail the build if purgatory.ro has missing symbols · e4160b2e
      Hans de Goede authored
      
      
      Linking purgatory.ro with -r enables "incremental linking"; this means
      no checks for unresolved symbols are done while linking purgatory.ro.
      
      A change to the sha256 code has caused the purgatory in 5.4-rc1 to have
      a missing symbol on memzero_explicit(), yet things still happily build.
      
      Add an extra check for unresolved symbols by calling ld without -r
      before running bin2c to generate kexec-purgatory.c.
      
      This causes a build of 5.4-rc1 with this patch added to fail as it should:
      
          CHK     arch/x86/purgatory/purgatory.ro
        ld: arch/x86/purgatory/purgatory.ro: in function `sha256_transform':
        sha256.c:(.text+0x1c0c): undefined reference to `memzero_explicit'
        make[2]: *** [arch/x86/purgatory/Makefile:72:
            arch/x86/purgatory/kexec-purgatory.c] Error 1
        make[1]: *** [scripts/Makefile.build:509: arch/x86/purgatory] Error 2
        make: *** [Makefile:1650: arch/x86] Error 2
      
      Also remove --no-undefined from LDFLAGS_purgatory.ro as that has no
      effect.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Link: https://lkml.kernel.org/r/20200317130841.290418-2-hdegoede@redhat.com
      e4160b2e
    • Hans de Goede's avatar
      x86/purgatory: Disable various profiling and sanitizing options · e2ac07c0
      Hans de Goede authored
      
      
      Since the purgatory is a special stand-alone binary, various profiling
      and sanitizing options must be disabled. Having these options enabled
      typically will cause dependencies on various special symbols exported by
      special libs / stubs used by these frameworks. Since the purgatory is
      special, it is not linked against these stubs causing missing symbols in
      the purgatory if these options are not disabled.
      
      Sync the set of disabled profiling and sanitizing options with that from
      drivers/firmware/efi/libstub/Makefile, adding
      -DDISABLE_BRANCH_PROFILING to the CFLAGS and setting:
      
        GCOV_PROFILE                    := n
        UBSAN_SANITIZE                  := n
      
      This fixes broken references to ftrace_likely_update() when
      CONFIG_TRACE_BRANCH_PROFILING is enabled and to __gcov_init() and
      __gcov_exit() when CONFIG_GCOV_KERNEL is enabled.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Link: https://lkml.kernel.org/r/20200317130841.290418-1-hdegoede@redhat.com
      e2ac07c0
  5. 16 Nov, 2019 1 commit
  6. 23 Sep, 2019 1 commit
  7. 06 Sep, 2019 1 commit
    • Steve Wahl's avatar
      x86/purgatory: Change compiler flags from -mcmodel=kernel to -mcmodel=large to... · e16c2983
      Steve Wahl authored
      
      x86/purgatory: Change compiler flags from -mcmodel=kernel to -mcmodel=large to fix kexec relocation errors
      
      The last change to this Makefile caused relocation errors when loading
      a kdump kernel.  Restore -mcmodel=large (not -mcmodel=kernel),
      -ffreestanding, and -fno-zero-initialized-bsss, without reverting to
      the former practice of resetting KBUILD_CFLAGS.
      
      Purgatory.ro is a standalone binary that is not linked against the
      rest of the kernel.  Its image is copied into an array that is linked
      to the kernel, and from there kexec relocates it wherever it desires.
      
      With the previous change to compiler flags, the error "kexec: Overflow
      in relocation type 11 value 0x11fffd000" was encountered when trying
      to load the crash kernel.  This is from kexec code trying to relocate
      the purgatory.ro object.
      
      From the error message, relocation type 11 is R_X86_64_32S.  The
      x86_64 ABI says:
      
        "The R_X86_64_32 and R_X86_64_32S relocations truncate the
         computed value to 32-bits.  The linker must verify that the
         generated value for the R_X86_64_32 (R_X86_64_32S) relocation
         zero-extends (sign-extends) to the original 64-bit value."
      
      This type of relocation doesn't work when kexec chooses to place the
      purgatory binary in memory that is not reachable with 32 bit
      addresses.
      
      The compiler flag -mcmodel=kernel allows those type of relocations to
      be emitted, so revert to using -mcmodel=large as was done before.
      
      Also restore the -ffreestanding and -fno-zero-initialized-bss flags
      because they are appropriate for a stand alone piece of object code
      which doesn't explicitly zero the bss, and one other report has said
      undefined symbols are encountered without -ffreestanding.
      
      These identical compiler flag changes need to happen for every object
      that becomes part of the purgatory.ro object, so gather them together
      first into PURGATORY_CFLAGS_REMOVE and PURGATORY_CFLAGS, and then
      apply them to each of the objects that have C source.  Do not apply
      any of these flags to kexec-purgatory.o, which is not part of the
      standalone object but part of the kernel proper.
      Tested-by: default avatarVaibhav Rustagi <vaibhavrustagi@google.com>
      Tested-by: default avatarAndreas Smas <andreas@lonelycoder.com>
      Signed-off-by: default avatarSteve Wahl <steve.wahl@hpe.com>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: None
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: clang-built-linux@googlegroups.com
      Cc: dimitri.sivanich@hpe.com
      Cc: mike.travis@hpe.com
      Cc: russ.anderson@hpe.com
      Fixes: b059f801 ("x86/purgatory: Use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS")
      Link: https://lkml.kernel.org/r/20190905202346.GA26595@swahl-linux
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      e16c2983
  8. 22 Aug, 2019 2 commits
  9. 08 Aug, 2019 2 commits
  10. 17 Jul, 2018 1 commit
    • Masahiro Yamada's avatar
      kbuild: move bin2c back to scripts/ from scripts/basic/ · c417fbce
      Masahiro Yamada authored
      Commit 8370edea ("bin2c: move bin2c in scripts/basic") moved bin2c
      to the scripts/basic/ directory, incorrectly stating "Kexec wants to
      use bin2c and it wants to use it really early in the build process.
      See arch/x86/purgatory/ code in later patches."
      
      Commit bdab125c ("Revert "kexec/purgatory: Add clean-up for
      purgatory directory"") and commit d6605b6b
      
       ("x86/build: Remove
      unnecessary preparation for purgatory") removed the redundant
      purgatory build magic entirely.
      
      That means that the move of bin2c was unnecessary in the first place.
      
      fixdep is the only host program that deserves to sit in the
      scripts/basic/ directory.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      c417fbce
  11. 14 Jul, 2018 1 commit
  12. 14 Apr, 2018 1 commit
  13. 25 Mar, 2018 1 commit
  14. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      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...
      b2441318
  15. 01 Apr, 2017 1 commit
  16. 09 Nov, 2016 1 commit
  17. 07 Jun, 2016 1 commit
  18. 20 Apr, 2016 1 commit
  19. 29 Feb, 2016 1 commit
    • Josh Poimboeuf's avatar
      objtool: Mark non-standard object files and directories · c0dd6716
      Josh Poimboeuf authored
      
      
      Code which runs outside the kernel's normal mode of operation often does
      unusual things which can cause a static analysis tool like objtool to
      emit false positive warnings:
      
       - boot image
       - vdso image
       - relocation
       - realmode
       - efi
       - head
       - purgatory
       - modpost
      
      Set OBJECT_FILES_NON_STANDARD for their related files and directories,
      which will tell objtool to skip checking them.  It's ok to skip them
      because they don't affect runtime stack traces.
      
      Also skip the following code which does the right thing with respect to
      frame pointers, but is too "special" to be validated by a tool:
      
       - entry
       - mcount
      
      Also skip the test_nx module because it modifies its exception handling
      table at runtime, which objtool can't understand.  Fortunately it's
      just a test module so it doesn't matter much.
      
      Currently objtool is the only user of OBJECT_FILES_NON_STANDARD, but it
      might eventually be useful for other tools.
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Bernd Petrovitsch <bernd@petrovitsch.priv.at>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Chris J Arges <chris.j.arges@canonical.com>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Pedro Alves <palves@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: live-patching@vger.kernel.org
      Link: http://lkml.kernel.org/r/366c080e3844e8a5b6a0327dc7e8c2b90ca3baeb.1456719558.git.jpoimboe@redhat.com
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      c0dd6716
  20. 15 Oct, 2014 1 commit
  21. 14 Oct, 2014 1 commit
  22. 29 Aug, 2014 2 commits
    • Vivek Goyal's avatar
      x86/purgatory: use approprate -m64/-32 build flag for arch/x86/purgatory · 4df4185a
      Vivek Goyal authored
      
      
      Thomas reported that build of x86_64 kernel was failing for him.  He is
      using 32bit tool chain.
      
      Problem is that while compiling purgatory, I have not specified -m64
      flag.  And 32bit tool chain must be assuming -m32 by default.
      
      Following is error message.
      
      (mini) [~/work/linux-2.6] make
      scripts/kconfig/conf --silentoldconfig Kconfig
        CHK     include/config/kernel.release
        UPD     include/config/kernel.release
        CHK     include/generated/uapi/linux/version.h
        CHK     include/generated/utsrelease.h
        UPD     include/generated/utsrelease.h
        CC      arch/x86/purgatory/purgatory.o
      arch/x86/purgatory/purgatory.c:1:0: error: code model 'large' not supported in
      the 32 bit mode
      
      Fix it by explicitly passing appropriate -m64/-m32 build flag for
      purgatory.
      Reported-by: default avatarThomas Glanzmann <thomas@glanzmann.de>
      Tested-by: default avatarThomas Glanzmann <thomas@glanzmann.de>
      Suggested-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4df4185a
    • Vivek Goyal's avatar
      kexec: create a new config option CONFIG_KEXEC_FILE for new syscall · 74ca317c
      Vivek Goyal authored
      
      
      Currently new system call kexec_file_load() and all the associated code
      compiles if CONFIG_KEXEC=y.  But new syscall also compiles purgatory
      code which currently uses gcc option -mcmodel=large.  This option seems
      to be available only gcc 4.4 onwards.
      
      Hiding new functionality behind a new config option will not break
      existing users of old gcc.  Those who wish to enable new functionality
      will require new gcc.  Having said that, I am trying to figure out how
      can I move away from using -mcmodel=large but that can take a while.
      
      I think there are other advantages of introducing this new config
      option.  As this option will be enabled only on x86_64, other arches
      don't have to compile generic kexec code which will never be used.  This
      new code selects CRYPTO=y and CRYPTO_SHA256=y.  And all other arches had
      to do this for CONFIG_KEXEC.  Now with introduction of new config
      option, we can remove crypto dependency from other arches.
      
      Now CONFIG_KEXEC_FILE is available only on x86_64.  So whereever I had
      CONFIG_X86_64 defined, I got rid of that.
      
      For CONFIG_KEXEC_FILE, instead of doing select CRYPTO=y, I changed it to
      "depends on CRYPTO=y".  This should be safer as "select" is not
      recursive.
      Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Tested-by: default avatarShaun Ruffell <sruffell@digium.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      74ca317c
  23. 08 Aug, 2014 1 commit
    • Vivek Goyal's avatar
      purgatory: core purgatory functionality · 8fc5b4d4
      Vivek Goyal authored
      
      
      Create a stand alone relocatable object purgatory which runs between two
      kernels.  This name, concept and some code has been taken from
      kexec-tools.  Idea is that this code runs after a crash and it runs in
      minimal environment.  So keep it separate from rest of the kernel and in
      long term we will have to practically do no maintenance of this code.
      
      This code also has the logic to do verify sha256 hashes of various
      segments which have been loaded into memory.  So first we verify that the
      kernel we are jumping to is fine and has not been corrupted and make
      progress only if checsums are verified.
      
      This code also takes care of copying some memory contents to backup region.
      
      [sfr@canb.auug.org.au: run host built programs from objtree]
      Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Greg Kroah-Hartman <greg@kroah.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: WANG Chao <chaowang@redhat.com>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Signed-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8fc5b4d4