08 Aug, 2019
2 commits
-
KBUILD_CFLAGS is very carefully built up in the top level Makefile,
particularly when cross compiling or using different build tools.
Resetting KBUILD_CFLAGS via := assignment is an antipattern.The comment above the reset mentions that -pg is problematic. Other
Makefiles use `CFLAGS_REMOVE_file.o = $(CC_FLAGS_FTRACE)` when
CONFIG_FUNCTION_TRACER is set. Prefer that pattern to wiping out all of
the important KBUILD_CFLAGS then manually having to re-add them. Seems
also that __stack_chk_fail references are generated when using
CONFIG_STACKPROTECTOR or CONFIG_STACKPROTECTOR_STRONG.Fixes: 8fc5b4d4121c ("purgatory: core purgatory functionality")
Reported-by: Vaibhav Rustagi
Suggested-by: Peter Zijlstra
Suggested-by: Thomas Gleixner
Signed-off-by: Nick Desaulniers
Signed-off-by: Thomas Gleixner
Tested-by: Vaibhav Rustagi
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20190807221539.94583-2-ndesaulniers@google.com -
Implementing memcpy and memset in terms of __builtin_memcpy and
__builtin_memset is problematic.GCC at -O2 will replace calls to the builtins with calls to memcpy and
memset (but will generate an inline implementation at -Os). Clang will
replace the builtins with these calls regardless of optimization level.
$ llvm-objdump -dr arch/x86/purgatory/string.o | tail0000000000000339 memcpy:
339: 48 b8 00 00 00 00 00 00 00 00 movabsq $0, %rax
000000000000033b: R_X86_64_64 memcpy
343: ff e0 jmpq *%rax0000000000000345 memset:
345: 48 b8 00 00 00 00 00 00 00 00 movabsq $0, %rax
0000000000000347: R_X86_64_64 memset
34f: ff e0Such code results in infinite recursion at runtime. This is observed
when doing kexec.Instead, reuse an implementation from arch/x86/boot/compressed/string.c.
This requires to implement a stub function for warn(). Also, Clang may
lower memcmp's that compare against 0 to bcmp's, so add a small definition,
too. See also: commit 5f074f3e192f ("lib/string.c: implement a basic bcmp")Fixes: 8fc5b4d4121c ("purgatory: core purgatory functionality")
Reported-by: Vaibhav Rustagi
Debugged-by: Vaibhav Rustagi
Debugged-by: Manoj Gupta
Suggested-by: Alistair Delva
Signed-off-by: Nick Desaulniers
Signed-off-by: Thomas Gleixner
Tested-by: Vaibhav Rustagi
Cc: stable@vger.kernel.org
Link: https://bugs.chromium.org/p/chromium/issues/detail?id=984056
Link: https://lkml.kernel.org/r/20190807221539.94583-1-ndesaulniers@google.com
19 Jun, 2019
1 commit
-
Based on 2 normalized pattern(s):
this source code is licensed under the gnu general public license
version 2 see the file copying for more detailsthis source code is licensed under general public license version 2
seeextracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 52 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Enrico Weigelt
Reviewed-by: Allison Randal
Reviewed-by: Alexios Zavras
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190602204653.449021192@linutronix.de
Signed-off-by: Greg Kroah-Hartman
18 Jul, 2018
1 commit
-
Commit 8370edea81e3 ("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 bdab125c9301 ("Revert "kexec/purgatory: Add clean-up for
purgatory directory"") and commit d6605b6bbee8 ("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: Masahiro Yamada
15 Jul, 2018
1 commit
-
- Build the kernel without the fix
- Add some flag to the purgatories KBUILD_CFLAGS,I used
-fno-asynchronous-unwind-tables
- Re-build the kernelWhen you look at makes output you see that sha256.o is not re-build in the
last step. Also readelf -S still shows the .eh_frame section for
sha256.o.With the fix sha256.o is rebuilt in the last step.
Without FORCE make does not detect changes only made to the command line
options. So object files might not be re-built even when they should be.
Fix this by adding FORCE where it is missing.Link: http://lkml.kernel.org/r/20180704110044.29279-2-prudo@linux.ibm.com
Fixes: df6f2801f511 ("kernel/kexec_file.c: move purgatories sha256 to common code")
Signed-off-by: Philipp Rudo
Acked-by: Dave Young
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: [4.17+]
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
14 Apr, 2018
1 commit
-
The code to verify the new kernels sha digest is applicable for all
architectures. Move it to common code.One problem is the string.c implementation on x86. Currently sha256
includes x86/boot/string.h which defines memcpy and memset to be gcc
builtins. By moving the sha256 implementation to common code and
changing the include to linux/string.h both functions are no longer
defined. Thus definitions have to be provided in x86/purgatory/string.cLink: http://lkml.kernel.org/r/20180321112751.22196-12-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
25 Mar, 2018
1 commit
-
The kernel build system already takes care of generating the dependency
files. Having the additional -MD in KBUILD_CFLAGS leads to stray
..d files in the build directory when we call the cc-option macro.Signed-off-by: Sven Wegener
Cc: H. Peter Anvin
Cc: Kees Cook
Cc: Linus Torvalds
Cc: Matthias Kaehlcke
Cc: Peter Zijlstra
Cc: Sam Ravnborg
Cc: Thomas Gleixner
Cc: Vivek Goyal
Link: http://lkml.kernel.org/r/alpine.LNX.2.21.1803242219380.30139@titan.int.lan.stealer.net
Signed-off-by: Ingo Molnar
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
01 Apr, 2017
1 commit
-
Fixes this:
kexec: Undefined symbol: __asan_load8_noabort
kexec-bzImage64: Loading purgatory failedLink: http://lkml.kernel.org/r/1489672155.4458.7.camel@gmx.de
Signed-off-by: Mike Galbraith
Cc: Alexander Potapenko
Cc: Andrey Ryabinin
Cc: Dmitry Vyukov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
11 Mar, 2017
1 commit
-
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: 72042a8c7b01 ("x86/purgatory: Make functions and variables static")
Reported-by: Mike Galbraith <
Signed-off-by: Thomas Gleixner
Cc: Nicholas Mc Guire
Cc: Borislav Petkov
Cc: Vivek Goyal
Cc: "Tobin C. Harding"
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1703101315140.3681@nanos
Signed-off-by: Thomas Gleixner
01 Mar, 2017
2 commits
-
Sparse emits warning, 'symbol not declared' for a function that has
neither file scope nor a forward declaration. The functions only call
site is an ASM file.Add a header file with the function declaration. Include the header file in
the C source file defining the function in order to fix the sparse
warning. Include the header file in ASM file containing the call site to
document the usage.Signed-off-by: Tobin C. Harding
Link: http://lkml.kernel.org/r/1487545956-2547-3-git-send-email-me@tobin.cc
Signed-off-by: Thomas Gleixner -
Sparse emits several 'symbol not declared' warnings for various
functions and variables.Add static keyword to functions and variables which have file scope
only.Signed-off-by: Tobin C. Harding
Link: http://lkml.kernel.org/r/1487545956-2547-2-git-send-email-me@tobin.cc
Signed-off-by: Thomas Gleixner
10 Nov, 2016
1 commit
-
If the gcc is configured to do -fPIE by default then the build aborts
later with:
| Unsupported relocation type: unknown type rel type name (29)Tagging it stable so it is possible to compile recent stable kernels as
well.Cc: stable@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Michal Marek
08 Jun, 2016
1 commit
-
The sancov gcc plugin inserts a __sanitizer_cov_trace_pc() call
at the start of basic blocks.This plugin is a helper plugin for the kcov feature. It supports
all gcc versions with plugin support (from gcc-4.5 on).
It is based on the gcc commit "Add fuzzing coverage support" by Dmitry Vyukov
(https://gcc.gnu.org/viewcvs/gcc?limit_changes=0&view=revision&revision=231296).Signed-off-by: Emese Revfy
Acked-by: Kees Cook
Signed-off-by: Michal Marek
20 Apr, 2016
1 commit
-
Since commit 2aedcd098a94 ('kbuild: suppress annoying "... is up to
date." message'), $(call if_changed,...) is evaluated to "@:"
when there is nothing to do.We no longer need to add "@:" after $(call if_changed,...) to
suppress "... is up to date." message.Signed-off-by: Masahiro Yamada
Signed-off-by: Michal Marek
25 Mar, 2016
1 commit
-
Pull x86 fixes from Ingo Molnar:
"Misc fixes:- fix hotplug bugs
- fix irq live lock
- fix various topology handling bugs
- fix APIC ACK ordering
- fix PV iopl handling
- fix speling
- fix/tweak memcpy_mcsafe() return value
- fix fbcon bug
- remove stray prototypes"* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/msr: Remove unused native_read_tscp()
x86/apic: Remove declaration of unused hw_nmi_is_cpu_stuck
x86/oprofile/nmi: Add missing hotplug FROZEN handling
x86/hpet: Use proper mask to modify hotplug action
x86/apic/uv: Fix the hotplug notifier
x86/apb/timer: Use proper mask to modify hotplug action
x86/topology: Use total_cpus not nr_cpu_ids for logical packages
x86/topology: Fix Intel HT disable
x86/topology: Fix logical package mapping
x86/irq: Cure live lock in fixup_irqs()
x86/tsc: Prevent NULL pointer deref in calibrate_delay_is_known()
x86/apic: Fix suspicious RCU usage in smp_trace_call_function_interrupt()
x86/iopl: Fix iopl capability check on Xen PV
x86/iopl/64: Properly context-switch IOPL on Xen PV
selftests/x86: Add an iopl test
x86/mm, x86/mce: Fix return type/value for memcpy_mcsafe()
x86/video: Don't assume all FB devices are PCI devices
arch/x86/irq: Purge useless handler declarations from hw_irq.h
x86: Fix misspellings in comments
29 Feb, 2016
1 commit
-
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
- modpostSet 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
- mcountAlso 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: Josh Poimboeuf
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Arnaldo Carvalho de Melo
Cc: Bernd Petrovitsch
Cc: Borislav Petkov
Cc: Chris J Arges
Cc: Jiri Slaby
Cc: Linus Torvalds
Cc: Michal Marek
Cc: Namhyung Kim
Cc: Pedro Alves
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: live-patching@vger.kernel.org
Link: http://lkml.kernel.org/r/366c080e3844e8a5b6a0327dc7e8c2b90ca3baeb.1456719558.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar
24 Feb, 2016
1 commit
-
Signed-off-by: Adam Buchbinder
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: trivial@kernel.org
Signed-off-by: Ingo Molnar
11 Dec, 2014
1 commit
-
…r-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 build, cleanup and defconfig updates from Ingo Molnar:
"A single minor build change to suppress a repetitive build messages,
misc cleanups and a defconfig update"* 'x86-build-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/purgatory, build: Suppress kexec-purgatory.c is up to date message* 'x86-cleanups-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86, CPU, AMD: Move K8 TLB flush filter workaround to K8 code
x86, espfix: Remove stale ptemask
x86, msr: Use seek definitions instead of hard-coded values
x86, msr: Convert printk to pr_foo()
x86, msr: Use PTR_ERR_OR_ZERO
x86/simplefb: Use PTR_ERR_OR_ZERO
x86/sysfb: Use PTR_ERR_OR_ZERO
x86, cpuid: Use PTR_ERR_OR_ZERO* 'x86-debug-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/kconfig/defconfig: Enable CONFIG_FHANDLE=y
15 Oct, 2014
1 commit
-
Suppress this unnecessary message during kernel re-build
(CONFIG_KEXEC_FILE=y):make[1]: `arch/x86/purgatory/kexec-purgatory.c' is up to date.
Signed-off-by: WANG Chao
Link: http://lkml.kernel.org/r/1413262019-3759-1-git-send-email-chaowang@redhat.com
Signed-off-by: H. Peter Anvin
14 Oct, 2014
1 commit
-
Make the Makefile of kexec purgatory be consistent with others in linux
src tree, and make it look generic and simple.Signed-off-by: Baoquan He
Cc: Vivek Goyal
Cc: H. Peter Anvin
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Stephen Rothwell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
30 Aug, 2014
2 commits
-
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 modeFix it by explicitly passing appropriate -m64/-m32 build flag for
purgatory.Reported-by: Thomas Glanzmann
Tested-by: Thomas Glanzmann
Suggested-by: H. Peter Anvin
Signed-off-by: Vivek Goyal
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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: Vivek Goyal
Cc: Eric Biederman
Cc: H. Peter Anvin
Tested-by: Shaun Ruffell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
09 Aug, 2014
3 commits
-
This patch adds support for loading a kexec on panic (kdump) kernel usning
new system call.It prepares ELF headers for memory areas to be dumped and for saved cpu
registers. Also prepares the memory map for second kernel and limits its
boot to reserved areas only.Signed-off-by: Vivek Goyal
Cc: Borislav Petkov
Cc: Michael Kerrisk
Cc: Yinghai Lu
Cc: Eric Biederman
Cc: H. Peter Anvin
Cc: Matthew Garrett
Cc: Greg Kroah-Hartman
Cc: Dave Young
Cc: WANG Chao
Cc: Baoquan He
Cc: Andy Lutomirski
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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: Vivek Goyal
Cc: Borislav Petkov
Cc: Michael Kerrisk
Cc: Yinghai Lu
Cc: Eric Biederman
Cc: H. Peter Anvin
Cc: Matthew Garrett
Cc: Greg Kroah-Hartman
Cc: Dave Young
Cc: WANG Chao
Cc: Baoquan He
Cc: Andy Lutomirski
Signed-off-by: Stephen Rothwell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Next two patches provide code for purgatory. This is a code which does
not link against the kernel and runs stand alone. This code runs between
two kernels. One of the primary purpose of this code is to verify the
digest of newly loaded kernel and making sure it matches the digest
computed at kernel load time.We use sha256 for calculating digest of kexec segmetns. Purgatory can't
use stanard crypto API as that API is not available in purgatory context.Hence, I have copied code from crypto/sha256_generic.c and compiled it
with purgaotry code so that it could be used. I could not #include
sha256_generic.c file here as some of the function signature requiered
little tweaking. Original functions work with crypto API but these ones
don'tSo instead of doing #include on sha256_generic.c I just copied relevant
portions of code into arch/x86/purgatory/sha256.c. Now we shouldn't have
to touch this code at all. Do let me know if there are better ways to
handle it.This patch does not enable compiling of this code. That happens in next
patch. I wanted to highlight this change in a separate patch for easy
review.Signed-off-by: Vivek Goyal
Cc: Borislav Petkov
Cc: Michael Kerrisk
Cc: Yinghai Lu
Cc: Eric Biederman
Cc: H. Peter Anvin
Cc: Matthew Garrett
Cc: Greg Kroah-Hartman
Cc: Dave Young
Cc: WANG Chao
Cc: Baoquan He
Cc: Andy Lutomirski
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds