talos-op-linux/arch/x86/kernel/acpi, branch master

x86/ACPI/sleep: Move acpi_get_wakeup_address() into sleep.c, remove from

2019-12-10T09:15:48+00:00

Move the definition of acpi_get_wakeup_address() into sleep.c to break linux/acpi.h's dependency (by way of asm/acpi.h) on asm/realmode.h. Everyone and their mother includes linux/acpi.h, i.e. modifying realmode.h results in a full kernel rebuild, which makes the already inscrutable real mode boot code even more difficult to understand and is positively rage inducing when trying to make changes to x86's boot flow. No functional change intended. Signed-off-by: Sean Christopherson Link: https://lkml.kernel.org/r/20191126165417.22423-13-sean.j.christopherson@intel.com Signed-off-by: Ingo Molnar

x86/ACPI/sleep: Remove an unnecessary include of asm/realmode.h

2019-12-10T09:15:48+00:00

None of the declarations in x86's acpi/sleep.h are in any way dependent on the real mode boot code. Remove sleep.h's include of asm/realmode.h to limit the dependencies on realmode.h to code that actually interacts with the boot code. Signed-off-by: Sean Christopherson Acked-by: Rafael J. Wysocki Link: https://lkml.kernel.org/r/20191126165417.22423-11-sean.j.christopherson@intel.com Signed-off-by: Ingo Molnar

x86/asm/32: Add ENDs to some functions and relabel with SYM_CODE_*

2019-10-18T09:58:33+00:00

All these are functions which are invoked from elsewhere but they are not typical C functions. So annotate them using the new SYM_CODE_START. All these were not balanced with any END, so mark their ends by SYM_CODE_END, appropriately. Signed-off-by: Jiri Slaby Signed-off-by: Borislav Petkov Reviewed-by: Boris Ostrovsky [xen bits] Reviewed-by: Rafael J. Wysocki [hibernate] Cc: Andy Lutomirski Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Josh Poimboeuf Cc: Juergen Gross Cc: Len Brown Cc: linux-arch@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: Pavel Machek Cc: Peter Zijlstra Cc: Pingfan Liu Cc: Stefano Stabellini Cc: "Steven Rostedt (VMware)" Cc: Thomas Gleixner Cc: x86-ml Cc: xen-devel@lists.xenproject.org Link: https://lkml.kernel.org/r/20191011115108.12392-26-jslaby@suse.cz

x86/asm: Change all ENTRY+ENDPROC to SYM_FUNC_*

2019-10-18T09:58:33+00:00

These are all functions which are invoked from elsewhere, so annotate them as global using the new SYM_FUNC_START and their ENDPROC's by SYM_FUNC_END. Make sure ENTRY/ENDPROC is not defined on X86_64, given these were the last users. Signed-off-by: Jiri Slaby Signed-off-by: Borislav Petkov Reviewed-by: Rafael J. Wysocki [hibernate] Reviewed-by: Boris Ostrovsky [xen bits] Acked-by: Herbert Xu [crypto] Cc: Allison Randal Cc: Andrey Ryabinin Cc: Andy Lutomirski Cc: Andy Shevchenko Cc: Ard Biesheuvel Cc: Armijn Hemel Cc: Cao jin Cc: Darren Hart Cc: Dave Hansen Cc: "David S. Miller" Cc: Enrico Weigelt Cc: Greg Kroah-Hartman Cc: Herbert Xu Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jim Mattson Cc: Joerg Roedel Cc: Josh Poimboeuf Cc: Juergen Gross Cc: Kate Stewart Cc: "Kirill A. Shutemov" Cc: kvm ML Cc: Len Brown Cc: linux-arch@vger.kernel.org Cc: linux-crypto@vger.kernel.org Cc: linux-efi Cc: linux-efi@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: Mark Rutland Cc: Matt Fleming Cc: Paolo Bonzini Cc: Pavel Machek Cc: Peter Zijlstra Cc: platform-driver-x86@vger.kernel.org Cc: "Radim Krčmář" Cc: Sean Christopherson Cc: Stefano Stabellini Cc: "Steven Rostedt (VMware)" Cc: Thomas Gleixner Cc: Vitaly Kuznetsov Cc: Wanpeng Li Cc: Wei Huang Cc: x86-ml Cc: xen-devel@lists.xenproject.org Cc: Xiaoyao Li Link: https://lkml.kernel.org/r/20191011115108.12392-25-jslaby@suse.cz

x86/asm/suspend: Use SYM_DATA for data

2019-10-18T07:50:25+00:00

Some global data in the suspend code were marked as `ENTRY'. ENTRY was intended for functions and shall be paired with ENDPROC. ENTRY also aligns symbols to 16 bytes which creates unnecessary holes. Note that: * saved_magic (long) in wakeup_32 is still prepended by section's ALIGN * saved_magic (quad) in wakeup_64 follows a bunch of quads which are aligned (but need not be aligned to 16) Since historical markings are being dropped, make proper use of newly added SYM_DATA in this code. Signed-off-by: Jiri Slaby Signed-off-by: Borislav Petkov Acked-by: Rafael J. Wysocki Acked-by: Pavel Machek Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Len Brown Cc: linux-arch@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: Thomas Gleixner Cc: x86-ml Link: https://lkml.kernel.org/r/20191011115108.12392-3-jslaby@suse.cz

Merge branch 'next-lockdown' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security

2019-09-28T15:14:15+00:00

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 ...

x86/asm/suspend: Get rid of bogus_64_magic

2019-09-06T08:34:15+00:00

bogus_64_magic is only a dead-end loop. There is no need for an out-of-order function (and unannotated local label), so just handle it in-place and also store 0xbad-m-a-g-i-c to %rcx beforehand, in case someone is inspecting registers. Here a qemu+gdb example: Remote debugging using localhost:1235 wakeup_long64 () at arch/x86/kernel/acpi/wakeup_64.S:26 26 jmp 1b (gdb) info registers rax 0x123456789abcdef0 1311768467463790320 rbx 0x0 0 rcx 0xbad6d61676963 3286910041024867 ^^^^^^^^^^^^^^^ [ bp: Add the gdb example. ] Signed-off-by: Jiri Slaby Signed-off-by: Borislav Petkov Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Len Brown Cc: linux-pm@vger.kernel.org Cc: Pavel Machek Cc: "Rafael J. Wysocki" Cc: Thomas Gleixner Cc: x86-ml Link: https://lkml.kernel.org/r/20190906075550.23435-1-jslaby@suse.cz

acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down

2019-08-20T04:54:16+00:00

This option allows userspace to pass the RSDP address to the kernel, which makes it possible for a user to modify the workings of hardware. Reject the option when the kernel is locked down. This requires some reworking of the existing RSDP command line logic, since the early boot code also makes use of a command-line passed RSDP when locating the SRAT table before the lockdown code has been initialised. This is achieved by separating the command line RSDP path in the early boot code from the generic RSDP path, and then copying the command line RSDP into boot params in the kernel proper if lockdown is not enabled. If lockdown is enabled and an RSDP is provided on the command line, this will only be used when parsing SRAT (which shouldn't permit kernel code execution) and will be ignored in the rest of the kernel. (Modified by Matthew Garrett in order to handle the early boot RSDP environment) Signed-off-by: Josh Boyer Signed-off-by: David Howells Signed-off-by: Matthew Garrett Reviewed-by: Kees Cook cc: Dave Young cc: linux-acpi@vger.kernel.org Signed-off-by: James Morris

x86/acpi/cstate: Add Zhaoxin processors support for cache flush policy in C3

2019-06-22T09:45:58+00:00

Same as Intel, Zhaoxin MP CPUs support C3 share cache and on all recent Zhaoxin platforms ARB_DISABLE is a nop. So set related flags correctly in the same way as Intel does. Signed-off-by: Tony W Wang-oc Signed-off-by: Thomas Gleixner Cc: "hpa@zytor.com" Cc: "gregkh@linuxfoundation.org" Cc: "rjw@rjwysocki.net" Cc: "lenb@kernel.org" Cc: David Wang Cc: "Cooper Yan(BJ-RD)" Cc: "Qiyuan Wang(BJ-RD)" Cc: "Herry Yang(BJ-RD)" Link: https://lkml.kernel.org/r/a370503660994669991a7f7cda7c5e98@zhaoxin.com

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 430

2019-06-05T15:37:16+00:00

Based on 1 normalized pattern(s): distribute under gplv2 extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 8 file(s). Signed-off-by: Thomas Gleixner Reviewed-by: Armijn Hemel Reviewed-by: Allison Randal Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190531190114.475576622@linutronix.de Signed-off-by: Greg Kroah-Hartman