Intel OpenBMC Linux kernel source tree (mirror) https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-5.4 2020-02-05T21:22:46+00:00 2020-02-05T21:22:46+00:00 Brendan Higgins brendanhiggins@google.com 2019-12-13T00:35:22+00:00 urn:sha1:9e62f296dbaeb9a007e9b2ba82be231c5d679d22 [ Upstream commit 0e31e3573f0cd94d7b821117db854187ffc85765 ] When building ARCH=um with CONFIG_UML_X86=y and CONFIG_64BIT=y we get the build errors: drivers/misc/lkdtm/bugs.c: In function ‘lkdtm_UNSET_SMEP’: drivers/misc/lkdtm/bugs.c:288:8: error: implicit declaration of function ‘native_read_cr4’ [-Werror=implicit-function-declaration] cr4 = native_read_cr4(); ^~~~~~~~~~~~~~~ drivers/misc/lkdtm/bugs.c:290:13: error: ‘X86_CR4_SMEP’ undeclared (first use in this function); did you mean ‘X86_FEATURE_SMEP’? if ((cr4 & X86_CR4_SMEP) != X86_CR4_SMEP) { ^~~~~~~~~~~~ X86_FEATURE_SMEP drivers/misc/lkdtm/bugs.c:290:13: note: each undeclared identifier is reported only once for each function it appears in drivers/misc/lkdtm/bugs.c:297:2: error: implicit declaration of function ‘native_write_cr4’; did you mean ‘direct_write_cr4’? [-Werror=implicit-function-declaration] native_write_cr4(cr4); ^~~~~~~~~~~~~~~~ direct_write_cr4 So specify that this block of code should only build when CONFIG_X86_64=y *AND* CONFIG_UML is unset. Signed-off-by: Brendan Higgins <brendanhiggins@google.com> Acked-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20191213003522.66450-1-brendanhiggins@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 2019-09-02T17:30:09+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2019-09-02T17:30:09+00:00 urn:sha1:99097a214b0c15f7595ac8f2788662f3941c1992 We need the fixes in here as well for testing and merges Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2019-08-28T20:33:44+00:00 Raul E Rangel rrangel@chromium.org 2019-08-27T17:36:19+00:00 urn:sha1:b9bc7b8b1e9e815b231c1ca0b566ee723f480987 lkdtm/bugs.c:94:2: error: format '%d' expects argument of type 'int', but argument 2 has type 'long unsigned int' [-Werror=format=] pr_info("Calling function with %d frame size to depth %d ...\n", ^ THREAD_SIZE is defined as a unsigned long, cast CONFIG_FRAME_WARN to unsigned long as well. Fixes: 24cccab42c419 ("lkdtm/bugs: Adjust recursion test to avoid elision") Cc: stable <stable@vger.kernel.org> Signed-off-by: Raul E Rangel <rrangel@chromium.org> Acked-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20190827173619.170065-1-rrangel@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2019-08-19T18:13:21+00:00 Kees Cook keescook@chromium.org 2019-08-19T17:24:52+00:00 urn:sha1:1ee170ea3f0dcf3a4b34f7e7c36559e84bb0d3d6 There are three paths through the kernel code exception logging: - BUG (no configurable printk message) - WARN_ON (no configurable printk message) - WARN (configurable printk message) LKDTM was not testing WARN_ON(). This is needed to evaluate the placement of the "cut here" line, which needs special handling in each of the three exceptions (and between architectures that implement instruction exceptions to implement the code exceptions). Signed-off-by: Kees Cook <keescook@chromium.org> 2019-07-11T22:34:05+00:00 Linus Torvalds torvalds@linux-foundation.org 2019-07-11T22:34:05+00:00 urn:sha1:97ff4ca46d3279134cec49752de8c5a62dc68460 Pull char / misc driver updates from Greg KH: "Here is the "large" pull request for char and misc and other assorted smaller driver subsystems for 5.3-rc1. It seems that this tree is becoming the funnel point of lots of smaller driver subsystems, which is fine for me, but that's why it is getting larger over time and does not just contain stuff under drivers/char/ and drivers/misc. Lots of small updates all over the place here from different driver subsystems: - habana driver updates - coresight driver updates - documentation file movements and updates - Android binder fixes and updates - extcon driver updates - google firmware driver updates - fsi driver updates - smaller misc and char driver updates - soundwire driver updates - nvmem driver updates - w1 driver fixes All of these have been in linux-next for a while with no reported issues" * tag 'char-misc-5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (188 commits) coresight: Do not default to CPU0 for missing CPU phandle dt-bindings: coresight: Change CPU phandle to required property ocxl: Allow contexts to be attached with a NULL mm fsi: sbefifo: Don't fail operations when in SBE IPL state coresight: tmc: Smatch: Fix potential NULL pointer dereference coresight: etm3x: Smatch: Fix potential NULL pointer dereference coresight: Potential uninitialized variable in probe() coresight: etb10: Do not call smp_processor_id from preemptible coresight: tmc-etf: Do not call smp_processor_id from preemptible coresight: tmc-etr: alloc_perf_buf: Do not call smp_processor_id from preemptible coresight: tmc-etr: Do not call smp_processor_id() from preemptible docs: misc-devices: convert files without extension to ReST fpga: dfl: fme: align PR buffer size per PR datawidth fpga: dfl: fme: remove copy_to_user() in ioctl for PR fpga: dfl-fme-mgr: fix FME_PR_INTFC_ID register address. intel_th: msu: Start read iterator from a non-empty window intel_th: msu: Split sgt array and pointer in multiwindow mode intel_th: msu: Support multipage blocks intel_th: pci: Add Ice Lake NNPI support intel_th: msu: Fix single mode with disabled IOMMU ... 2019-07-09T04:48:15+00:00 Linus Torvalds torvalds@linux-foundation.org 2019-07-09T04:48:15+00:00 urn:sha1:5ad18b2e60b75c7297a998dea702451d33a052ed Pull force_sig() argument change from Eric Biederman: "A source of error over the years has been that force_sig has taken a task parameter when it is only safe to use force_sig with the current task. The force_sig function is built for delivering synchronous signals such as SIGSEGV where the userspace application caused a synchronous fault (such as a page fault) and the kernel responded with a signal. Because the name force_sig does not make this clear, and because the force_sig takes a task parameter the function force_sig has been abused for sending other kinds of signals over the years. Slowly those have been fixed when the oopses have been tracked down. This set of changes fixes the remaining abusers of force_sig and carefully rips out the task parameter from force_sig and friends making this kind of error almost impossible in the future" * 'siginfo-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace: (27 commits) signal/x86: Move tsk inside of CONFIG_MEMORY_FAILURE in do_sigbus signal: Remove the signal number and task parameters from force_sig_info signal: Factor force_sig_info_to_task out of force_sig_info signal: Generate the siginfo in force_sig signal: Move the computation of force into send_signal and correct it. signal: Properly set TRACE_SIGNAL_LOSE_INFO in __send_signal signal: Remove the task parameter from force_sig_fault signal: Use force_sig_fault_to_task for the two calls that don't deliver to current signal: Explicitly call force_sig_fault on current signal/unicore32: Remove tsk parameter from __do_user_fault signal/arm: Remove tsk parameter from __do_user_fault signal/arm: Remove tsk parameter from ptrace_break signal/nds32: Remove tsk parameter from send_sigtrap signal/riscv: Remove tsk parameter from do_trap signal/sh: Remove tsk parameter from force_sig_info_fault signal/um: Remove task parameter from send_sigtrap signal/x86: Remove task parameter from send_sigtrap signal: Remove task parameter from force_sig_mceerr signal: Remove task parameter from force_sig signal: Remove task parameter from force_sigsegv ... 2019-06-23T05:05:56+00:00 Kees Cook keescook@chromium.org 2019-06-22T20:18:23+00:00 urn:sha1:06b32fdb030989c45bb9dad685b794bf2395d53a This adds an x86-specific test for pinned cr4 bits. A successful test will validate pinning and check the ROP-style call-middle-of-function defense, if needed. For example, in the case of native_write_cr4() looking like this: ffffffff8171bce0 <native_write_cr4>: ffffffff8171bce0: 48 8b 35 79 46 f2 00 mov 0xf24679(%rip),%rsi ffffffff8171bce7: 48 09 f7 or %rsi,%rdi ffffffff8171bcea: 0f 22 e7 mov %rdi,%cr4 ... ffffffff8171bd5a: c3 retq The UNSET_SMEP test will jump to ffffffff8171bcea (the mov to cr4) instead of ffffffff8171bce0 (native_write_cr4() entry) to simulate a direct-call bypass attempt. Expected successful results: # echo UNSET_SMEP > /sys/kernel/debug/provoke-crash/DIRECT # dmesg [ 79.594433] lkdtm: Performing direct entry UNSET_SMEP [ 79.596459] lkdtm: trying to clear SMEP normally [ 79.598406] lkdtm: ok: SMEP did not get cleared [ 79.599981] lkdtm: trying to clear SMEP with call gadget [ 79.601810] ------------[ cut here ]------------ [ 79.603421] Attempt to unpin cr4 bits: 100000; bypass attack?! ... [ 79.650170] ---[ end trace 2452ca0f6126242e ]--- [ 79.650937] lkdtm: ok: SMEP removal was reverted Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2019-05-27T14:36:28+00:00 Eric W. Biederman ebiederm@xmission.com 2019-05-23T15:17:27+00:00 urn:sha1:3cf5d076fb4d48979f382bc9452765bf8b79e740 All of the remaining callers pass current into force_sig so remove the task parameter to make this obvious and to make misuse more difficult in the future. This also makes it clear force_sig passes current into force_sig_info. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> 2019-04-07T17:38:31+00:00 Kees Cook keescook@chromium.org 2019-04-06T15:59:19+00:00 urn:sha1:24cccab42c4199c6daa0a6981e6f6a1ffb0b5a09 While I was able to trick gcc into keeping a pathological recursion, Clang was not so easily fooled. Instead, switch to using "volatile" and side-effects to keep the stack variable allocated and to run the function. Additionally renames "OVERFLOW" to "EXHAUST_STACK" to better describe the test. Signed-off-by: Kees Cook <keescook@chromium.org> 2018-03-07T03:18:55+00:00 Kees Cook keescook@chromium.org 2018-03-06T22:58:09+00:00 urn:sha1:039a1c42058db54692a6d4497508bd48555f29fb The LKDTM modules keep expanding, and it's getting weird to have each file get a prefix. Instead, move to a subdirectory for cleaner handling. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>