aboutsummaryrefslogtreecommitdiff
path: root/include/linux
AgeCommit message (Collapse)AuthorFilesLines
2019-08-21PM / wakeup: Drop wakeup_source_init(), wakeup_source_prepare()Tri Vo1-11/+0
wakeup_source_init() has no users. Remove it. As a result, wakeup_source_prepare() is only called from wakeup_source_create(). Merge wakeup_source_prepare() into wakeup_source_create() and remove it. Change wakeup_source_create() behavior so that assigning NULL to wakeup source's name throws an error. Signed-off-by: Tri Vo <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-08-21dma-direct: fix zone selection after an unaddressable CMA allocationChristoph Hellwig1-4/+1
The new dma_alloc_contiguous hides if we allocate CMA or regular pages, and thus fails to retry a ZONE_NORMAL allocation if the CMA allocation succeeds but isn't addressable. That means we either fail outright or dip into a small zone that might not succeed either. Thanks to Hillf Danton for debugging this issue. Fixes: b1d2dc009dec ("dma-contiguous: add dma_{alloc,free}_contiguous() helpers") Reported-by: Tobias Klausmann <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Tested-by: Tobias Klausmann <[email protected]>
2019-08-20net/mlx5: Add lag_tx_port_affinity capability bitMaxim Mikityanskiy1-1/+3
Add the lag_tx_port_affinity HCA capability bit that indicates that setting port affinity of TISes is supported. Signed-off-by: Maxim Mikityanskiy <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-08-20net/mlx5: Expose IP-in-IP capability bitAya Levin1-1/+3
Expose Fw indication that it supports Stateless Offloads for IP over IP tunneled packets. The following offloads are supported for the inner packets: RSS, RX & TX Checksum Offloads, LSO and Flow Steering. Signed-off-by: Aya Levin <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-08-20net/mlx5: Add support for VNIC_ENV internal rq counterMoshe Shemesh1-2/+8
Add mlx5 interface support for reading internal rq out of buffer counter as part of QUERY_VNIC_ENV command. The command is used by the driver to query vnic diagnostic statistics from FW. Signed-off-by: Moshe Shemesh <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-08-20alarmtimers: Avoid rtc.h includeThomas Gleixner1-1/+2
rtc.h is not needed in alarmtimers when a forward declaration of struct rtc_device is provided. That allows to include posix-timers.h without adding more includes to alarmtimer.h or creating circular include dependencies. Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Frederic Weisbecker <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2019-08-20posix-timers: Cleanup forward declarations and includesThomas Gleixner1-3/+2
- Rename struct siginfo to kernel_siginfo as that is used and required - Add a forward declaration for task_struct and remove sched.h include - Remove timex.h include as it is not needed Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Frederic Weisbecker <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2019-08-20Input: add support for polling to input devicesDmitry Torokhov1-0/+12
Separating "normal" and "polled" input devices was a mistake, as often we want to allow the very same device work on both interrupt-driven and polled mode, depending on the board on which the device is used. This introduces new APIs: - input_setup_polling - input_set_poll_interval - input_set_min_poll_interval - input_set_max_poll_interval These new APIs allow switching an input device into polled mode with sysfs attributes matching drivers using input_polled_dev APIs that will be eventually removed. Tested-by: Michal Vokáč <[email protected]> Acked-by: Benjamin Tissoires <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
2019-08-20bpf: add new BPF_BTF_GET_NEXT_ID syscall commandQuentin Monnet1-0/+3
Add a new command for the bpf() system call: BPF_BTF_GET_NEXT_ID is used to cycle through all BTF objects loaded on the system. The motivation is to be able to inspect (list) all BTF objects presents on the system. Signed-off-by: Quentin Monnet <[email protected]> Reviewed-by: Jakub Kicinski <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]>
2019-08-20xprtrdma: Boost client's max slot table size to match Linux serverChuck Lever1-2/+2
I've heard rumors of an NFS/RDMA server implementation that has a default credit limit of 1024. The client's default setting remains at 128. Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Anna Schumaker <[email protected]>
2019-08-20bpf: add include guard to tnum.hMasahiro Yamada1-0/+6
Add a header include guard just in case. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]>
2019-08-20vfs: don't allow writes to swap filesDarrick J. Wong1-0/+11
Don't let userspace write to an active swap file because the kernel effectively has a long term lease on the storage and things could get seriously corrupted if we let this happen. Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
2019-08-20SUNRPC: Remove rpc_wake_up_queued_task_on_wq()Chuck Lever1-3/+0
Clean up: commit c544577daddb ("SUNRPC: Clean up transport write space handling") appears to have removed the last caller of rpc_wake_up_queued_task_on_wq(). Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Anna Schumaker <[email protected]>
2019-08-20memremap: provide a not device managed memremap_pagesChristoph Hellwig1-0/+2
The kvmppc ultravisor code wants a device private memory pool that is system wide and not attached to a device. Instead of faking up one provide a low-level memremap_pages for it. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Ira Weiny <[email protected]> Reviewed-by: Dan Williams <[email protected]> Tested-by: Bharata B Rao <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2019-08-20memremap: remove the dev field in struct dev_pagemapChristoph Hellwig1-1/+0
The dev field in struct dev_pagemap is only used to print dev_name in two places, which are at best nice to have. Just remove the field and thus the name in those two messages. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Ira Weiny <[email protected]> Reviewed-by: Dan Williams <[email protected]> Tested-by: Bharata B Rao <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2019-08-20resource: add a not device managed request_free_mem_region variantChristoph Hellwig1-0/+2
Factor out the guts of devm_request_free_mem_region so that we can implement both a device managed and a manually release version as tiny wrappers around it. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Ira Weiny <[email protected]> Reviewed-by: Dan Williams <[email protected]> Tested-by: Bharata B Rao <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2019-08-20mm: remove the unused MIGRATE_PFN_DEVICE flagChristoph Hellwig1-1/+0
No one ever checks this flag, and we could easily get that information from the page if needed. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Ralph Campbell <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Tested-by: Ralph Campbell <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2019-08-20mm: remove the unused MIGRATE_PFN_ERROR flagChristoph Hellwig1-1/+0
Now that we can rely errors in the normal control flow there is no need for this flag, remove it. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Ralph Campbell <[email protected]> Tested-by: Ralph Campbell <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2019-08-20mm: turn migrate_vma upside downChristoph Hellwig1-99/+19
There isn't any good reason to pass callbacks to migrate_vma. Instead we can just export the three steps done by this function to drivers and let them sequence the operation without callbacks. This removes a lot of boilerplate code as-is, and will allow the drivers to drastically improve code flow and error handling further on. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Ralph Campbell <[email protected]> Tested-by: Ralph Campbell <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2019-08-20hmm: use mmu_notifier_get/put for 'struct hmm'Jason Gunthorpe2-17/+1
This is a significant simplification, it eliminates all the remaining 'hmm' stuff in mm_struct, eliminates krefing along the critical notifier paths, and takes away all the ugly locking and abuse of page_table_lock. mmu_notifier_get() provides the single struct hmm per struct mm which eliminates mm->hmm. It also directly guarantees that no mmu_notifier op callback is callable while concurrent free is possible, this eliminates all the krefs inside the mmu_notifier callbacks. The remaining krefs in the range code were overly cautious, drivers are already not permitted to free the mirror while a range exists. Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Ralph Campbell <[email protected]> Tested-by: Ralph Campbell <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2019-08-20can: rcar_can: Remove unused platform data supportGeert Uytterhoeven1-18/+0
All R-Car platforms use DT for describing CAN controllers. R-Car CAN platform data support was never used in any upstream kernel. Move the Clock Select Register settings enum into the driver, and remove platform data support and the corresponding header file. Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Wolfram Sang <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2019-08-20irqchip: Add include guard to irq-partition-percpu.hMasahiro Yamada1-0/+5
Add a header include guard just in case. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2019-08-20irqchip/gic-v3: Warn about inconsistent implementations of extended rangesMarc Zyngier1-0/+1
As is it usual for the GIC, it isn't disallowed to put together a system that is majorly inconsistent, with a distributor supporting the extended ranges while some of the CPUs don't. Kindly tell the user that things are sailing isn't going to be smooth. Signed-off-by: Marc Zyngier <[email protected]>
2019-08-20irqchip/gic-v3: Add EPPI range supportMarc Zyngier1-0/+12
Expand the pre-existing PPI support to be able to deal with the Extended PPI range (EPPI). This includes obtaining the number of PPIs from each individual redistributor, and compute the minimum set (just in case someone builds something really clever...). Signed-off-by: Marc Zyngier <[email protected]>
2019-08-20irqchip/gic-v3: Add ESPI range supportMarc Zyngier1-1/+16
Add the required support for the ESPI range, which behave exactly like the SPIs of old, only with new funky INTIDs. Signed-off-by: Marc Zyngier <[email protected]>
2019-08-20Merge branch 'for-joerg/batched-unmap' of ↵Joerg Roedel2-37/+112
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into core
2019-08-20gpio: Use callback presence to determine need of valid_maskLinus Walleij1-9/+0
After we switched the two drivers that have .need_valid_mask set to use the callback for setting up the .valid_mask, we can just use the presence of the .init_valid_mask() callback (or the OF reserved ranges, nota bene) to determine whether to allocate the mask or not and we can drop the .need_valid_mask field altogether. Cc: Benjamin Gaignard <[email protected]> Cc: Amelie Delaunay <[email protected]> Cc: Stephen Boyd <[email protected]> Cc: Bjorn Andersson <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2019-08-20gpio: Pass mask and size with the init_valid_mask()Linus Walleij1-1/+3
It is more helpful for drivers to have the affected fields directly available when we use the callback to set up the valid mask. Change this and switch over the only user (MSM) to use the passed parameters. If we do this we can also move the mask out of publicly visible struct fields. Cc: Stephen Boyd <[email protected]> Cc: Bjorn Andersson <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Stephen Boyd <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2019-08-20gpio: stubs in headers should be inlineStephen Rothwell1-2/+2
Fixes: fdd61a013a24 ("gpio: Add support for hierarchical IRQ domains") Signed-off-by: Stephen Rothwell <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2019-08-19tracefs: Restrict tracefs when the kernel is locked downMatthew Garrett1-0/+1
Tracefs may release more information about the kernel than desirable, so restrict it when the kernel is locked down in confidentiality mode by preventing open(). (Fixed by Ben Hutchings to avoid a null dereference in default_file_open()) Signed-off-by: Matthew Garrett <[email protected]> Reviewed-by: Steven Rostedt (VMware) <[email protected]> Cc: Ben Hutchings <[email protected]> Signed-off-by: James Morris <[email protected]>
2019-08-19debugfs: Restrict debugfs when the kernel is locked downDavid Howells1-0/+1
Disallow opening of debugfs files that might be used to muck around when the kernel is locked down as various drivers give raw access to hardware through debugfs. Given the effort of auditing all 2000 or so files and manually fixing each one as necessary, I've chosen to apply a heuristic instead. The following changes are made: (1) chmod and chown are disallowed on debugfs objects (though the root dir can be modified by mount and remount, but I'm not worried about that). (2) When the kernel is locked down, only files with the following criteria are permitted to be opened: - The file must have mode 00444 - The file must not have ioctl methods - The file must not have mmap (3) When the kernel is locked down, files may only be opened for reading. Normal device interaction should be done through configfs, sysfs or a miscdev, not debugfs. Note that this makes it unnecessary to specifically lock down show_dsts(), show_devs() and show_call() in the asus-wmi driver. I would actually prefer to lock down all files by default and have the the files unlocked by the creator. This is tricky to manage correctly, though, as there are 19 creation functions and ~1600 call sites (some of them in loops scanning tables). Signed-off-by: David Howells <[email protected]> cc: Andy Shevchenko <[email protected]> cc: [email protected] cc: [email protected] cc: Matthew Garrett <[email protected]> cc: Thomas Gleixner <[email protected]> Cc: Greg KH <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Signed-off-by: Matthew Garrett <[email protected]> Signed-off-by: James Morris <[email protected]>
2019-08-19kexec: Allow kexec_file() with appropriate IMA policy when locked downMatthew Garrett1-0/+9
Systems in lockdown mode should block the kexec of untrusted kernels. For x86 and ARM we can ensure that a kernel is trustworthy by validating a PE signature, but this isn't possible on other architectures. On those platforms we can use IMA digital signatures instead. Add a function to determine whether IMA has or will verify signatures for a given event type, and if so permit kexec_file() even if the kernel is otherwise locked down. This is restricted to cases where CONFIG_INTEGRITY_TRUSTED_KEYRING is set in order to prevent an attacker from loading additional keys at runtime. Signed-off-by: Matthew Garrett <[email protected]> Acked-by: Mimi Zohar <[email protected]> Cc: Dmitry Kasatkin <[email protected]> Cc: [email protected] Signed-off-by: James Morris <[email protected]>
2019-08-19lockdown: Lock down perf when in confidentiality modeDavid Howells1-0/+1
Disallow the use of certain perf facilities that might allow userspace to access kernel data. Signed-off-by: David Howells <[email protected]> Signed-off-by: Matthew Garrett <[email protected]> Reviewed-by: Kees Cook <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: James Morris <[email protected]>
2019-08-19bpf: Restrict bpf when kernel lockdown is in confidentiality modeDavid Howells1-0/+1
bpf_read() and bpf_read_str() could potentially be abused to (eg) allow private keys in kernel memory to be leaked. Disable them if the kernel has been locked down in confidentiality mode. Suggested-by: Alexei Starovoitov <[email protected]> Signed-off-by: Matthew Garrett <[email protected]> Reviewed-by: Kees Cook <[email protected]> cc: [email protected] cc: Chun-Yi Lee <[email protected]> cc: Alexei Starovoitov <[email protected]> Cc: Daniel Borkmann <[email protected]> Signed-off-by: James Morris <[email protected]>
2019-08-19lockdown: Lock down tracing and perf kprobes when in confidentiality modeDavid Howells1-0/+1
Disallow the creation of perf and ftrace kprobes when the kernel is locked down in confidentiality mode by preventing their registration. This prevents kprobes from being used to access kernel memory to steal crypto data, but continues to allow the use of kprobes from signed modules. Reported-by: Alexei Starovoitov <[email protected]> Signed-off-by: David Howells <[email protected]> Signed-off-by: Matthew Garrett <[email protected]> Acked-by: Masami Hiramatsu <[email protected]> Reviewed-by: Kees Cook <[email protected]> Cc: Naveen N. Rao <[email protected]> Cc: Anil S Keshavamurthy <[email protected]> Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Signed-off-by: James Morris <[email protected]>
2019-08-19lockdown: Lock down /proc/kcoreDavid Howells1-0/+1
Disallow access to /proc/kcore when the kernel is locked down to prevent access to cryptographic data. This is limited to lockdown confidentiality mode and is still permitted in integrity mode. Signed-off-by: David Howells <[email protected]> Signed-off-by: Matthew Garrett <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: James Morris <[email protected]>
2019-08-19x86/mmiotrace: Lock down the testmmiotrace moduleDavid Howells1-0/+1
The testmmiotrace module shouldn't be permitted when the kernel is locked down as it can be used to arbitrarily read and write MMIO space. This is a runtime check rather than buildtime in order to allow configurations where the same kernel may be run in both locked down or permissive modes depending on local policy. Suggested-by: Thomas Gleixner <[email protected]> Signed-off-by: David Howells <[email protected] Signed-off-by: Matthew Garrett <[email protected]> Acked-by: Steven Rostedt (VMware) <[email protected]> Reviewed-by: Kees Cook <[email protected]> cc: Thomas Gleixner <[email protected]> cc: Steven Rostedt <[email protected]> cc: Ingo Molnar <[email protected]> cc: "H. Peter Anvin" <[email protected]> cc: [email protected] Signed-off-by: James Morris <[email protected]>
2019-08-19lockdown: Lock down module params that specify hardware parameters (eg. ioport)David Howells1-0/+1
Provided an annotation for module parameters that specify hardware parameters (such as io ports, iomem addresses, irqs, dma channels, fixed dma buffers and other types). Suggested-by: Alan Cox <[email protected]> Signed-off-by: David Howells <[email protected]> Signed-off-by: Matthew Garrett <[email protected]> Reviewed-by: Kees Cook <[email protected]> Cc: Jessica Yu <[email protected]> Signed-off-by: James Morris <[email protected]>
2019-08-19lockdown: Lock down TIOCSSERIALDavid Howells1-0/+1
Lock down TIOCSSERIAL as that can be used to change the ioport and irq settings on a serial port. This only appears to be an issue for the serial drivers that use the core serial code. All other drivers seem to either ignore attempts to change port/irq or give an error. Reported-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: David Howells <[email protected]> Signed-off-by: Matthew Garrett <[email protected]> Reviewed-by: Kees Cook <[email protected]> cc: Jiri Slaby <[email protected]> Cc: [email protected] Signed-off-by: James Morris <[email protected]>
2019-08-19lockdown: Prohibit PCMCIA CIS storage when the kernel is locked downDavid Howells1-0/+1
Prohibit replacement of the PCMCIA Card Information Structure when the kernel is locked down. Suggested-by: Dominik Brodowski <[email protected]> Signed-off-by: David Howells <[email protected]> Signed-off-by: Matthew Garrett <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: James Morris <[email protected]>
2019-08-19acpi: Ignore acpi_rsdp kernel param when the kernel has been locked downJosh Boyer1-0/+6
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 <[email protected]> Signed-off-by: David Howells <[email protected]> Signed-off-by: Matthew Garrett <[email protected]> Reviewed-by: Kees Cook <[email protected]> cc: Dave Young <[email protected]> cc: [email protected] Signed-off-by: James Morris <[email protected]>
2019-08-19ACPI: Limit access to custom_method when the kernel is locked downMatthew Garrett1-0/+1
custom_method effectively allows arbitrary access to system memory, making it possible for an attacker to circumvent restrictions on module loading. Disable it if the kernel is locked down. Signed-off-by: Matthew Garrett <[email protected]> Signed-off-by: David Howells <[email protected]> Reviewed-by: Kees Cook <[email protected]> cc: [email protected] Signed-off-by: James Morris <[email protected]>
2019-08-19x86/msr: Restrict MSR access when the kernel is locked downMatthew Garrett1-0/+1
Writing to MSRs should not be allowed if the kernel is locked down, since it could lead to execution of arbitrary code in kernel mode. Based on a patch by Kees Cook. Signed-off-by: Matthew Garrett <[email protected]> Signed-off-by: David Howells <[email protected]> Acked-by: Kees Cook <[email protected]> Reviewed-by: Thomas Gleixner <[email protected]> cc: [email protected] Signed-off-by: James Morris <[email protected]>
2019-08-19x86: Lock down IO port access when the kernel is locked downMatthew Garrett1-0/+1
IO port access would permit users to gain access to PCI configuration registers, which in turn (on a lot of hardware) give access to MMIO register space. This would potentially permit root to trigger arbitrary DMA, so lock it down by default. This also implicitly locks down the KDADDIO, KDDELIO, KDENABIO and KDDISABIO console ioctls. Signed-off-by: Matthew Garrett <[email protected]> Signed-off-by: David Howells <[email protected]> Reviewed-by: Kees Cook <[email protected]> cc: [email protected] Signed-off-by: James Morris <[email protected]>
2019-08-19PCI: Lock down BAR access when the kernel is locked downMatthew Garrett1-0/+1
Any hardware that can potentially generate DMA has to be locked down in order to avoid it being possible for an attacker to modify kernel code, allowing them to circumvent disabled module loading or module signing. Default to paranoid - in future we can potentially relax this for sufficiently IOMMU-isolated devices. Signed-off-by: David Howells <[email protected]> Signed-off-by: Matthew Garrett <[email protected]> Acked-by: Bjorn Helgaas <[email protected]> Reviewed-by: Kees Cook <[email protected]> cc: [email protected] Signed-off-by: James Morris <[email protected]>
2019-08-19hibernate: Disable when the kernel is locked downJosh Boyer1-0/+1
There is currently no way to verify the resume image when returning from hibernate. This might compromise the signed modules trust model, so until we can work with signed hibernate images we disable it when the kernel is locked down. Signed-off-by: Josh Boyer <[email protected]> Signed-off-by: David Howells <[email protected]> Signed-off-by: Matthew Garrett <[email protected]> Reviewed-by: Kees Cook <[email protected]> Cc: [email protected] Cc: [email protected] cc: [email protected] Signed-off-by: James Morris <[email protected]>
2019-08-19kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCEJiri Bohac1-2/+2
This is a preparatory patch for kexec_file_load() lockdown. A locked down kernel needs to prevent unsigned kernel images from being loaded with kexec_file_load(). Currently, the only way to force the signature verification is compiling with KEXEC_VERIFY_SIG. This prevents loading usigned images even when the kernel is not locked down at runtime. This patch splits KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE. Analogous to the MODULE_SIG and MODULE_SIG_FORCE for modules, KEXEC_SIG turns on the signature verification but allows unsigned images to be loaded. KEXEC_SIG_FORCE disallows images without a valid signature. Signed-off-by: Jiri Bohac <[email protected]> Signed-off-by: David Howells <[email protected]> Signed-off-by: Matthew Garrett <[email protected]> cc: [email protected] Signed-off-by: James Morris <[email protected]>
2019-08-19kexec_load: Disable at runtime if the kernel is locked downMatthew Garrett1-0/+1
The kexec_load() syscall permits the loading and execution of arbitrary code in ring 0, which is something that lock-down is meant to prevent. It makes sense to disable kexec_load() in this situation. This does not affect kexec_file_load() syscall which can check for a signature on the image to be booted. Signed-off-by: David Howells <[email protected]> Signed-off-by: Matthew Garrett <[email protected]> Acked-by: Dave Young <[email protected]> Reviewed-by: Kees Cook <[email protected]> cc: [email protected] Signed-off-by: James Morris <[email protected]>
2019-08-19lockdown: Restrict /dev/{mem,kmem,port} when the kernel is locked downMatthew Garrett1-0/+1
Allowing users to read and write to core kernel memory makes it possible for the kernel to be subverted, avoiding module loading restrictions, and also to steal cryptographic information. Disallow /dev/mem and /dev/kmem from being opened this when the kernel has been locked down to prevent this. Also disallow /dev/port from being opened to prevent raw ioport access and thus DMA from being used to accomplish the same thing. Signed-off-by: David Howells <[email protected]> Signed-off-by: Matthew Garrett <[email protected]> Reviewed-by: Kees Cook <[email protected]> Cc: [email protected] Signed-off-by: James Morris <[email protected]>
2019-08-19lockdown: Enforce module signatures if the kernel is locked downDavid Howells1-0/+1
If the kernel is locked down, require that all modules have valid signatures that we can verify. I have adjusted the errors generated: (1) If there's no signature (ENODATA) or we can't check it (ENOPKG, ENOKEY), then: (a) If signatures are enforced then EKEYREJECTED is returned. (b) If there's no signature or we can't check it, but the kernel is locked down then EPERM is returned (this is then consistent with other lockdown cases). (2) If the signature is unparseable (EBADMSG, EINVAL), the signature fails the check (EKEYREJECTED) or a system error occurs (eg. ENOMEM), we return the error we got. Note that the X.509 code doesn't check for key expiry as the RTC might not be valid or might not have been transferred to the kernel's clock yet. [Modified by Matthew Garrett to remove the IMA integration. This will be replaced with integration with the IMA architecture policy patchset.] Signed-off-by: David Howells <[email protected]> Signed-off-by: Matthew Garrett <[email protected]> Reviewed-by: Kees Cook <[email protected]> Cc: Jessica Yu <[email protected]> Signed-off-by: James Morris <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.