kernel.git/arch/x86/boot/string.c, branch linux-4.19.y

x86/purgatory: Do not use __builtin_memcpy and __builtin_memset

2019-08-16T08:12:50Z

commit 4ce97317f41d38584fb93578e922fcd19e535f5b upstream. 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 | tail 0000000000000339 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 *%rax 0000000000000345 memset: 345: 48 b8 00 00 00 00 00 00 00 00 movabsq $0, %rax 0000000000000347: R_X86_64_64 memset 34f: ff e0 Such 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 Signed-off-by: Greg Kroah-Hartman

x86/boot: Use CC_SET()/CC_OUT() instead of open coding it

2018-08-02T12:30:42Z

Remove open-coded uses of set instructions with CC_SET()/CC_OUT(). Signed-off-by: Uros Bizjak Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20180629142844.15200-1-ubizjak@gmail.com

x86/boot: #undef memcpy() et al in string.c

2017-07-25T09:13:55Z

undef memcpy() and friends in boot/string.c so that the functions defined here will have the correct names, otherwise we end up up trying to redefine __builtin_memcpy() etc. Surprisingly, GCC allows this (and, helpfully, discards the __builtin_ prefix from the function name when compiling it), but clang does not. Adding these #undef's appears to preserve what I assume was the original intent of the code. Signed-off-by: Michael Davidson Signed-off-by: Matthias Kaehlcke Acked-by: H. Peter Anvin Cc: Arnd Bergmann Cc: Bernhard.Rosenkranzer@linaro.org Cc: Greg Hackmann Cc: Kees Cook Cc: Linus Torvalds Cc: Nick Desaulniers Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20170724235155.79255-1-mka@chromium.org Signed-off-by: Ingo Molnar

x86/KASLR: Parse all 'memmap=' boot option entries

2017-05-24T07:50:27Z

In commit: f28442497b5c ("x86/boot: Fix KASLR and memmap= collision") ... the memmap= option is parsed so that KASLR can avoid those reserved regions. It uses cmdline_find_option() to get the value if memmap= is specified, however the problem is that cmdline_find_option() can only find the last entry if multiple memmap entries are provided. This is not correct. Address this by checking each command line token for a "memmap=" match and parse each instance instead of using cmdline_find_option(). Signed-off-by: Baoquan He Acked-by: Kees Cook Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: dan.j.williams@intel.com Cc: douly.fnst@cn.fujitsu.com Cc: dyoung@redhat.com Cc: m.mizuma@jp.fujitsu.com Link: http://lkml.kernel.org/r/1494654390-23861-2-git-send-email-bhe@redhat.com Signed-off-by: Ingo Molnar

Merge branch 'linus' into x86/boot, to pick up fixes

2017-01-28T08:30:11Z

Signed-off-by: Ingo Molnar

x86/boot: Fix KASLR and memmap= collision

2017-01-25T11:35:50Z

CONFIG_RANDOMIZE_BASE=y relocates the kernel to a random base address. However it does not take into account the memmap= parameter passed in from the kernel command line. This results in the kernel sometimes being put in the middle of memmap. Teach KASLR to not insert the kernel in memmap defined regions. We support up to 4 memmap regions: any additional regions will cause KASLR to disable. The mem_avoid set has been augmented to add up to 4 unusable regions of memmaps provided by the user to exclude those regions from the set of valid address range to insert the uncompressed kernel image. The nn@ss ranges will be skipped by the mem_avoid set since it indicates that memory is useable. Signed-off-by: Dave Jiang Reviewed-by: Thomas Gleixner Acked-by: Kees Cook Acked-by: Baoquan He Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: dan.j.williams@intel.com Cc: david@fromorbit.com Cc: linux-nvdimm@lists.01.org Link: http://lkml.kernel.org/r/148417664156.131935.2248592164852799738.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Ingo Molnar

x86/boot: Add missing declaration of string functions

2017-01-09T10:53:05Z

Add the missing declarations of basic string functions to string.h to allow a clean build. Fixes: 5be865661516 ("String-handling functions for the new x86 setup code.") Signed-off-by: Nicholas Mc Guire Link: http://lkml.kernel.org/r/1483781911-21399-1-git-send-email-hofrat@osadl.org Signed-off-by: Thomas Gleixner

x86, asm: use bool for bitops and other assembly outputs

2016-06-08T19:41:20Z

The gcc people have confirmed that using "bool" when combined with inline assembly always is treated as a byte-sized operand that can be assumed to be 0 or 1, which is exactly what the SET instruction emits. Change the output types and intermediate variables of as many operations as practical to "bool". Signed-off-by: H. Peter Anvin Link: http://lkml.kernel.org/r/1465414726-197858-3-git-send-email-hpa@linux.intel.com Reviewed-by: Andy Lutomirski Reviewed-by: Borislav Petkov Acked-by: Peter Zijlstra (Intel)

x86/boot: Standardize strcmp()

2015-03-23T09:24:12Z

strcmp() is always expected to return 0 when arguments are equal, negative when its first argument @str1 is less than its second argument @str2 and a positive value otherwise. Previously strcmp("a", "b") returned 1. Now it gives -1, as it is supposed to. Until now this bug never triggered, because all uses for strcmp() in the boot code tested for nonzero: triton:~/tip> git grep strcmp arch/x86/boot/ arch/x86/boot/boot.h:int strcmp(const char *str1, const char *str2); arch/x86/boot/edd.c: if (!strcmp(eddarg, "skipmbr") || !strcmp(eddarg, "skip")) { arch/x86/boot/edd.c: else if (!strcmp(eddarg, "off")) arch/x86/boot/edd.c: else if (!strcmp(eddarg, "on")) should in the future strcmp() be used in a comparative way in the boot code, it might have led to (not so subtle) bugs. Signed-off-by: Arjun Sreedharan Signed-off-by: Borislav Petkov Cc: H. Peter Anvin Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1426520267-1803-1-git-send-email-arjun024@gmail.com Signed-off-by: Ingo Molnar

x86, boot: Remove misc.h inclusion from compressed/string.c

2014-05-08T15:00:06Z

Given the fact that we removed inclusion of boot.h from boot/string.c does not look like we need misc.h inclusion in compressed/string.c. So remove it. misc.h was also pulling in string_32.h which in turn had macros for memcmp and memcpy. So we don't need to #undef memcmp and memcpy anymore. Signed-off-by: Vivek Goyal Link: http://lkml.kernel.org/r/1398447972-27896-3-git-send-email-vgoyal@redhat.com Signed-off-by: H. Peter Anvin