tracefs: Fix potential null dereference in default_file_open()

The "open" operation in struct file_operations is optional, and
ftrace_event_id_fops does not set it.  In default_file_open(), after
all other checks have passed, return 0 if the underlying struct
file_operations does not implement open.

Fixes: 757ff7244358 ("tracefs: Restrict tracefs when the kernel is …")
References: https://bugs.debian.org/934304
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name tracefs-fix-potential-null-dereference-in-default_fi.patch

tracefs: Restrict tracefs when the kernel is locked down

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

Signed-off-by: Matthew Garrett <mjg59@google.com>
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
[bwh: Convert back to the non-LSM lockdown API]

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0031-tracefs-Restrict-tracefs-when-the-kernel-is-locked-d.patch

lockdown: Print current->comm in restriction messages

Print the content of current->comm in messages generated by lockdown to
indicate a restriction that was hit.  This makes it a bit easier to find
out what caused the message.

The message now patterned something like:

Lockdown: <comm>: <what> is restricted; see man kernel_lockdown.7

Signed-off-by: David Howells <dhowells@redhat.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0030-lockdown-Print-current-comm-in-restriction-messages.patch

efi: Lock down the kernel if booted in secure boot mode

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>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
cc: linux-efi@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0029-efi-Lock-down-the-kernel-if-booted-in-secure-boot-mo.patch

efi: Add an EFI_SECURE_BOOT flag to indicate secure boot mode

UEFI machines can be booted in Secure Boot mode.  Add an EFI_SECURE_BOOT
flag that can be passed to efi_enabled() to find out whether secure boot is
enabled.

Move the switch-statement in x86's setup_arch() that inteprets the
secure_boot boot parameter to generic code and set the bit there.

Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
cc: linux-efi@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0028-efi-Add-an-EFI_SECURE_BOOT-flag-to-indicate-secure-b.patch

debugfs: Restrict debugfs when the kernel is locked down

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 <dhowells@redhat.com>
cc: Andy Shevchenko <andy.shevchenko@gmail.com>
cc: acpi4asus-user@lists.sourceforge.net
cc: platform-driver-x86@vger.kernel.org
cc: Matthew Garrett <mjg59@srcf.ucam.org>
cc: Thomas Gleixner <tglx@linutronix.de>

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0027-debugfs-Restrict-debugfs-when-the-kernel-is-locked-d.patch

Lock down perf

Disallow the use of certain perf facilities that might allow userspace to
access kernel data.

Signed-off-by: David Howells <dhowells@redhat.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0026-Lock-down-perf.patch

bpf: Restrict kernel image access functions when the kernel is locked 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 and kernel memory to be altered without
restriction.

Completely prohibit the use of BPF when the kernel is locked down.

Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: netdev@vger.kernel.org
cc: Chun-Yi Lee <jlee@suse.com>
cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0025-bpf-Restrict-kernel-image-access-functions-when-the-.patch

Lock down kprobes

Disallow the creation of kprobes when the kernel is locked down by
preventing their registration.  This prevents kprobes from being used to
access kernel memory, either to make modifications or to steal crypto data.

Reported-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0024-Lock-down-kprobes.patch

Lock down /proc/kcore

Disallow access to /proc/kcore when the kernel is locked down to prevent
access to cryptographic data.

Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <james.l.morris@oracle.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0023-Lock-down-proc-kcore.patch

x86/mmiotrace: Lock down the testmmiotrace module

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.

Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: David Howells <dhowells@redhat.com
cc: Thomas Gleixner <tglx@linutronix.de>
cc: Steven Rostedt <rostedt@goodmis.org>
cc: Ingo Molnar <mingo@kernel.org>
cc: "H. Peter Anvin" <hpa@zytor.com>
cc: x86@kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0022-x86-mmiotrace-Lock-down-the-testmmiotrace-module.patch

Lock down module params that specify hardware parameters (eg. ioport)

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 <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0021-Lock-down-module-params-that-specify-hardware-parame.patch

Lock down TIOCSSERIAL

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>
cc: Jiri Slaby <jslaby@suse.com>

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0020-Lock-down-TIOCSSERIAL.patch

Prohibit PCMCIA CIS storage when the kernel is locked down

Prohibit replacement of the PCMCIA Card Information Structure when the
kernel is locked down.

Suggested-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-pcmcia@lists.infradead.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0019-Prohibit-PCMCIA-CIS-storage-when-the-kernel-is-locke.patch

acpi: Disable APEI error injection if the kernel is locked down

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>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: linux-acpi@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0018-acpi-Disable-APEI-error-injection-if-the-kernel-is-l.patch

acpi: Disable ACPI table override if the kernel is locked down

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>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: linux-acpi@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0017-acpi-Disable-ACPI-table-override-if-the-kernel-is-lo.patch

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

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 <jwboyer@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Matthew Garrett <mjg59@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
cc: Dave Young <dyoung@redhat.com>
cc: linux-acpi@vger.kernel.org
[bwh: Convert back to the non-LSM lockdown API]

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0016-acpi-Ignore-acpi_rsdp-kernel-param-when-the-kernel-h.patch

ACPI: Limit access to custom_method when the kernel is locked down

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 <mjg59@srcf.ucam.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: linux-acpi@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0015-ACPI-Limit-access-to-custom_method-when-the-kernel-i.patch

x86/msr: Restrict MSR access when the kernel is locked down

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.

MSR accesses are logged for the purposes of building up a whitelist as per
Alan Cox's suggestion.

Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: x86@kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0014-x86-msr-Restrict-MSR-access-when-the-kernel-is-locke.patch

x86: Lock down IO port access when the kernel is locked down

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 <mjg59@srcf.ucam.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: x86@kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0013-x86-Lock-down-IO-port-access-when-the-kernel-is-lock.patch

PCI: Lock down BAR access when the kernel is locked down

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 <mjg59@srcf.ucam.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: linux-pci@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0012-PCI-Lock-down-BAR-access-when-the-kernel-is-locked-d.patch

uswsusp: Disable when the kernel is locked down

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>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
Reviewed-by: James Morris <james.l.morris@oracle.com>
cc: linux-pm@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0011-uswsusp-Disable-when-the-kernel-is-locked-down.patch

hibernate: Disable when the kernel is locked down

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>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: linux-pm@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0010-hibernate-Disable-when-the-kernel-is-locked-down.patch

kexec_file: Restrict at runtime if the kernel is locked down

When KEXEC_SIG is not enabled, kernel should not load images through
kexec_file systemcall if the kernel is locked down unless IMA can be used
to validate the image.

[Modified by David Howells to fit with modifications to the previous patch
 and to return -EPERM if the kernel is locked down for consistency with
 other lockdowns]

Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Jiri Bohac <jbohac@suse.cz>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
cc: Chun-Yi Lee <jlee@suse.com>
cc: kexec@lists.infradead.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0009-kexec_file-Restrict-at-runtime-if-the-kernel-is-lock.patch

kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

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.

[Modified by David Howells such that:

 (1) verify_pefile_signature() differentiates between no-signature and
     sig-didn't-match in its returned errors.

 (2) kexec fails with EKEYREJECTED and logs an appropriate message if
     signature checking is enforced and an signature is not found, uses
     unsupported crypto or has no matching key.

 (3) kexec fails with EKEYREJECTED if there is a signature for which we
     have a key, but signature doesn't match - even if in non-forcing mode.

 (4) kexec fails with EBADMSG or some other error if there is a signature
     which cannot be parsed - even if in non-forcing mode.

 (5) kexec fails with ELIBBAD if the PE file cannot be parsed to extract
     the signature - even if in non-forcing mode.

]

Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Jiri Bohac <jbohac@suse.cz>
cc: Matthew Garrett <mjg59@srcf.ucam.org>
cc: Chun-Yi Lee <jlee@suse.com>
cc: kexec@lists.infradead.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0008-kexec_file-split-KEXEC_VERIFY_SIG-into-KEXEC_SIG-and.patch

Copy secure_boot flag in boot params across kexec reboot

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>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: kexec@lists.infradead.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0007-Copy-secure_boot-flag-in-boot-params-across-kexec-re.patch

kexec_load: Disable at runtime if the kernel is locked down

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: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
Reviewed-by: James Morris <james.l.morris@oracle.com>
cc: kexec@lists.infradead.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0006-kexec_load-Disable-at-runtime-if-the-kernel-is-locke.patch

Restrict /dev/{mem,kmem,port} when the kernel is locked down

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: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0005-Restrict-dev-mem-kmem-port-when-the-kernel-is-locked.patch

Enforce module signatures if the kernel is locked down

If the kernel is locked down, require that all modules have valid
signatures that we can verify or that IMA can validate the file.

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 IMA will have validated the image, return 0 (okay).

     (c) 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.

Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Jiri Bohac <jbohac@suse.cz>
cc: "Lee, Chun-Yi" <jlee@suse.com>
cc: James Morris <james.l.morris@oracle.com>

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0004-Enforce-module-signatures-if-the-kernel-is-locked-do.patch

ima: require secure_boot rules in lockdown mode

Require the "secure_boot" rules, whether or not it is specified
on the boot command line, for both the builtin and custom policies
in secure boot lockdown mode.

Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0003-ima-require-secure_boot-rules-in-lockdown-mode.patch

Add a SysRq option to lift kernel lockdown

Make an option to provide a sysrq key that will lift the kernel lockdown,
thereby allowing the running kernel image to be accessed and modified.

On x86 this is triggered with SysRq+x, but this key may not be available on
all arches, so it is set by setting LOCKDOWN_LIFT_KEY in asm/setup.h.
Since this macro must be defined in an arch to be able to use this facility
for that arch, the Kconfig option is restricted to arches that support it.

Signed-off-by: Kyle McMartin <kyle@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: x86@kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0002-Add-a-SysRq-option-to-lift-kernel-lockdown.patch

Add the ability to lock down access to the running kernel image

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>
Acked-by: James Morris <james.l.morris@oracle.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0001-Add-the-ability-to-lock-down-access-to-the-running-k.patch

Partially revert "net: socket: implement 64-bit timestamps"

The introduction of SIOCGSTAMP{,NS}_OLD and move of SICOGSTAMP{,NS} to
a different header has caused build failures for various user-space
programs including qemu and suricata.  It also causes a test failure
for glibc.

For now, remove the _OLD suffix on the old ioctl numbers and require
programs using 64-bit timestamps to explicitly use SIOCGSTAMP{,NS}_NEW.

References: https://lore.kernel.org/lkml/af0eb47a-5b98-1bd9-3e8d-652e7f28b01f@de.ibm.com/
References: https://bugs.debian.org/934316
References: https://ci.debian.net/data/autopkgtest/testing/amd64/g/glibc/2772289/log.gz
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name partially-revert-net-socket-implement-64-bit-timestamps.patch

Revert "objtool: Fix CONFIG_STACK_VALIDATION=y warning for out-of-tree modules"

This reverts commit 9f0c18aec620bc9d82268b3cb937568dd07b43ff.  This
check doesn't make sense for OOT modules as they should always use
a pre-built objtool.

Gbp-Pq: Topic debian
Gbp-Pq: Name revert-objtool-fix-config_stack_validation-y-warning.patch

Partially revert "usb: Kconfig: using select for USB_COMMON dependency"

This reverts commit cb9c1cfc86926d0e86d19c8e34f6c23458cd3478 for
USB_LED_TRIG.  This config symbol has bool type and enables extra code
in usb_common itself, not a separate driver.  Enabling it should not
force usb_common to be built-in!

Fixes: cb9c1cfc8692 ("usb: Kconfig: using select for USB_COMMON dependency")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name partially-revert-usb-kconfig-using-select-for-usb_co.patch

fs: Add MODULE_SOFTDEP declarations for hard-coded crypto drivers

This helps initramfs builders and other tools to find the full
dependencies of a module.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[Lukas Wunner: Forward-ported to 4.11: drop parts applied upstream]

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name fs-add-module_softdep-declarations-for-hard-coded-cr.patch

phy/marvell: disable 4-port phys

The Marvell PHY was originally disabled because it can cause networking
failures on some systems. According to Lennert Buytenhek this is because some
of the variants added did not share the same register layout. Since the known
cases are all 4-ports disable those variants (indicated by a 4 in the
penultimate position of the model name) until they can be audited for
correctness.

[bwh: Also #if-out the init functions for these PHYs to avoid
 compiler warnings]

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name disable-some-marvell-phys.patch

RISC-V: Add an Image header that boot loader can parse.

Currently, the last stage boot loaders such as U-Boot can accept only
uImage which is an unnecessary additional step in automating boot
process.

Add an image header that boot loader understands and boot Linux from
flat Image directly.

This header is based on ARM64 boot image header and provides an
opportunity to combine both ARM64 & RISC-V image headers in future.

Also make sure that PE/COFF header can co-exist in the same image so
that EFI stub can be supported for RISC-V in future. EFI specification
needs PE/COFF image header in the beginning of the kernel image in order
to load it as an EFI application. In order to support EFI stub, code0
should be replaced with "MZ" magic string and res4(at offset 0x3c)
should point to the rest of the PE/COFF header (which will be added
during EFI support).

Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot + Linux.

Signed-off-by: Atish Patra <atish.patra@wdc.com>
Reviewed-by: Karsten Merker <merker@debian.org>
Tested-by: Karsten Merker <merker@debian.org> (QEMU+OpenSBI+U-Boot)
Tested-by: Kevin Hilman <khilman@baylibre.com> (OpenSBI + U-Boot + Linux)
[paul.walmsley@sifive.com: fixed whitespace in boot-image-header.txt;
 converted structure comment to kernel-doc format and added some detail]
Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
Gbp-Pq: Topic features/riscv64
Gbp-Pq: Name RISC-V-Add-Image-header.patch

x86: Make x32 syscall support conditional on a kernel parameter

Enabling x32 in the standard amd64 kernel would increase its attack
surface while provide no benefit to the vast majority of its users.
No-one seems interested in regularly checking for vulnerabilities
specific to x32 (at least no-one with a white hat).

Still, adding another flavour just to turn on x32 seems wasteful.  And
the only differences on syscall entry are a few instructions that mask
out the x32 flag and compare the syscall number.

Use a static key to control whether x32 syscalls are really enabled, a
Kconfig parameter to set its default value and a kernel parameter
"syscall.x32" to change it at boot time.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name x86-make-x32-syscall-support-conditional.patch

x86: memtest: WARN if bad RAM found

Since this is not a particularly thorough test, if we find any bad
bits of RAM then there is a fair chance that there are other bad bits
we fail to detect.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name x86-memtest-WARN-if-bad-RAM-found.patch

MIPS: Loongson 3: Add Loongson LS3A RS780E 1-way machine definition

Add a Loongson LS3A RS780E 1-way machine definition, which only differs
from other Loongson 3 based machines by the UART base clock speed.

Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
[bwh: Forward-ported to 4.2]

Gbp-Pq: Topic features/mips
Gbp-Pq: Name MIPS-Loongson-3-Add-Loongson-LS3A-RS780E-1-way-machi.patch

MIPS: increase MAX_PHYSMEM_BITS on Loongson 3 only

Commit c4617318 broke Loongson-2 support and maybe even more by increasing
the value of MAX_PHYSMEM_BITS. At it is currently only needed on
Loongson-3, define it conditionally.

Note: this should be replace by upstream fix when available.

Gbp-Pq: Topic features/mips
Gbp-Pq: Name MIPS-increase-MAX-PHYSMEM-BITS-on-Loongson-3-only.patch

powerpc: Fix -mcpu= options for SPE-only compiler

GCC for Debian's "powerpcspe" architecture only supports 32-bit
SPE targets, and using -mcpu=powerpc or -mcpu=powerpc64 is a fatal
error.

* Change the test for a biarch compiler to pass both the -m32 and -m64
  options, so that it doesn't catch 32-bit-only compilers
* Add an ifdef CONFIG_PPC64 around the 64-bit CPU option definitions

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/powerpc
Gbp-Pq: Name powerpc-fix-mcpu-options-for-spe-only-compiler.patch

x86-32: Disable 3D-Now in generic config

We want the 686 flavour to run on Geode LX and similar AMD family 5
CPUs as well as family 6 and higher CPUs.  This used to work with
CONFIG_M686=y.  However commit 25d76ac88821 "x86/Kconfig: Explicitly
enumerate i686-class CPUs in Kconfig" in Linux 4.16 has made the
kernel require family 6 or higher.

It looks like a sensible choice would be to enable CONFIG_MGEODE_LX
and CONFIG_X86_GENERIC (for more generic optimisations), but this
currently enables CONFIG_X86_USE_3D_NOW which will cause the kernel to
crash on CPUs without the AMD-specific 3D-Now instructions.

Make CONFIG_X86_USE_3DNOW depend on CONFIG_X86_GENERIC being disabled.

Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name x86-32-disable-3dnow-in-generic-config.patch

arm64/acpi: Add fixup for HPE m400 quirks

Adds a new ACPI init routine acpi_fixup_m400_quirks that adds
a work-around for HPE ProLiant m400 APEI firmware problems.

The work-around disables APEI when CONFIG_ACPI_APEI is set and
m400 firmware is detected.  Without this fixup m400 systems
experience errors like these on startup:

  [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 2
  [Hardware Error]: event severity: fatal
  [Hardware Error]:  Error 0, type: fatal
  [Hardware Error]:   section_type: memory error
  [Hardware Error]:   error_status: 0x0000000000001300
  [Hardware Error]:   error_type: 10, invalid address
  Kernel panic - not syncing: Fatal hardware error!

Signed-off-by: Geoff Levand <geoff@infradead.org>
[bwh: Adjust context to apply to Linux 4.19]

Gbp-Pq: Topic bugfix/arm64
Gbp-Pq: Name arm64-acpi-Add-fixup-for-HPE-m400-quirks.patch

powerpc/boot: Fix missing crc32poly.h when building with KERNEL_XZ

After commit faa16bc404d7 ("lib: Use existing define with
polynomial") the lib/xz/xz_crc32.c includes a header from include/linux
directory thus any other user of this code should define proper include
path.

This fixes the build error on powerpc with CONFIG_KERNEL_XZ:

    In file included from ../arch/powerpc/boot/../../../lib/decompress_unxz.c:233:0,
                     from ../arch/powerpc/boot/decompress.c:42:
    ../arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:29: fatal error: linux/crc32poly.h: No such file or directory

Reported-by: Michal Kubecek <mkubecek@suse.cz>
Fixes: faa16bc404d7 ("lib: Use existing define with polynomial")
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: Meelis Roos <mroos@linux.ee>
Tested-by: Michal Kubecek <mkubecek@suse.cz>
Gbp-Pq: Topic bugfix/powerpc
Gbp-Pq: Name powerpc-boot-fix-missing-crc32poly.h-when-building-with-kernel_xz.patch

ARM: mm: Export __sync_icache_dcache() for xen-privcmd

The xen-privcmd driver, which can be modular, calls set_pte_at()
which in turn may call __sync_icache_dcache().

The call to __sync_icache_dcache() may be optimised out because it is
conditional on !pte_special(), and xen-privcmd calls pte_mkspecial().
However, in a non-LPAE configuration there is no "special" bit and the
call is really unconditional.

Fixes: 3ad0876554ca ("xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/arm
Gbp-Pq: Name arm-mm-export-__sync_icache_dcache-for-xen-privcmd.patch

powerpc/lib/Makefile: Don't pull in quad.o for 32-bit kernels

The functions exported by quad.o are only used when guarded by
__powerpc64__ and so are unused on 32-bit kernels. Moreover, their
implementations make use of instructions which will cause an illegal
instruction error on 32-bit processors, and are not accepted by the
assembler for SPE processors.

Fixes: 31bfdb036f12 ("powerpc: Use instruction emulation infrastructure to handle alignment faults")
Signed-off-by: James Clarke <jrtc27@jrtc27.com>
Gbp-Pq: Topic bugfix/powerpc
Gbp-Pq: Name powerpc-lib-makefile-don-t-pull-in-quad.o-for-32-bit.patch

powerpc/lib/sstep: Fix building for powerpcspe

On powerpcspe, ptesync is not a recognised instruction and so fails to
assemble. We don't expect to have to emulate an lwsync or a ptesync on a
32-bit kernel, so just ifdef them out, and catch any unexpected barrier
types.

Fixes: 3cdfcbfd32b9 ("powerpc: Change analyse_instr so it doesn't modify *regs")
Signed-off-by: James Clarke <jrtc27@jrtc27.com>
Gbp-Pq: Topic bugfix/powerpc
Gbp-Pq: Name powerpc-lib-sstep-fix-building-for-powerpcspe.patch

arch/sh: Check for kprobe trap number before trying to handle a kprobe trap

The DIE_TRAP notifier chain is run both for kprobe traps and for BUG/WARN
traps. The kprobe code assumes to be only called for
BREAKPOINT_INSTRUCTION, and concludes to have hit a concurrently removed
kprobe if it finds anything else at the faulting locations. This includes
TRAPA_BUG_OPCODE used for BUG and WARN.

The consequence is that kprobe_handler returns 1. This makes
kprobe_exceptions_notify return NOTIFY_STOP, and prevents handling the BUG
statement. This also prevents moving $pc away from the trap instruction,
so the system locks up in an endless loop

Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
Gbp-Pq: Topic bugfix/sh
Gbp-Pq: Name sh-check-for-kprobe-trap-number-before-trying-to-handle-a-kprobe-trap.patch

sh: Do not use hyphen in exported variable names

arch/sh/Makefile defines and exports ld-bfd to be used by
arch/sh/boot/Makefile and arch/sh/boot/compressed/Makefile.  Similarly
arch/sh/boot/Makefile defines and exports suffix-y to be used by
arch/sh/boot/compressed/Makefile.  However some shells, including
dash, will not pass through environment variables whose name includes
a hyphen.  Usually GNU make does not use a shell to recurse, but if
e.g. $(srctree) contains '~' it will use a shell here.

Rename these variables to ld_bfd and suffix_y.

References: https://buildd.debian.org/status/fetch.php?pkg=linux&arch=sh4&ver=4.13%7Erc5-1%7Eexp1&stamp=1502943967&raw=0
Fixes: ef9b542fce00 ("sh: bzip2/lzma uImage support.")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/sh
Gbp-Pq: Name sh-boot-do-not-use-hyphen-in-exported-variable-name.patch

perf tools: Fix unwind build on i386

EINVAL may not be defined when building unwind-libunwind.c with
REMOTE_UNWIND_LIBUNWIND, resulting in a compiler error in
LIBUNWIND__ARCH_REG_ID().  Its only caller, access_reg(), only checks
for a negative return value and doesn't care what it is.  So change
-EINVAL to -1.

Fixes: 52ffe0ff02fc ("Support x86(32-bit) cross platform callchain unwind.")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name perf-tools-fix-unwind-build-on-i386.patch

arm64: dts: rockchip: correct voltage selector on Firefly-RK3399

Without this patch the Firefly-RK3399 board boot process hangs after these
lines:

   fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected!
   fan53555-reg: supplied by vcc_sys
   vcc1v8_s3: supplied by vcc_1v8

Blacklisting driver fan53555 allows booting.

The device tree uses a value of fcs,suspend-voltage-selector different to
any other board.

Changing this setting to the usual value is sufficient to enable booting
and also matches the value used in the vendor kernel.

Fixes: 171582e00db1 ("arm64: dts: rockchip: add support for firefly-rk3399 board")
Cc: stable@vger.kernel.org
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic bugfix/arm64
Gbp-Pq: Name dts-rockchip-correct-voltage-selector-firefly-RK3399.patch

ARM: dts: kirkwood: Fix SATA pinmux-ing for TS419

The old board code for the TS419 assigns MPP pins 15 and 16 as SATA
activity signals (and none as SATA presence signals).  Currently the
device tree assigns the SoC's default pinmux groups for SATA, which
conflict with the second Ethernet port.

Reported-by: gmbh@gazeta.pl
Tested-by: gmbh@gazeta.pl
References: https://bugs.debian.org/855017
Cc: stable@vger.kernel.org # 3.15+
Fixes: 934b524b3f49 ("ARM: Kirkwood: Add DT description of QNAP 419")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/arm
Gbp-Pq: Name arm-dts-kirkwood-fix-sata-pinmux-ing-for-ts419.patch

btrfs: warn about RAID5/6 being experimental at mount time

Too many people come complaining about losing their data -- and indeed,
there's no warning outside a wiki and the mailing list tribal knowledge.
Message severity chosen for consistency with XFS -- "alert" makes dmesg
produce nice red background which should get the point across.

Signed-off-by: Adam Borowski <kilobyte@angband.pl>
[bwh: Also add_taint() so this is flagged in bug reports]

Gbp-Pq: Topic debian
Gbp-Pq: Name btrfs-warn-about-raid5-6-being-experimental-at-mount.patch

fanotify: Taint on use of FANOTIFY_ACCESS_PERMISSIONS

Various free and proprietary AV products use this feature and users
apparently want it.  But punting access checks to userland seems like
an easy way to deadlock the system, and there will be nothing we can
do about that.  So warn and taint the kernel if this feature is
actually used.

Gbp-Pq: Topic debian
Gbp-Pq: Name fanotify-taint-on-use-of-fanotify_access_permissions.patch

fjes: Disable auto-loading

fjes matches a generic ACPI device ID, and relies on its probe
function to distinguish whether that really corresponds to a supported
device.  Very few system will need the driver and it wastes memory on
all the other systems where the same device ID appears, so disable
auto-loading.

Gbp-Pq: Topic debian
Gbp-Pq: Name fjes-disable-autoload.patch

viafb: Autoload on OLPC XO 1.5 only

It appears that viafb won't work automatically on all the boards for
which it has a PCI device ID match.  Currently, it is blacklisted by
udev along with most other framebuffer drivers, so this doesn't matter
much.

However, this driver is required for console support on the XO 1.5.
We need to allow it to be autoloaded on this model only, and then
un-blacklist it in udev.

Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name viafb-autoload-on-olpc-xo1.5-only.patch

snd-pcsp: Disable autoload

There are two drivers claiming the platform:pcspkr device:
- pcspkr creates an input(!) device that can only beep
- snd-pcsp creates an equivalent input device plus a PCM device that can
  play barely recognisable renditions of sampled sound

snd-pcsp is blacklisted by the alsa-base package, but not everyone
installs that.  On PCs where no sound is wanted at all, both drivers
will still be loaded and one or other will complain that it couldn't
claim the relevant I/O range.

In case anyone finds snd-pcsp useful, we continue to build it.  But
remove the alias, to ensure it's not loaded where it's not wanted.

Gbp-Pq: Topic debian
Gbp-Pq: Name snd-pcsp-disable-autoload.patch

cdc_ncm,cdc_mbim: Use NCM by default

Devices that support both NCM and MBIM modes should be kept in NCM
mode unless there is userland support for MBIM.

Set the default value of cdc_ncm.prefer_mbim to false and leave it to
userland (modem-manager) to override this with a modprobe.conf file
once it's ready to speak MBIM.

Gbp-Pq: Topic debian
Gbp-Pq: Name cdc_ncm-cdc_mbim-use-ncm-by-default.patch

intel-iommu: Add Kconfig option to exclude iGPU by default

There is still laptop firmware that touches the integrated GPU behind
the operating system's back, and doesn't say so in the RMRR table.
Enabling the IOMMU for all devices causes breakage.

Replace CONFIG_INTEL_IOMMU_DEFAULT_ON with a 3-way choice
corresponding to "on", "off", and "on,intgpu_off".

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name intel-iommu-add-kconfig-option-to-exclude-igpu-by-default.patch

intel-iommu: Add option to exclude integrated GPU only

There is still laptop firmware that touches the integrated GPU behind
the operating system's back, and doesn't say so in the RMRR table.
Enabling the IOMMU for all devices causes breakage, but turning it off
for all graphics devices seems like a major weakness.

Add an option, intel_iommu=igpu_off, to exclude only integrated GPUs
from remapping.  This is a narrower exclusion than igfx_off: it only
affects Intel devices on the root bus.  Devices attached through an
external port (Thunderbolt or ExpressCard) won't be on the root bus.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name intel-iommu-add-option-to-exclude-integrated-gpu-only.patch

security,perf: Allow further restriction of perf_event_open

When kernel.perf_event_open is set to 3 (or greater), disallow all
access to performance events by users without CAP_SYS_ADMIN.
Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
makes this value the default.

This is based on a similar feature in grsecurity
(CONFIG_GRKERNSEC_PERF_HARDEN).  This version doesn't include making
the variable read-only.  It also allows enabling further restriction
at run-time regardless of whether the default is changed.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/all
Gbp-Pq: Name security-perf-allow-further-restriction-of-perf_event_open.patch

add sysctl to disallow unprivileged CLONE_NEWUSER by default

add sysctl to disallow unprivileged CLONE_NEWUSER by default

This is a short-term patch.  Unprivileged use of CLONE_NEWUSER
is certainly an intended feature of user namespaces.  However
for at least saucy we want to make sure that, if any security
issues are found, we have a fail-safe.

Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
[bwh: Remove unneeded binary sysctl bits]

Gbp-Pq: Topic debian
Gbp-Pq: Name add-sysctl-to-disallow-unprivileged-CLONE_NEWUSER-by-default.patch

yama: Disable by default

Gbp-Pq: Topic debian
Gbp-Pq: Name yama-disable-by-default.patch

sched: Do not enable autogrouping by default

We want to provide the option of autogrouping but without enabling
it by default yet.

Gbp-Pq: Topic debian
Gbp-Pq: Name sched-autogroup-disabled.patch

fs: Enable link security restrictions by default

This reverts commit 561ec64ae67ef25cac8d72bb9c4bfc955edfd415
('VFS: don't do protected {sym,hard}links by default').

Gbp-Pq: Topic debian
Gbp-Pq: Name fs-enable-link-security-restrictions-by-default.patch

hamradio: Disable auto-loading as mitigation against local exploits

We can mitigate the effect of vulnerabilities in obscure protocols by
preventing unprivileged users from loading the modules, so that they
are only exploitable on systems where the administrator has chosen to
load the protocol.

The 'ham' radio protocols (ax25, netrom, rose) are not actively
maintained or widely used.  Therefore disable auto-loading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name hamradio-disable-auto-loading-as-mitigation-against-local-exploits.patch

dccp: Disable auto-loading as mitigation against local exploits

We can mitigate the effect of vulnerabilities in obscure protocols by
preventing unprivileged users from loading the modules, so that they
are only exploitable on systems where the administrator has chosen to
load the protocol.

The 'dccp' protocol is not actively maintained or widely used.
Therefore disable auto-loading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name dccp-disable-auto-loading-as-mitigation-against-local-exploits.patch

decnet: Disable auto-loading as mitigation against local exploits

Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation.  We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.

The 'decnet' protocol is unmaintained and of mostly historical
interest, and the user-space support package 'dnet-common' loads the
module explicitly.  Therefore disable auto-loading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name decnet-Disable-auto-loading-as-mitigation-against-lo.patch

rds: Disable auto-loading as mitigation against local exploits

Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation.  We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.

The 'rds' protocol is one such protocol that has been found to be
vulnerable, and which was not present in the 'lenny' kernel.
Therefore disable auto-loading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name rds-Disable-auto-loading-as-mitigation-against-local.patch

af_802154: Disable auto-loading as mitigation against local exploits

Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation.  We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.

The 'af_802154' (IEEE 802.15.4) protocol is not widely used, was
not present in the 'lenny' kernel, and seems to receive only sporadic
maintenance.  Therefore disable auto-loading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name af_802154-Disable-auto-loading-as-mitigation-against.patch

aufs5.2 standalone patch

Patch headers added by debian/bin/genpatch-aufs

SPDX-License-Identifier: GPL-2.0
aufs5.2 standalone patch

Gbp-Pq: Topic features/all/aufs5
Gbp-Pq: Name aufs5-standalone.patch

aufs5.2 mmap patch

Patch headers added by debian/bin/genpatch-aufs

SPDX-License-Identifier: GPL-2.0
aufs5.2 mmap patch

Gbp-Pq: Topic features/all/aufs5
Gbp-Pq: Name aufs5-mmap.patch

aufs5.2 base patch

Patch headers added by debian/bin/genpatch-aufs

SPDX-License-Identifier: GPL-2.0
aufs5.2 base patch

Gbp-Pq: Topic features/all/aufs5
Gbp-Pq: Name aufs5-base.patch

firmware_class: Refer to Debian wiki page when logging missing firmware

If firmware loading fails due to a missing file, log a second error
message referring to our wiki page about firmware.  This will explain
why some firmware is in non-free, or can't be packaged at all.  Only
do this once per boot.

Do something similar in the radeon and amdgpu drivers, where we have
an early check to avoid failing at a point where we cannot display
anything.

Gbp-Pq: Topic debian
Gbp-Pq: Name firmware_class-refer-to-debian-wiki-firmware-page.patch

radeon, amdgpu: Firmware is required for DRM and KMS on R600 onward

radeon requires firmware/microcode for the GPU in all chips, but for
newer chips (apparently R600 'Evergreen' onward) it also expects
firmware for the memory controller and other sub-blocks.

radeon attempts to gracefully fall back and disable some features if
the firmware is not available, but becomes unstable - the framebuffer
and/or system memory may be corrupted, or the display may stay black.

Therefore, perform a basic check for the existence of
/lib/firmware/{radeon,amdgpu} when a device is probed, and abort if it
is missing, except for the pre-R600 case.

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name radeon-amdgpu-firmware-is-required-for-drm-and-kms-on-r600-onward.patch

firmware: Remove redundant log messages from drivers

Now that firmware_class logs every success and failure consistently,
many other log messages can be removed from drivers.

This will probably need to be split up into multiple patches prior to
upstream submission.

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name firmware-remove-redundant-log-messages-from-drivers.patch

firmware_class: Log every success and failure against given device

The hundreds of users of request_firmware() have nearly as many
different log formats for reporting failures.  They also have only the
vaguest hint as to what went wrong; only firmware_class really knows
that.  Therefore, add specific log messages for the failure modes that
aren't currently logged.

In case of a driver that tries multiple names, this may result in the
impression that it failed to initialise.  Therefore, also log successes.

This makes many error messages in drivers redundant, which will be
removed in later patches.

This does not cover the case where we fall back to a user-mode helper
(which is no longer enabled in Debian).

NOTE: hw-detect will depend on the "firmware: failed to load %s (%d)\n"
format to detect missing firmware.

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name firmware_class-log-every-success-and-failure.patch

iwlwifi: Do not request unreleased firmware for IWL6000

The iwlwifi driver currently supports firmware API versions 4-6 for
these devices.  It will request the file for the latest supported
version and then fall back to earlier versions.  However, the latest
version that has actually been released is 4, so we expect the
requests for versions 6 and then 5 to fail.

The installer appears to report any failed request, and it is probably
not easy to detect that this particular failure is harmless.  So stop
requesting the unreleased firmware.

Gbp-Pq: Topic debian
Gbp-Pq: Name iwlwifi-do-not-request-unreleased-firmware.patch

af9005: Use request_firmware() to load register init script

Read the register init script from the Windows driver.  This is sick
but should avoid the potential copyright infringement in distributing
a version of the script which is directly derived from the driver.

Gbp-Pq: Topic features/all
Gbp-Pq: Name drivers-media-dvb-usb-af9005-request_firmware.patch

android: Enable building ashmem and binder as modules

We want to enable use of the Android ashmem and binder drivers to
support Anbox, but they should not be built-in as that would waste
resources and increase security attack surface on systems that don't
need them.

- Add a MODULE_LICENSE declaration to ashmem
- Change the Makefiles to build each driver as an object with the
  "_linux" suffix (which is what Anbox expects)
- Change config symbol types to tristate

Gbp-Pq: Topic debian
Gbp-Pq: Name android-enable-building-ashmem-and-binder-as-modules.patch

Export symbols needed by Android drivers

We want to enable use of the Android ashmem and binder drivers to
support Anbox, but they should not be built-in as that would waste
resources and increase security attack surface on systems that don't
need them.

Export the currently un-exported symbols they depend on.

Gbp-Pq: Topic debian
Gbp-Pq: Name export-symbols-needed-by-android-drivers.patch

wireless: Add Debian wireless-regdb certificates

This hex dump is generated using:

{
    for cert in debian/certs/wireless-regdb-*.pem; do
        openssl x509 -in $cert -outform der;
    done
} | hexdump -v -e '1/1 "0x%.2x," "\n"' > net/wireless/certs/debian.hex

Gbp-Pq: Topic debian
Gbp-Pq: Name wireless-add-debian-wireless-regdb-certificates.patch

Install perf scripts non-executable

[bwh: Forward-ported to 4.13]

Gbp-Pq: Topic debian
Gbp-Pq: Name tools-perf-install.patch

Create manpages and binaries including the version

[bwh: Fix version insertion in perf man page cross-references and perf
man page title.  Install bash_completion script for perf with a
version-dependent name.  And do the same for trace.]

Gbp-Pq: Topic debian
Gbp-Pq: Name tools-perf-version.patch

powerpcspe-omit-uimage

Gbp-Pq: Topic debian
Gbp-Pq: Name powerpcspe-omit-uimage.patch

Fix uImage build

[bwh: This was added without a description, but I think it is dealing
with a similar issue to powerpcspe-omit-uimage.patch]

Gbp-Pq: Topic debian
Gbp-Pq: Name arch-sh4-fix-uimage-build.patch

Disable uImage generation for mips generic

MIPS generic trys to generate uImage when build, which then ask for
u-boot-tools.

Gbp-Pq: Topic debian
Gbp-Pq: Name mips-boston-disable-its.patch

Partially revert "MIPS: Add -Werror to arch/mips/Kbuild"

This reverts commits 66f9ba101f54bda63ab1db97f9e9e94763d0651b and
5373633cc9253ba82547473e899cab141c54133e.

We really don't want to add -Werror anywhere.

Gbp-Pq: Topic debian
Gbp-Pq: Name mips-disable-werror.patch

Hardcode arch script output

Here's a patch that simply uses hardcoded definitions instead of
doing the dynamic tests that require architecture-specific scripts.

I don't particularly like this approach because it restricts
portability and diverts from upstream. But, it is simpler, and this
really needs to be fixed somehow before etch (along with a rebuild of
linux-modules-extra-2.6), so I'm willing to live with it if my other
patch is deemed unacceptable.

My primary concern is that, in the future, the output of these scripts
will change and we (or our successors) will either not notice or
forget to update the hardcoded values.

Including the scripts in linux-kbuild will avoid this manual step
altogether, and allow for the possibility of other archs to provide
their own scripts in the future.

Gbp-Pq: Topic debian
Gbp-Pq: Name ia64-hardcode-arch-script-output.patch

Tweak gitignore for Debian pkg-kernel using git svn.

[bwh: Tweak further for pure git]

Gbp-Pq: Topic debian
Gbp-Pq: Name gitignore.patch

kbuild: Make the toolchain variables easily overwritable

Allow make variables to be overridden for each flavour by a file in
the build tree, .kernelvariables.

We currently use this for ARCH, KERNELRELEASE, CC, and in some cases
also CROSS_COMPILE, CFLAGS_KERNEL and CFLAGS_MODULE.

This file can only be read after we establish the build tree, and all
use of $(ARCH) needs to be moved after this.

Gbp-Pq: Topic debian
Gbp-Pq: Name kernelvariables.patch

Make mkcompile_h accept an alternate timestamp string

We want to include the Debian version in the utsname::version string
instead of a full timestamp string.  However, we still need to provide
a standard timestamp string for gen_initramfs_list.sh to make the
kernel image reproducible.

Make mkcompile_h use $KBUILD_BUILD_VERSION_TIMESTAMP in preference to
$KBUILD_BUILD_TIMESTAMP.

Gbp-Pq: Topic debian
Gbp-Pq: Name uname-version-timestamp.patch

Include package version along with kernel release in stack traces

For distribution binary packages we assume
$DISTRIBUTION_OFFICIAL_BUILD, $DISTRIBUTOR and $DISTRIBUTION_VERSION
are set.

Gbp-Pq: Topic debian
Gbp-Pq: Name version.patch

video: Remove nvidiafb and rivafb

These drivers contain register programming code provided by the
hardware vendor that appears to have been deliberately obfuscated.
This is arguably not the preferred form for modification.

These drivers are also largely redundant with nouveau.  The RIVA 128
(NV3) is not supported by nouveau but is about 15 years old and
probably discontinued 10 years ago.

Gbp-Pq: Topic debian/dfsg
Gbp-Pq: Name video-remove-nvidiafb-and-rivafb.patch

Add removal patches for: 3c359, smctr, keyspan, cops

Gbp-Pq: Topic debian/dfsg
Gbp-Pq: Name drivers-net-appletalk-cops.patch

vs6624: mark as broken

Gbp-Pq: Topic debian/dfsg
Gbp-Pq: Name vs6624-disable.patch

dvb-usb-af9005: mark as broken

Gbp-Pq: Topic debian/dfsg
Gbp-Pq: Name drivers-media-dvb-dvb-usb-af9005-disable.patch

Remove microcode patches for mgsuvd (not enabled in Debian configs)

Gbp-Pq: Topic debian/dfsg
Gbp-Pq: Name arch-powerpc-platforms-8xx-ucode-disable.patch