This repository has been archived by the owner on Sep 24, 2020. It is now read-only.
Rebase patches onto 4.13.15 #110
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
UEFI machines can be booted in Secure Boot mode. Add a EFI_SECURE_BOOT bit that can be passed to efi_enabled() to find out whether secure boot is enabled. This will be used by the SysRq+x handler, registered by the x86 arch, to find out whether secure boot mode is enabled so that it can be disabled. Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: David Howells <dhowells@redhat.com>
Provide a single call to allow kernel code to determine whether the system should be locked down, thereby disallowing various accesses that might allow the running kernel image to be changed including the loading of modules that aren't validly signed with a key we recognise, fiddling with MSR registers and disallowing hibernation, Signed-off-by: David Howells <dhowells@redhat.com>
UEFI Secure Boot provides a mechanism for ensuring that the firmware will only load signed bootloaders and kernels. Certain use cases may also require that all kernel modules also be signed. Add a configuration option that to lock down the kernel - which includes requiring validly signed modules - if the kernel is secure-booted. Signed-off-by: David Howells <dhowells@redhat.com>
If the kernel is locked down, require that all modules have valid signatures that we can verify. Signed-off-by: David Howells <dhowells@redhat.com>
Allowing users to write to address space makes it possible for the kernel to be subverted, avoiding module loading restrictions. Prevent this when the kernel has been locked down. Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: David Howells <dhowells@redhat.com>
kexec 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 in this situation. This does not affect kexec_file_load() which can check for a signature on the image to be booted. Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: David Howells <dhowells@redhat.com>
Kexec reboot in case secure boot being enabled does not keep the secure boot mode in new kernel, so later one can load unsigned kernel via legacy kexec_load. In this state, the system is missing the protections provided by secure boot. Adding a patch to fix this by retain the secure_boot flag in original kernel. secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the stub. Fixing this issue by copying secure_boot flag across kexec reboot. Signed-off-by: Dave Young <dyoung@redhat.com> Signed-off-by: David Howells <dhowells@redhat.com>
When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image through kexec_file systemcall if securelevel has been set. This code was showed in Matthew's patch but not in git: https://lkml.org/lkml/2015/3/13/778 Cc: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: Lee, Chun-Yi <jlee@suse.com> Signed-off-by: David Howells <dhowells@redhat.com>
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 <jwboyer@fedoraproject.org> Signed-off-by: David Howells <dhowells@redhat.com>
uswsusp allows a user process to dump and then restore kernel state, which makes it possible to modify the running kernel. Disable this if the kernel is locked down. Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: David Howells <dhowells@redhat.com>
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: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: David Howells <dhowells@redhat.com>
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 <matthew.garrett@nebula.com> Signed-off-by: David Howells <dhowells@redhat.com>
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. Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: David Howells <dhowells@redhat.com>
We have no way of validating what all of the Asus WMI methods do on a given machine - and there's a risk that some will allow hardware state to be manipulated in such a way that arbitrary code can be executed in the kernel, circumventing module loading restrictions. Prevent that if the kernel is locked down. Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: David Howells <dhowells@redhat.com>
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 <matthew.garrett@nebula.com> Signed-off-by: David Howells <dhowells@redhat.com>
This option allows userspace to pass the RSDP address to the kernel, which makes it possible for a user to circumvent any restrictions imposed on loading modules. Ignore the option when the kernel is locked down. Signed-off-by: Josh Boyer <jwboyer@redhat.com> Signed-off-by: David Howells <dhowells@redhat.com>
From the kernel documentation (initrd_table_override.txt): If the ACPI_INITRD_TABLE_OVERRIDE compile option is true, it is possible to override nearly any ACPI table provided by the BIOS with an instrumented, modified one. When securelevel is set, the kernel should disallow any unauthenticated changes to kernel space. ACPI tables contain code invoked by the kernel, so do not allow ACPI tables to be overridden if the kernel is locked down. Signed-off-by: Linn Crosetto <linn@hpe.com> Signed-off-by: David Howells <dhowells@redhat.com>
ACPI provides an error injection mechanism, EINJ, for debugging and testing the ACPI Platform Error Interface (APEI) and other RAS features. If supported by the firmware, ACPI specification 5.0 and later provide for a way to specify a physical memory address to which to inject the error. Injecting errors through EINJ can produce errors which to the platform are indistinguishable from real hardware errors. This can have undesirable side-effects, such as causing the platform to mark hardware as needing replacement. While it does not provide a method to load unauthenticated privileged code, the effect of these errors may persist across reboots and affect trust in the underlying hardware, so disable error injection through EINJ if the kernel is locked down. Signed-off-by: Linn Crosetto <linn@hpe.com> Signed-off-by: David Howells <dhowells@redhat.com>
… down There are some bpf functions can be used to read kernel memory: bpf_probe_read, bpf_probe_write_user and bpf_trace_printk. These allow private keys in kernel memory (e.g. the hibernation image signing key) to be read by an eBPF program. Prohibit those functions when the kernel is locked down. Signed-off-by: Lee, Chun-Yi <jlee@suse.com> Signed-off-by: David Howells <dhowells@redhat.com>
When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. The eata driver takes a single string parameter that contains a slew of settings, including hardware resource configuration. Prohibit use of the parameter if the kernel is locked down. Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> Signed-off-by: David Howells <dhowells@redhat.com> cc: Dario Ballabio <ballabio_dario@emc.com> cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com> cc: "Martin K. Petersen" <martin.petersen@oracle.com> cc: linux-scsi@vger.kernel.org
Prohibit replacement of the PCMCIA Card Information Structure when the kernel is locked down. Signed-off-by: David Howells <dhowells@redhat.com>
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 <gregkh@linuxfoundation.org> Signed-off-by: David Howells <dhowells@redhat.com>
This enables relocating source and build trees to different roots, provided they stay reachable relative to one another. Useful for builds done within a sandbox where the eventual root is prefixed by some undesirable path component.
Signed-off-by: Geoff Levand <geoff@infradead.org>
dm0-
approved these changes
Nov 22, 2017
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
From: https://jenkins-os.prod.coreos.systems/job/os/job/update-linux/34/