tools/build: Remove bpf() run-time check at build time

It is not correct to test that a syscall works on the build system's
kernel.  We might be building on an earlier kernel version or with
security restrictions that block bpf().

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name tools-build-remove-bpf-run-time-check-at-build-time.patch

alpha: uapi: Add support for __SANE_USERSPACE_TYPES__

This fixes compiler errors in perf such as:

tests/attr.c: In function 'store_event':
tests/attr.c:66:27: error: format '%llu' expects argument of type 'long long unsigned int', but argument 6 has type '__u64 {aka long unsigned int}' [-Werror=format=]
  snprintf(path, PATH_MAX, "%s/event-%d-%llu-%d", dir,
                           ^

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Tested-by: Michael Cree <mcree@orcon.net.nz>
Cc: stable@vger.kernel.org
Gbp-Pq: Topic bugfix/alpha
Gbp-Pq: Name alpha-uapi-add-support-for-__sane_userspace_types__.patch

Revert "perf build: Fix libunwind feature detection on 32-bit x86"

This reverts commit 05b41775e2edd69a83f592e3534930c934d4038e.
It broke feature detection that was working just fine for us.

Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name revert-perf-build-fix-libunwind-feature-detection-on.patch

tools/lib/traceevent: Use LDFLAGS

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name tools-lib-traceevent-use-ldflags.patch

tools/perf: Remove shebang lines from perf scripts

perf scripts need to be invoked through perf, not directly through
perl (or other language interpreter).  So including shebang lines in
them is useless and possibly misleading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name tools-perf-remove-shebangs.patch

perf tools: Use $KBUILD_BUILD_TIMESTAMP as man page date

This allows man pages to be built reproducibly.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name tools-perf-man-date.patch

kbuild: Fix recordmcount dependency for OOT modules

We never rebuild anything in-tree when building an out-of-tree
modules, so external modules should not depend on the recordmcount
sources.

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name kbuild-fix-recordmcount-dependency.patch

usbip: Document TCP wrappers

Add references to TCP wrappers configuration in the manual page.

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name usbip-document-tcp-wrappers.patch

module: Disable matching missing version CRC

This partly reverts commit cd3caefb4663e3811d37cc2afad3cce642d60061.
We want to fail closed if a symbol version CRC is missing, as the
alternative may allow subverting module signing.

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name module-disable-matching-missing-version-crc.patch

alpha: Restore symbol versions for symbols exported from assembly

Add <asm/asm-prototypes.h> so that genksyms knows the types of
these symbols and can generate CRCs for them.

Fixes: 00fc0e0dda62 ("alpha: move exports to actual definitions")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/alpha
Gbp-Pq: Name alpha-restore-symbol-versions-for-symbols-exported-f.patch

xfrm: policy: check policy direction value

The 'dir' parameter in xfrm_migrate() is a user-controlled byte which is used
as an array index. This can lead to an out-of-bound access, kernel lockup and
DoS. Add a check for the 'dir' value.

This fixes CVE-2017-11600.

References: https://bugzilla.redhat.com/show_bug.cgi?id=1474928
Fixes: 80c9abaabf42 ("[XFRM]: Extension for dynamic update of endpoint address(es)")
Cc: <stable@vger.kernel.org> # v2.6.21-rc1
Reported-by: "bo Zhang" <zhangbo5891001@gmail.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name xfrm-policy-check-policy-direction-value.patch

udp: consistently apply ufo or fragmentation

When iteratively building a UDP datagram with MSG_MORE and that
datagram exceeds MTU, consistently choose UFO or fragmentation.

Once skb_is_gso, always apply ufo. Conversely, once a datagram is
split across multiple skbs, do not consider ufo.

Sendpage already maintains the first invariant, only add the second.
IPv6 does not have a sendpage implementation to modify.

A gso skb must have a partial checksum, do not follow sk_no_check_tx
in udp_send_skb.

Found by syzkaller.

Fixes: e89e9cf539a2 ("[IPv4/IPv6]: UFO Scatter-gather approach")
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name udp-consistently-apply-ufo-or-fragmentation.patch

packet: fix tp_reserve race in packet_set_ring

Updates to tp_reserve can race with reads of the field in
packet_set_ring. Avoid this by holding the socket lock during
updates in setsockopt PACKET_RESERVE.

This bug was discovered by syzkaller.

Fixes: 8913336a7e8d ("packet: add PACKET_RESERVE sockopt")
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name packet-fix-tp_reserve-race-in-packet_set_ring.patch

PCI: Set pci=nobios by default

CONFIG_PCI_GOBIOS results in physical addresses 640KB-1MB being mapped
W+X, which is undesirable for security reasons and will result in a
warning at boot now that we enable CONFIG_DEBUG_WX.

This can be overridden using the kernel parameter "pci=nobios", but we
want to disable W+X by default.  Disable PCI BIOS probing by default;
it can still be enabled using "pci=bios".

Gbp-Pq: Topic debian
Gbp-Pq: Name i386-686-pae-pci-set-pci-nobios-by-default.patch

arm64: add kernel config option to lock down when in Secure Boot mode

Add a kernel configuration option to lock down the kernel, to restrict
userspace's ability to modify the running kernel when UEFI Secure Boot is
enabled. Based on the x86 patch by Matthew Garrett.

Determine the state of Secure Boot in the EFI stub and pass this to the
kernel using the FDT.

Signed-off-by: Linn Crosetto <linn@hpe.com>
[bwh: Forward-ported to 4.10: adjust context]
[Lukas Wunner: Forward-ported to 4.11: drop parts applied upstream]
[bwh: Forward-ported to 4.11 and lockdown patch set:
 - Convert result of efi_get_secureboot() to a boolean
 - Use lockdown API and naming]

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name arm64-add-kernel-config-option-to-lock-down-when.patch

mtd: Disable slram and phram when locked down

The slram and phram drivers both allow mapping regions of physical
address space such that they can then be read and written by userland
through the MTD interface.  This is probably usable to manipulate
hardware into overwriting kernel code on many systems.  Prevent that
if locked down.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name mtd-disable-slram-and-phram-when-locked-down.patch

Enable cold boot attack mitigation

[Lukas Wunner: Forward-ported to 4.11: adjust context]

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name enable-cold-boot-attack-mitigation.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 0061-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>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0060-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>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0059-Prohibit-PCMCIA-CIS-storage-when-the-kernel-is-locke.patch

scsi: Lock down the eata driver

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: Alan Cox <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

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0058-scsi-Lock-down-the-eata-driver.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.  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>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0057-bpf-Restrict-kernel-image-access-functions-when-the-.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>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0056-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>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0055-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 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>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0054-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 <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0053-ACPI-Limit-access-to-custom_method-when-the-kernel-i.patch

asus-wmi: Restrict debugfs interface when the kernel is locked down

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>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0052-asus-wmi-Restrict-debugfs-interface-when-the-kernel-.patch

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

Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0051-x86-Restrict-MSR-access-when-the-kernel-is-locked-do.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 <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0050-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 <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
[bwh: For 4.12, adjust context]

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0049-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>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0048-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>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0047-hibernate-Disable-when-the-kernel-is-locked-down.patch

kexec_file: Disable at runtime if securelevel has been set

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>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0046-kexec_file-Disable-at-runtime-if-securelevel-has-bee.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>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0045-Copy-secure_boot-flag-in-boot-params-across-kexec-re.patch

kexec: Disable at runtime if the kernel is locked down

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>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0044-kexec-Disable-at-runtime-if-the-kernel-is-locked-dow.patch

Add a sysrq option to exit secure boot mode

Make sysrq+x exit secure boot mode on x86_64, thereby allowing the running
kernel image to be modified.  This lifts the lockdown.

Signed-off-by: Kyle McMartin <kyle@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
[bwh: For 4.12, adjust context]

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0043-Add-a-sysrq-option-to-exit-secure-boot-mode.patch

Restrict /dev/mem and /dev/kmem when the kernel is locked down

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>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0042-Restrict-dev-mem-and-dev-kmem-when-the-kernel-is-loc.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.

Signed-off-by: David Howells <dhowells@redhat.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0041-Enforce-module-signatures-if-the-kernel-is-locked-do.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>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0040-efi-Lock-down-the-kernel-if-booted-in-secure-boot-mo.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>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0039-Add-the-ability-to-lock-down-access-to-the-running-k.patch

efi: Add EFI_SECURE_BOOT bit

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>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0038-efi-Add-EFI_SECURE_BOOT-bit.patch

Annotate hardware config module parameters in drivers/staging/media/

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.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/staging/media/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Mauro Carvalho Chehab <mchehab@kernel.org>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: linux-media@vger.kernel.org
cc: devel@driverdev.osuosl.org
[bwh: For 4.12, fix up filename and permission format]

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0027-Annotate-hardware-config-module-parameters-in-driver.patch

bfq: Re-enable auto-loading when built as a module

The block core requests modules with the "-iosched" name suffix, but
bfq no longer has that suffix.  Add an alias.

Fixes: ea25da48086d ("block, bfq: split bfq-iosched.c into multiple ...")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name bfq-re-enable-auto-loading-when-built-as-a-module.patch

rtlwifi: Fix fallback firmware loading

Commit f70e4df2b384 ("rtlwifi: Add code to read new versions of
firmware") added code to load an old firmware file if the new one is
not available.  Unfortunately that code is never reached because
request_firmware_nowait() does not wait for the firmware to show up
and returns 0 even if the file is not there.

Use the existing fallback mechanism introduced by commit 62009b7f1279
("rtlwifi: rtl8192cu: Add new firmware") instead.

Fixes: f70e4df2b384 ("rtlwifi: Add code to read new versions of firmware")
Cc: stable@vger.kernel.org
Signed-off-by: Sven Joachim <svenjoac@gmx.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name rtlwifi-fix-fallback-firmware-loading.patch

rtlwifi: Fix memory leak when firmware request fails

This patch will fix memory leak when firmware request fails

Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name rtlwifi-fix-memory-leak-when-firmware-request-fails.patch

Kbuild.include: addtree: Remove quotes before matching path

systemtap currently fails to build modules when the kernel source and
object trees are separate.

systemtap adds something like -I"/usr/share/systemtap/runtime" to
EXTRA_CFLAGS, and addtree should not adjust this as it's specifying an
absolute directory.  But since make has no understanding of shell
quoting, it does anyway.

For a long time this didn't matter, because addtree would still emit
the original -I option after the adjusted one.  However, commit
db547ef19064 ("Kbuild: don't add obj tree in additional includes")
changed it to remove the original -I option.

Remove quotes (both double and single) before matching against the
excluded patterns.

References: https://bugs.debian.org/856474
Reported-by: Jack Henschel <jackdev@mailbox.org>
Reported-by: Ritesh Raj Sarraf <rrs@debian.org>
Fixes: db547ef19064 ("Kbuild: don't add obj tree in additional includes")
Cc: stable@vger.kernel.org # 4.8+
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name kbuild-include-addtree-remove-quotes-before-matching-path.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

kbuild: Do not use hyphen in exported variable name

This definition in Makefile.dtbinst:

    export dtbinst-root ?= $(obj)

should define and export dtbinst-root when handling the root dts
directory, and do nothing in the subdirectories.  However, the
variable does not reliably get exported to the environment, perhaps
because its name contains a hyphen.

Rename the variable to dtbinst_root.

References: https://bugs.debian.org/833561
Fixes: 323a028d39cdi ("dts, kbuild: Implement support for dtb vendor subdirs")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name kbuild-do-not-use-hyphen-in-exported-variable-name.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

kbuild: Use -nostdinc in compile tests

gcc 4.8 and later include <stdc-predef.h> by default.  In some
versions of eglibc that includes <bits/predefs.h>, but that may be
missing when building with a biarch compiler.  Also <stdc-predef.h>
itself could be missing as we are only trying to build a kernel, not
userland.

The -nostdinc option disables this, though it isn't explicitly
documented.  This option is already used when actually building
the kernel, but not by cc-option and other tests.  This can result
in silently miscompiling the kernel.

References: https://bugs.debian.org/717557
References: https://bugs.debian.org/726861
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name kbuild-use-nostdinc-in-compile-tests.patch

ARM64: dts: marvell: armada-37xx: Enable uSD on ESPRESSObin

The ESPRESSObin board exposes one of the SDHCI interfaces
via J1 uSD slot. This patch enables it.

Tested-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Signed-off-by: Zbigniew Bodek <zbodek@gmail.com>
[gregory.clement@free-electrons.com:  removed "no-1-8-v"]
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm64
Gbp-Pq: Name ARM64-dts-marvell-armada-37xx-Enable-uSD-on-ESPRESSO.patch

arm64: dts: marvell: Enable second SDHCI controller in Armada 37xx

The Armada 37xx SoCs has 2 SDHCI interfaces. This patch adds the second
one.

Moreover, the Armada 37xx DB v2 board populates the 2 SDHCI interfaces.

The second interface is using pluggable module that can either
have an SD connector or eMMC on it.
This patch adds support for SD module in the device DT.

[ gregory.clement@free-electrons.com:
 - Add more detail in commit log
 - Sort the dt node in address order
 - Document the SD slot in the dts ]

Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm64
Gbp-Pq: Name arm64-dts-marvell-Enable-second-SDHCI-controller-in-.patch

ARM: dts: rockchip: enable ARM Mali GPU on rk3288-veyron

Add reference to the Mali GPU device tree node on rk3288-veyron.
Tested on Minnie and Jerry boards.

Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name arm-dts-rockchip-enable-arm-mali-gpu-on-rk3288-veyro.patch

ARM: dts: rockchip: enable ARM Mali GPU on rk3288-firefly

Add reference to the Mali GPU device tree node on rk3288-firefly.
Tested on Firefly board.

Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name arm-dts-rockchip-enable-arm-mali-gpu-on-rk3288-firef.patch

ARM: dts: rockchip: enable ARM Mali GPU on rk3288-rock2-som

Add reference to the Mali GPU device tree node on the
rk3288-rock2-som platform.  Tested on a Radxa Rock2 Square board.

Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name arm-dts-rockchip-enable-arm-mali-gpu-on-rk3288-rock2.patch

ARM: dts: rockchip: add ARM Mali GPU node for rk3288

Add Mali GPU device tree node for the rk3288 SoC, with devfreq
opp table.

Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name arm-dts-rockchip-add-arm-mali-gpu-node-for-rk3288.patch

dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU

The ARM Mali Midgard GPU family is present in a number of SoCs
from many different vendors such as Samsung Exynos and Rockchip.

Import the device tree bindings documentation from the r16p0
release of the Mali Midgard GPU kernel driver:

  https://developer.arm.com/-/media/Files/downloads/mali-drivers/kernel/mali-midgard-gpu/TX011-SW-99002-r16p0-00rel0.tgz

Remove the copyright and GPL licence header as deemed not necessary.

Redesign the "compatible" property strings to list all the Mali
Midgard GPU types and add vendor specific ones.

Drop the "clock-names" property as the Mali Midgard GPU uses only one
clock (the driver now needs to call clk_get with NULL).

Convert the "interrupt-names" property values to lower-case: "job",
"mmu" and "gpu".

Replace the deprecated "operating-points" optional property with
"operating-points-v2".

Omit the following optional properties in this initial version as they
are only used in very specific cases:

  * snoop_enable_smc
  * snoop_disable_smc
  * jm_config
  * power_model
  * system-coherency
  * ipa-model

Update the example accordingly to reflect all these changes, based on
rk3288 mali-t760.

CC: John Reitan <john.reitan@arm.com>
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name dt-bindings-gpu-add-bindings-for-the-arm-mali-midgar.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 two instructions (mask out
the x32 flag and compare the syscall number).

So pad the standard comparison with a nop and add a kernel parameter
"syscall.x32" which controls whether this is replaced with the x32
version at boot time.  Add a Kconfig parameter to set the default.

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

mm: Revert x86_64 and arm64 ELF_ET_DYN_BASE base

Moving the x86_64 and arm64 PIE base from 0x555555554000 to 0x000100000000
broke AddressSanitizer. This is a partial revert of:

  commit eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE")
  commit 02445990a96e ("arm64: move ELF_ET_DYN_BASE to 4GB / 4MB")

The AddressSanitizer tool has hard-coded expectations about where
executable mappings are loaded. The motivation for changing the PIE
base in the above commits was to avoid the Stack-Clash CVEs that
allowed executable mappings to get too close to heap and stack. This
was mainly a problem on 32-bit, but the 64-bit bases were moved too,
in an effort to proactively protect those systems (proofs of concept
do exist that show 64-bit collisions, but other recent changes to fix
stack accounting and setuid behaviors will minimize the impact).

The new 32-bit PIE base is fine for ASan (since it matches the ET_EXEC
base), so only the 64-bit PIE base needs to be reverted to let x86 and
arm64 ASan binaries run again. Future changes to the 64-bit PIE base on
these architectures can be made optional once a more dynamic method for
dealing with AddressSanitizer is found. (e.g. always loading PIE into
the mmap region for marked binaries.)

Reported-by: Kostya Serebryany <kcc@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name mm-revert-x86_64-and-arm64-elf_et_dyn_base-base.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

Revert "gpu: host1x: Add IOMMU support"

This reverts commit 404bfb78daf3bedafb0bfab24947059575cbea3d, which
resulted in a build failure:

drivers/gpu/host1x/cdma.c: In function 'host1x_pushbuffer_init':
drivers/gpu/host1x/cdma.c:94:48: error: passing argument 3 of 'dma_alloc_wc' from incompatible pointer type [-Werror=incompatible-pointer-types]
   pb->mapped = dma_alloc_wc(host1x->dev, size, &pb->phys,
                                                ^
In file included from drivers/gpu/host1x/cdma.c:22:0:
include/linux/dma-mapping.h:773:21: note: expected 'dma_addr_t * {aka long long unsigned int *}' but argument is of type 'phys_addr_t * {aka unsigned int *}'
 static inline void *dma_alloc_wc(struct device *dev, size_t size,
                     ^~~~~~~~~~~~

This code is mixing up dma_addr_t and phys_addr_t, and this looks had
to avoid when combining the two address mapping APIs.  But with XEN
enabled and ARM_LPAE not enabled, as in the armmp config, dma_addr_t
is 64-bit while phys_addr_t is 32-bit.

Gbp-Pq: Topic debian
Gbp-Pq: Name revert-gpu-host1x-add-iommu-support.patch

MIPS: Octeon: Fix broken EDAC driver.

Fixes: 15f6847923a8 ("MIPS: Octeon: Remove unused L2C types and
macros.")

Signed-off-by: Steven J. Hill <steven.hill@cavium.com>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Gbp-Pq: Topic bugfix/mips
Gbp-Pq: Name mips-octeon-fix-broken-edac-driver.patch

platform/x86: ideapad-laptop: Add several models to no_hw_rfkill

Some Lenovo ideapad models do not have hardware rfkill switches, but
trying to read the rfkill switches through the ideapad-laptop module.
It caused to always reported blocking breaking wifi.

Fix it by adding those models to no_hw_rfkill_list.

Signed-off-by: Yang Jiaxun <yjx@flygoat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-several-models-to-no.patch

platform/x86: ideapad-laptop: Add IdeaPad V510-15IKB to no_hw_rfkill

Like other Lenovo models the IdeaPad V510-15IKB does not have an hw
rfkill switch. This results in hard-blocked radios after boot, resulting
in always blocked radios rendering them unusable.

Add the IdeaPad V510-15IKB to the no_hw_rfkill DMI list and allows using
the built-in radios.

Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-ideapad-v510-15ikb-t.patch

platform/x86: ideapad-laptop: Add Y720-15IKBN to no_hw_rfkill

Lenovo Legion Y720-15IKBN is yet another Lenovo model that does not
have an hw rfkill switch, resulting in wifi always reported as hard
blocked.

Add the model to the list of models without rfkill switch.

Signed-off-by: Olle Liljenzin <olle@liljenzin.se>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-y720-15ikbn-to-no_hw.patch

platform/x86: ideapad-laptop: Add Y520-15IKBN to no_hw_rfkill

Lenovo Legion Y520-15IKBN is yet another Lenovo model that does not
have an hw rfkill switch, resulting in wifi always reported as hard
blocked.

Add the model to the list of models without rfkill switch.

Signed-off-by: Olle Liljenzin <olle@liljenzin.se>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-y520-15ikbn-to-no_hw.patch

platform/x86: ideapad-laptop: Add IdeaPad V310-15ISK to no_hw_rfkill

Like other Lenovo models the IdeaPad V310-15ISK does not have an hw
rfkill switch. This results in hard-blocked radios after boot, resulting
in always blocked radios rendering them unusable.

Add the IdeaPad V310-15ISK to the no_hw_rfkill DMI list and allows using
the built-in radios.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-ideapad-v310-15isk-t.patch

platform/x86: ideapad-laptop: Add IdeaPad 310-15IKB to no_hw_rfkill

Like other Lenovo models the IdeaPad 310-15IKB does not have an hw rfkill
switch. This results in hard-blocked radios after boot, resulting in
always blocked radios rendering them unusable.

Add the IdeaPad 310-15IKB to the no_hw_rfkill DMI list and allows using
the built-in radios.

Signed-off-by: Sven Rebhan <Sven.Rebhan@googlemail.com>
[andy: massaged commit message]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-ideapad-310-15ikb-to.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

Don't WARN about expected W+X pages on Xen

Currently Xen PV domains (or at least dom0) on amd64 tend to have a
large number of low kernel pages with W+X permissions.  It's not
obvious how to fix this, and we're not going to get any new
information by WARNing about this, but we do still want to hear about
other W+X cases.  So add a condition to the WARN_ON.

Gbp-Pq: Topic debian
Gbp-Pq: Name amd64-don-t-warn-about-expected-w+x-pages-on-xen.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

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

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

aufs4.11.7+ standalone patch

Patch headers added by debian/patches/features/all/aufs4/gen-patch

aufs4.11.7+ standalone patch

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

aufs4.11.7+ mmap patch

Patch headers added by debian/patches/features/all/aufs4/gen-patch

aufs4.11.7+ mmap patch

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

aufs4.11.7+ base patch

Patch headers added by debian/patches/features/all/aufs4/gen-patch

aufs4.11.7+ base patch

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

radeon: 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 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-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

Install perf scripts non-executable

[bwh: Forward-ported to 3.12]

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

modpost symbol prefix setting

[bwh: The original version of this was added by Bastian Blank.  The
upstream code includes <generated/autoconf.h> so that <linux/export.h>
can tell whether C symbols have an underscore prefix.  Since we build
modpost separately from the kernel, <generated/autoconf.h> won't exist.
However, no Debian Linux architecture uses the symbol prefix, so we
can simply omit it.]

Gbp-Pq: Topic debian
Gbp-Pq: Name modpost-symbol-prefix.patch