bcm: Make RASPBERRYPI_POWER depend on PM

reboot: Use power off rather than busy spinning when halt is requested

watchdog: bcm2835: Support setting reboot partition

The Raspberry Pi firmware looks at the RSTS register to know which
partition to boot from. The reboot syscall command
LINUX_REBOOT_CMD_RESTART2 supports passing in a string argument.

Add support for passing in a partition number 0..63 to boot from.
Partition 63 is a special partiton indicating halt.
If the partition doesn't exist, the firmware falls back to partition 0.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>

rtc: Add SPI alias for pcf2123 driver

Without this alias, Device Tree won't cause the driver
to be loaded.

See: https://github.com/raspberrypi/linux/pull/1510

clk: bcm2835: Mark GPIO clocks enabled at boot as critical.

These divide off of PLLD_PER and are used for the ethernet and wifi
PHYs source PLLs.  Neither of them is currently represented by a phy
device that would grab the clock for us.

This keeps other drivers from killing the networking PHYs when they
disable their own clocks and trigger PLLD_PER's refcount going to 0.

v2: Skip marking as critical if they aren't on at boot.

Signed-off-by: Eric Anholt <eric@anholt.net>

firmware: Updated mailbox header

dmaengine: bcm2835: Load driver early and support legacy API

Load driver early since at least bcm2708_fb doesn't support deferred
probing and even if it did, we don't want the video driver deferred.
Support the legacy DMA API which is needed by bcm2708_fb.
Don't mask out channel 2.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>

ARM: bcm2835: Set Serial number and Revision

The VideoCore bootloader passes in Serial number and
Revision number through Device Tree. Make these available to
userspace through /proc/cpuinfo.

Mainline status:

There is a commit in linux-next that standardize passing the serial
number through Device Tree (string: /serial-number):
ARM: 8355/1: arch: Show the serial number from devicetree in cpuinfo

There was an attempt to do the same with the revision number, but it
didn't get in:
[PATCH v2 1/2] arm: devtree: Set system_rev from DT revision

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>

spi-bcm2835: Remove unused code

spi-bcm2835: Disable forced software CS

Select software CS in bcm2708_common.dtsi, and disable the automatic
conversion in the driver to allow hardware CS to be re-enabled with an
overlay.

See: https://github.com/raspberrypi/linux/issues/1547

Signed-off-by: Phil Elwell <phil@raspberrypi.org>

spi-bcm2835: Support pin groups other than 7-11

The spi-bcm2835 driver automatically uses GPIO chip-selects due to
some unreliability of the native ones. In doing so it chooses the
same pins as the native chip-selects would use, but the existing
code always uses pins 7 and 8, wherever the SPI function is mapped.

Search the pinctrl group assigned to the driver for pins that
correspond to native chip-selects, and use those for GPIO chip-
selects.

Signed-off-by: Phil Elwell <phil@raspberrypi.org>

pinctrl-bcm2835: Return pins to inputs when freed

When dynamically unloading overlays, it is important that freed pins are
restored to being inputs to prevent functions from being enabled in
multiple places at once.

Signed-off-by: Phil Elwell <phil@raspberrypi.org>

pinctrl-bcm2835: Only request the interrupts listed in the DTB

Although the GPIO controller can generate three interrupts (four counting
the common one), the device tree files currently only specify two. In the
absence of the third, simply don't register that interrupt (as opposed to
registering 0), which has the effect of making it impossible to generate
interrupts for GPIOs 46-53 which, since they share pins with the SD card
interface, is unlikely to be a problem.

pinctrl-bcm2835: Fix interrupt handling for GPIOs 28-31 and 46-53

Contrary to the documentation, the BCM2835 GPIO controller actually has
four interrupt lines - one each for the three IRQ groups and one common. Rather
confusingly, the GPIO interrupt groups don't correspond directly with the GPIO
control banks. Instead, GPIOs 0-27 generate IRQ GPIO0, 28-45 GPIO1 and
46-53 GPIO2.

Awkwardly, the GPIOS for IRQ GPIO1 straddle two 32-entry GPIO banks, so it is
cleaner to split out a function to process the interrupts for a single GPIO
bank.

This bug has only just been observed because GPIOs above 27 can only be
accessed on an old Raspberry Pi with the optional P5 header fitted, where
the pins are often used for I2S instead.

pinctrl-bcm2835: Set base to 0 give expected gpio numbering

Signed-off-by: Noralf Tronnes <notro@tronnes.org>

serial: 8250: Don't crash when nr_uarts is 0

spidev: Add "spidev" compatible string to silence warning

See: https://github.com/raspberrypi/linux/issues/1054

irqchip: irq-bcm2835: Add 2836 FIQ support

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>

irqchip: bcm2835: Add FIQ support

Add a duplicate irq range with an offset on the hwirq's so the
driver can detect that enable_fiq() is used.
Tested with downstream dwc_otg USB controller driver.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>

irq-bcm2836: Prevent spurious interrupts, and trap them early

The old arch-specific IRQ macros included a dsb to ensure the
write to clear the mailbox interrupt completed before returning
from the interrupt. The BCM2836 irqchip driver needs the same
precaution to avoid spurious interrupts.

Spurious interrupts are still possible for other reasons,
though, so trap them early.

mm: Remove the PFN busy warning

See commit dae803e165a11bc88ca8dbc07a11077caf97bbcb -- the warning is
expected sometimes when using CMA.  However, that commit still spams
my kernel log with these warnings.

Signed-off-by: Eric Anholt <eric@anholt.net>

Protect __release_resource against resources without parents

Without this patch, removing a device tree overlay can crash here.

Signed-off-by: Phil Elwell <phil@raspberrypi.org>

Allow mac address to be set in smsc95xx

Signed-off-by: popcornmix <popcornmix@gmail.com>

smsc95xx: Experimental: Enable turbo_mode and packetsize=2560 by default

See: http://forum.kodi.tv/showthread.php?tid=285288

smsx95xx: fix crimes against truesize

smsc95xx is adjusting truesize when it shouldn't, and following a recent patch from Eric this is now triggering warnings.

This patch stops smsc95xx from changing truesize.

Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>

psudedomerge to tie in upstream history

remove some debian patches that conflict with rpi stuff

Merge packaging changes from 4.9.13-1+rpi3 into 4.9.30-2+deb9u2 to produce packaging for 4.9.30-2+deb9u2+rpi1

extract packaging changes from 4.9.13-1+rpi3 (5ad499885f6dc06a4eef5e2efbfd8504f53a2672)

extract packaging changes from 4.9.13-1+rpi2 (9aee96815fc5c5377349f1d0ef34370c38e967d4)

extract packaging changes from 4.9.13-1+rpi1 (e44c49f0c0476e5cb2b66c966302cba5b2748fd5)

Merge linux (4.9.30-2+deb9u2) import into refs/heads/workingbranch

liblockdep: Fix 'defined but not used' warning for init_utsname()

We define init_utsname() as static but not inline, resulting
in a warning for every source file that includes lockdep.h but
doesn't call it.

Since it is only used by lockdep.c, define it in there.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name liblockdep-fix-defined-but-not-used-warning-for-init.patch

liblockdep: Fix 'set but not used' warnings

liblockdep defines trivial macros for working with interrupt flags, as
interrupts are never disabled in userland.  This results in warnings
from gcc when -Wunused-but-set-variable is enabled, and it is enabled
by -Wall.  Fix this by evaluating the flags parameter and casting it to
void.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name liblockdep-fix-set-but-not-used-warnings.patch

liblockdep: Fix 'unused value' warnings

liblockdep defines various macros that may expand to an expression
with no effect, while the in-kernel definition does have an effect.
This results in warnings from gcc when -Wunused-value is enabled, and
is is enabled by -Wall.  Fix this by introducing trivial functions,
as function return values are generally allowed to be ignored.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name liblockdep-fix-unused-value-warnings.patch

liblockdep: Enable -Wall by default

Regressions in liblockdep may be missed because it doesn't enable
warnings.

Adding -Wall immediately introduces a lot of warnings, but those will
be fixed by the following commits.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name liblockdep-enable-wall-by-default.patch

liblockdep: Define the ARRAY_SIZE() macro

lockdep.c now uses ARRAY_SIZE().

Fixes: 75dd602a5198 ("lockdep: Fix lock_chain::base size")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name liblockdep-define-the-array_size-macro.patch

liblockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain::depth

liblockdep has been broken since commit 75dd602a5198 ("lockdep: Fix
lock_chain::base size"), as that adds a check that MAX_LOCK_DEPTH is
within the range of lock_chain::depth and in liblockdep it is much
too large.

That should have resulted in a compiler error, but didn't because:

- the check uses ARRAY_SIZE(), which isn't yet defined in liblockdep
  so is assumed to be an (undeclared) function
- putting a function call inside a BUILD_BUG_ON() expression quietly
  turns it into some nonsense involving a variable-length array

It did produce a compiler warning, but I didn't notice because
liblockdep already produces too many warnings if -Wall is enabled
(which I'll fix shortly).

Even before that commit, which reduced lock_chain::depth from 8 bits
to 6, MAX_LOCK_DEPTH was too large.

Cc: <stable@vger.kernel.org> # for versions before 4.6, use a value of 255
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name liblockdep-reduce-max_lock_depth-to-avoid-overflowin.patch

liblockdep: Fix undefined symbol prandom_u32

__lock_pin_lock() now calls prandom_u32() which is not defined in
liblockdep.  __lock_pin_lock() and its caller lock_pin_lock() are dead
code in liblockdep, but we still need to provide a definition of
prandom_u32() in case lazy binding is disabled.

Fixes: e7904a28f533 ("locking/lockdep, sched/core: Implement a better ...")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name liblockdep-fix-undefined-symbol-prandom_u32.patch

cpupower: Fix checks for CPU existence

Calls to cpufreq_cpu_exists(cpu) were converted to
cpupower_is_cpu_online(cpu) when libcpupower was introduced and the
former function was deleted.  However, cpupower_is_cpu_online()
returns 1 on success whereas cpufreq_cpu_exists() returned 0 on
success.  It also does not distinguish physically absent and offline
CPUs, and does not set errno.

cpufreq-set has already been fixed (commit c25badc9ceb6).

In cpufreq-bench, which prints an error message for offline CPUs,
properly distinguish and report the zero and negative cases.

Fixes: ac5a181d065d ("cpupower: Add cpuidle parts into library")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name cpupower-fix-checks-for-cpu-existence.patch

cpupower: Bump soname version

Several functions in the libcpupower API are renamed or removed in
Linux 4.7.  This is an backward-incompatible ABI change, so the
library soname should change from libcpupower.so.0 to
libcpupower.so.1.

Fixes: ac5a181d065d ("cpupower: Add cpuidle parts into library")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name cpupower-bump-soname-version.patch

tools lib traceevent: Fix use of uninitialized variables

Fix a number of correct warnings from gcc:

> plugin_function.c:133:6: warning: 'index' may be used uninitialized in this function [-Wmaybe-uninitialized]
>   int index;
>       ^

'index' is initialized only if indentation is wanted.  Move the
printing of indentation using 'index' into the same if-statement.

> kbuffer-parse.c:339:27: warning: 'length' may be used uninitialized in this function [-Wmaybe-uninitialized]
>   kbuf->next = kbuf->index + length;
>                            ^
> kbuffer-parse.c:297:15: note: 'length' was declared here
>   unsigned int length;
>                ^

'length' is not initialized when handling an OLD_RINGBUF_TYPE_TIME_EXTEND
record.  Based on what trace-cmd does, set length = 0 in this case.

> kbuffer-parse.c: In function 'kbuffer_read_at_offset':
> kbuffer-parse.c:632:9: warning: 'data' may be used uninitialized in this function [-Wmaybe-uninitialized]
>   return data;
>          ^

'data' is not initialized if the offset is too small.  Initialize it
to NULL so that the behaviour is the same as when the offset is too
large.

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

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

Also fix the test for whether __NR_bpf is defined.

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/hv: Fix fortify format warning

With fortify enabled, gcc warns:

tools/hv/hv_kvp_daemon.c:705:2: error: format not a string literal and no format arguments [-Werror=format-security]
  snprintf(dev_id, sizeof(dev_id), kvp_net_dir);
  ^

kvp_net_dir is a pointer to a string literal, but lacks const
qualification.  As it is never modified, it should be a const
array rather than a pointer.

Also, while snprintf() has a bounds check, the following strcat()s
do not.  Combine them into a single snprintf().

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name tools-hv-fix-fortify-format-warning.patch

tools/lib/lockdep: Use LDFLAGS

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name tools-lib-lockdep-use-ldflags.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

liblockdep: Remove double-quotes from soname

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name lockdep-fix-soname.patch

liblockdep: Fix object file paths used in an out-of-tree build

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name lockdep-fix-oot-build.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

Revert "MIPS: Loongson-3: Select MIPS_L1_CACHE_SHIFT_6"

This reverts commit 07d8aabff4903065bb472df9b040b8688fdc75a2 which was
commit 17c99d9421695a0e0de18bf1e7091d859e20ec1d upstream.  This
changed L1_CACHE_SHIFT which is used for structure alignment in many
places, thus would break ABI.

Gbp-Pq: Topic debian
Gbp-Pq: Name revert-mips-loongson-3-select-mips_l1_cache_shift_6.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

powerpc: Fix missing CRCs, add yet more asm-prototypes.h declarations

Add declarations for:
- __mfdcr, __mtdcr (if CONFIG_PPC_DCR_NATIVE=y; through <asm/dcr.h>)
- switch_mmu_context (if CONFIG_PPC_BOOK3S_64=n; through <asm/mmu_context.h>)

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/powerpc
Gbp-Pq: Name powerpc-fix-missing-crcs-add-yet-more-asm-prototypes.patch

powerpc: Remove Mac-on-Linux hooks

The symbols exported for use by MOL aren't getting CRCs and I was
about to fix that.  But MOL is dead upstream, and the latest work on
it was to make it use KVM instead of its own kernel module.  So remove
them instead.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/powerpc
Gbp-Pq: Name powerpc-remove-mac-on-linux-hooks.patch

Revert "alpha: move exports to actual definitions"

This reverts commit 00fc0e0dda6286407f3854cd71a125f519a5689c because
symbols exported from assembly don't automatically get modversions (ABI
hashes).

Gbp-Pq: Topic bugfix/alpha
Gbp-Pq: Name revert-alpha-move-exports-to-actual-definitions.patch

Revert "m68k: move exports to definitions"

This reverts commit d13ffb5630443e6112df0263969cbdfc8ab9ab57 because
symbols exported from assembly don't automatically get modversions (ABI
hashes).

Gbp-Pq: Topic bugfix/m68k
Gbp-Pq: Name revert-m68k-move-exports-to-definitions.patch

Revert "s390: move exports to definitions"

This reverts commit 711f5df7bf3ae7657e15edf76d671042c051ce95 because
symbols exported from assembly don't automatically get modversions (ABI
hashes).

Gbp-Pq: Topic bugfix/s390
Gbp-Pq: Name revert-s390-move-exports-to-definitions.patch

Revert "sparc: move exports to definitions"

This reverts commit d3867f0483103b8ff7edfdea3ef1981c03d96891 because
symbols exported from assembly don't automatically get modversions (ABI
hashes).

Commit 70a6fcf3283a "[sparc] unify 32bit and 64bit string.h" removed
the export of __memmove; don't try to export it again.  It also
completely disabled declaration of prototypes of memscan, memcpy and
memset, which are defined as macros.  gcc will still generate implicit
calls to memcpy and memset, so restore both exports and prototypes for
them.  Don't restore the export of memscan.

Commit aa95ce361ed9 "sparc64: Delete __ret_efault." did what it says;
don't try to export that symbol.

Gbp-Pq: Topic bugfix/sparc
Gbp-Pq: Name revert-sparc-move-exports-to-definitions.patch

Revert "ia64: move exports to definitions"

This reverts commit e007c53397acb5554e226693e3bff54a312ccd96 because
symbols exported from assembly don't automatically get modversions (ABI
hashes).

Gbp-Pq: Topic bugfix/ia64
Gbp-Pq: Name revert-ia64-move-exports-to-definitions.patch

mm: fix new crash in unmapped_area_topdown()

Trinity gets kernel BUG at mm/mmap.c:1963! in about 3 minutes of
mmap testing.  That's the VM_BUG_ON(gap_end < gap_start) at the
end of unmapped_area_topdown().  Linus points out how MAP_FIXED
(which does not have to respect our stack guard gap intentions)
could result in gap_end below gap_start there.  Fix that, and
the similar case in its alternative, unmapped_area().

Cc: stable@vger.kernel.org
Fixes: 1be7107fbe18 ("mm: larger stack guard gap, between vmas")
Reported-by: Dave Jones <davej@codemonkey.org.uk>
Debugged-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name mm-fix-new-crash-in-unmapped_area_topdown.patch

mm: larger stack guard gap, between vmas

commit 1be7107fbe18eed3e319a6c3e83c78254b693acb upstream.

Stack guard page is a useful feature to reduce a risk of stack smashing
into a different mapping. We have been using a single page gap which
is sufficient to prevent having stack adjacent to a different mapping.
But this seems to be insufficient in the light of the stack usage in
userspace. E.g. glibc uses as large as 64kB alloca() in many commonly
used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX]
which is 256kB or stack strings with MAX_ARG_STRLEN.

This will become especially dangerous for suid binaries and the default
no limit for the stack size limit because those applications can be
tricked to consume a large portion of the stack and a single glibc call
could jump over the guard page. These attacks are not theoretical,
unfortunatelly.

Make those attacks less probable by increasing the stack guard gap
to 1MB (on systems with 4k pages; but make it depend on the page size
because systems with larger base pages might cap stack allocations in
the PAGE_SIZE units) which should cover larger alloca() and VLA stack
allocations. It is obviously not a full fix because the problem is
somehow inherent, but it should reduce attack space a lot.

One could argue that the gap size should be configurable from userspace,
but that can be done later when somebody finds that the new 1MB is wrong
for some special case applications.  For now, add a kernel command line
option (stack_guard_gap) to specify the stack gap size (in page units).

Implementation wise, first delete all the old code for stack guard page:
because although we could get away with accounting one extra page in a
stack vma, accounting a larger gap can break userspace - case in point,
a program run with "ulimit -S -v 20000" failed when the 1MB gap was
counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK
and strict non-overcommit mode.

Instead of keeping gap inside the stack vma, maintain the stack guard
gap as a gap between vmas: using vm_start_gap() in place of vm_start
(or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few
places which need to respect the gap - mainly arch_get_unmapped_area(),
and and the vma tree's subtree_gap support for that.

Original-patch-by: Oleg Nesterov <oleg@redhat.com>
Original-patch-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Tested-by: Helge Deller <deller@gmx.de> # parisc
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[wt: backport to 4.11: adjust context]
[wt: backport to 4.9: adjust context ; kernel doc was not in admin-guide]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name mm-larger-stack-guard-gap-between-vmas.patch

ipv6: fix out of bound writes in __ip6_append_data()

Andrey Konovalov and idaifish@gmail.com reported crashes caused by
one skb shared_info being overwritten from __ip6_append_data()

Andrey program lead to following state :

copy -4200 datalen 2000 fraglen 2040
maxfraglen 2040 alloclen 2048 transhdrlen 0 offset 0 fraggap 6200

The skb_copy_and_csum_bits(skb_prev, maxfraglen, data + transhdrlen,
fraggap, 0); is overwriting skb->head and skb_shared_info

Since we apparently detect this rare condition too late, move the
code earlier to even avoid allocating skb and risking crashes.

Once again, many thanks to Andrey and syzkaller team.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Reported-by: <idaifish@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name ipv6-fix-out-of-bound-writes-in-__ip6_append_data.patch

crypto: skcipher - Add missing API setkey checks

The API setkey checks for key sizes and alignment went AWOL during the
skcipher conversion.  This patch restores them.

Cc: <stable@vger.kernel.org>
Fixes: 4e6c3df4d729 ("crypto: skcipher - Add low-level skcipher...")
Reported-by: Baozeng <sploving1@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name crypto-skcipher-Add-missing-api-setkey-checks.patch

ipv6/dccp: do not inherit ipv6_mc_list from parent

Like commit 657831ffc38e ("dccp/tcp: do not inherit mc_list from parent")
we should clear ipv6_mc_list etc. for IPv6 sockets too.

Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name ipv6-dccp-do-not-inherit-ipv6_mc_list-from-parent.patch

sctp: do not inherit ipv6_{mc|ac|fl}_list from parent

SCTP needs fixes similar to 83eaddab4378 ("ipv6/dccp: do not inherit
ipv6_mc_list from parent"), otherwise bad things can happen.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name sctp-do-not-inherit-ipv6_-mc-ac-fl-_list-from-parent.patch

ipv6: Fix leak in ipv6_gso_segment().

If ip6_find_1stfragopt() fails and we return an error we have to free
up 'segs' because nobody else is going to.

Fixes: 2423496af35d ("ipv6: Prevent overrun when parsing v6 header options")
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name ipv6-fix-leak-in-ipv6_gso_segment.patch

ipv6: xfrm: Handle errors reported by xfrm6_find_1stfragopt()

xfrm6_find_1stfragopt() may now return an error code and we must
not treat it as a length.

Fixes: 2423496af35d ("ipv6: Prevent overrun when parsing v6 header options")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Acked-by: Craig Gallek <kraig@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name ipv6-xfrm-handle-errors-reported-by-xfrm6_find_1stfr.patch

ipv6: Check ip6_find_1stfragopt() return value properly.

Do not use unsigned variables to see if it returns a negative
error or not.

Fixes: 2423496af35d ("ipv6: Prevent overrun when parsing v6 header options")
Reported-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name ipv6-check-ip6_find_1stfragopt-return-value-properly.patch

ipv6: Prevent overrun when parsing v6 header options

The KASAN warning repoted below was discovered with a syzkaller
program.  The reproducer is basically:
  int s = socket(AF_INET6, SOCK_RAW, NEXTHDR_HOP);
  send(s, &one_byte_of_data, 1, MSG_MORE);
  send(s, &more_than_mtu_bytes_data, 2000, 0);

The socket() call sets the nexthdr field of the v6 header to
NEXTHDR_HOP, the first send call primes the payload with a non zero
byte of data, and the second send call triggers the fragmentation path.

The fragmentation code tries to parse the header options in order
to figure out where to insert the fragment option.  Since nexthdr points
to an invalid option, the calculation of the size of the network header
can made to be much larger than the linear section of the skb and data
is read outside of it.

This fix makes ip6_find_1stfrag return an error if it detects
running out-of-bounds.

[   42.361487] ==================================================================
[   42.364412] BUG: KASAN: slab-out-of-bounds in ip6_fragment+0x11c8/0x3730
[   42.365471] Read of size 840 at addr ffff88000969e798 by task ip6_fragment-oo/3789
[   42.366469]
[   42.366696] CPU: 1 PID: 3789 Comm: ip6_fragment-oo Not tainted 4.11.0+ #41
[   42.367628] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1ubuntu1 04/01/2014
[   42.368824] Call Trace:
[   42.369183]  dump_stack+0xb3/0x10b
[   42.369664]  print_address_description+0x73/0x290
[   42.370325]  kasan_report+0x252/0x370
[   42.370839]  ? ip6_fragment+0x11c8/0x3730
[   42.371396]  check_memory_region+0x13c/0x1a0
[   42.371978]  memcpy+0x23/0x50
[   42.372395]  ip6_fragment+0x11c8/0x3730
[   42.372920]  ? nf_ct_expect_unregister_notifier+0x110/0x110
[   42.373681]  ? ip6_copy_metadata+0x7f0/0x7f0
[   42.374263]  ? ip6_forward+0x2e30/0x2e30
[   42.374803]  ip6_finish_output+0x584/0x990
[   42.375350]  ip6_output+0x1b7/0x690
[   42.375836]  ? ip6_finish_output+0x990/0x990
[   42.376411]  ? ip6_fragment+0x3730/0x3730
[   42.376968]  ip6_local_out+0x95/0x160
[   42.377471]  ip6_send_skb+0xa1/0x330
[   42.377969]  ip6_push_pending_frames+0xb3/0xe0
[   42.378589]  rawv6_sendmsg+0x2051/0x2db0
[   42.379129]  ? rawv6_bind+0x8b0/0x8b0
[   42.379633]  ? _copy_from_user+0x84/0xe0
[   42.380193]  ? debug_check_no_locks_freed+0x290/0x290
[   42.380878]  ? ___sys_sendmsg+0x162/0x930
[   42.381427]  ? rcu_read_lock_sched_held+0xa3/0x120
[   42.382074]  ? sock_has_perm+0x1f6/0x290
[   42.382614]  ? ___sys_sendmsg+0x167/0x930
[   42.383173]  ? lock_downgrade+0x660/0x660
[   42.383727]  inet_sendmsg+0x123/0x500
[   42.384226]  ? inet_sendmsg+0x123/0x500
[   42.384748]  ? inet_recvmsg+0x540/0x540
[   42.385263]  sock_sendmsg+0xca/0x110
[   42.385758]  SYSC_sendto+0x217/0x380
[   42.386249]  ? SYSC_connect+0x310/0x310
[   42.386783]  ? __might_fault+0x110/0x1d0
[   42.387324]  ? lock_downgrade+0x660/0x660
[   42.387880]  ? __fget_light+0xa1/0x1f0
[   42.388403]  ? __fdget+0x18/0x20
[   42.388851]  ? sock_common_setsockopt+0x95/0xd0
[   42.389472]  ? SyS_setsockopt+0x17f/0x260
[   42.390021]  ? entry_SYSCALL_64_fastpath+0x5/0xbe
[   42.390650]  SyS_sendto+0x40/0x50
[   42.391103]  entry_SYSCALL_64_fastpath+0x1f/0xbe
[   42.391731] RIP: 0033:0x7fbbb711e383
[   42.392217] RSP: 002b:00007ffff4d34f28 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
[   42.393235] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fbbb711e383
[   42.394195] RDX: 0000000000001000 RSI: 00007ffff4d34f60 RDI: 0000000000000003
[   42.395145] RBP: 0000000000000046 R08: 00007ffff4d34f40 R09: 0000000000000018
[   42.396056] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000400aad
[   42.396598] R13: 0000000000000066 R14: 00007ffff4d34ee0 R15: 00007fbbb717af00
[   42.397257]
[   42.397411] Allocated by task 3789:
[   42.397702]  save_stack_trace+0x16/0x20
[   42.398005]  save_stack+0x46/0xd0
[   42.398267]  kasan_kmalloc+0xad/0xe0
[   42.398548]  kasan_slab_alloc+0x12/0x20
[   42.398848]  __kmalloc_node_track_caller+0xcb/0x380
[   42.399224]  __kmalloc_reserve.isra.32+0x41/0xe0
[   42.399654]  __alloc_skb+0xf8/0x580
[   42.400003]  sock_wmalloc+0xab/0xf0
[   42.400346]  __ip6_append_data.isra.41+0x2472/0x33d0
[   42.400813]  ip6_append_data+0x1a8/0x2f0
[   42.401122]  rawv6_sendmsg+0x11ee/0x2db0
[   42.401505]  inet_sendmsg+0x123/0x500
[   42.401860]  sock_sendmsg+0xca/0x110
[   42.402209]  ___sys_sendmsg+0x7cb/0x930
[   42.402582]  __sys_sendmsg+0xd9/0x190
[   42.402941]  SyS_sendmsg+0x2d/0x50
[   42.403273]  entry_SYSCALL_64_fastpath+0x1f/0xbe
[   42.403718]
[   42.403871] Freed by task 1794:
[   42.404146]  save_stack_trace+0x16/0x20
[   42.404515]  save_stack+0x46/0xd0
[   42.404827]  kasan_slab_free+0x72/0xc0
[   42.405167]  kfree+0xe8/0x2b0
[   42.405462]  skb_free_head+0x74/0xb0
[   42.405806]  skb_release_data+0x30e/0x3a0
[   42.406198]  skb_release_all+0x4a/0x60
[   42.406563]  consume_skb+0x113/0x2e0
[   42.406910]  skb_free_datagram+0x1a/0xe0
[   42.407288]  netlink_recvmsg+0x60d/0xe40
[   42.407667]  sock_recvmsg+0xd7/0x110
[   42.408022]  ___sys_recvmsg+0x25c/0x580
[   42.408395]  __sys_recvmsg+0xd6/0x190
[   42.408753]  SyS_recvmsg+0x2d/0x50
[   42.409086]  entry_SYSCALL_64_fastpath+0x1f/0xbe
[   42.409513]
[   42.409665] The buggy address belongs to the object at ffff88000969e780
[   42.409665]  which belongs to the cache kmalloc-512 of size 512
[   42.410846] The buggy address is located 24 bytes inside of
[   42.410846]  512-byte region [ffff88000969e780, ffff88000969e980)
[   42.411941] The buggy address belongs to the page:
[   42.412405] page:ffffea000025a780 count:1 mapcount:0 mapping:          (null) index:0x0 compound_mapcount: 0
[   42.413298] flags: 0x100000000008100(slab|head)
[   42.413729] raw: 0100000000008100 0000000000000000 0000000000000000 00000001800c000c
[   42.414387] raw: ffffea00002a9500 0000000900000007 ffff88000c401280 0000000000000000
[   42.415074] page dumped because: kasan: bad access detected
[   42.415604]
[   42.415757] Memory state around the buggy address:
[   42.416222]  ffff88000969e880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   42.416904]  ffff88000969e900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   42.417591] >ffff88000969e980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   42.418273]                    ^
[   42.418588]  ffff88000969ea00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[   42.419273]  ffff88000969ea80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[   42.419882] ==================================================================

Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Craig Gallek <kraig@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name ipv6-prevent-overrun-when-parsing-v6-header-options.patch

NFSv4.x/callback: Create the callback service through svc_create_pooled

As the comments for svc_set_num_threads() said,
" Destroying threads relies on the service threads filling in
rqstp->rq_task, which only the nfs ones do.  Assumes the serv
has been created using svc_create_pooled()."

If creating service through svc_create(), the svc_pool_map_put()
will be called in svc_destroy(), but the pool map isn't used.
So that, the reference of pool map will be drop, the next using
of pool map will get a zero npools.

[  137.992130] divide error: 0000 [#1] SMP
[  137.992148] Modules linked in: nfsd(E) nfsv4 nfs fscache fuse tun bridge stp llc ip_set nfnetlink vmw_vsock_vmci_transport vsock snd_seq_midi snd_seq_midi_event vmw_balloon coretemp crct10dif_pclmul crc32_pclmul ppdev ghash_clmulni_intel intel_rapl_perf joydev snd_ens1371 gameport snd_ac97_codec ac97_bus snd_seq snd_pcm snd_rawmidi snd_timer snd_seq_device snd soundcore parport_pc parport nfit acpi_cpufreq tpm_tis tpm_tis_core tpm vmw_vmci i2c_piix4 shpchp auth_rpcgss nfs_acl lockd(E) grace sunrpc(E) xfs libcrc32c vmwgfx drm_kms_helper ttm crc32c_intel drm e1000 mptspi scsi_transport_spi serio_raw mptscsih mptbase ata_generic pata_acpi [last unloaded: nfsd]
[  137.992336] CPU: 0 PID: 4514 Comm: rpc.nfsd Tainted: G            E   4.11.0-rc8+ #536
[  137.992777] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015
[  137.993757] task: ffff955984101d00 task.stack: ffff9873c2604000
[  137.994231] RIP: 0010:svc_pool_for_cpu+0x2b/0x80 [sunrpc]
[  137.994768] RSP: 0018:ffff9873c2607c18 EFLAGS: 00010246
[  137.995227] RAX: 0000000000000000 RBX: ffff95598376f000 RCX: 0000000000000002
[  137.995673] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9559944aec00
[  137.996156] RBP: ffff9873c2607c18 R08: ffff9559944aec28 R09: 0000000000000000
[  137.996609] R10: 0000000001080002 R11: 0000000000000000 R12: ffff95598376f010
[  137.997063] R13: ffff95598376f018 R14: ffff9559944aec28 R15: ffff9559944aec00
[  137.997584] FS:  00007f755529eb40(0000) GS:ffff9559bb600000(0000) knlGS:0000000000000000
[  137.998048] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  137.998548] CR2: 000055f3aecd9660 CR3: 0000000084290000 CR4: 00000000001406f0
[  137.999052] Call Trace:
[  137.999517]  svc_xprt_do_enqueue+0xef/0x260 [sunrpc]
[  138.000028]  svc_xprt_received+0x47/0x90 [sunrpc]
[  138.000487]  svc_add_new_perm_xprt+0x76/0x90 [sunrpc]
[  138.000981]  svc_addsock+0x14b/0x200 [sunrpc]
[  138.001424]  ? recalc_sigpending+0x1b/0x50
[  138.001860]  ? __getnstimeofday64+0x41/0xd0
[  138.002346]  ? do_gettimeofday+0x29/0x90
[  138.002779]  write_ports+0x255/0x2c0 [nfsd]
[  138.003202]  ? _copy_from_user+0x4e/0x80
[  138.003676]  ? write_recoverydir+0x100/0x100 [nfsd]
[  138.004098]  nfsctl_transaction_write+0x48/0x80 [nfsd]
[  138.004544]  __vfs_write+0x37/0x160
[  138.004982]  ? selinux_file_permission+0xd7/0x110
[  138.005401]  ? security_file_permission+0x3b/0xc0
[  138.005865]  vfs_write+0xb5/0x1a0
[  138.006267]  SyS_write+0x55/0xc0
[  138.006654]  entry_SYSCALL_64_fastpath+0x1a/0xa9
[  138.007071] RIP: 0033:0x7f7554b9dc30
[  138.007437] RSP: 002b:00007ffc9f92c788 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[  138.007807] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f7554b9dc30
[  138.008168] RDX: 0000000000000002 RSI: 00005640cd536640 RDI: 0000000000000003
[  138.008573] RBP: 00007ffc9f92c780 R08: 0000000000000001 R09: 0000000000000002
[  138.008918] R10: 0000000000000064 R11: 0000000000000246 R12: 0000000000000004
[  138.009254] R13: 00005640cdbf77a0 R14: 00005640cdbf7720 R15: 00007ffc9f92c238
[  138.009610] Code: 0f 1f 44 00 00 48 8b 87 98 00 00 00 55 48 89 e5 48 83 78 08 00 74 10 8b 05 07 42 02 00 83 f8 01 74 40 83 f8 02 74 19 31 c0 31 d2 <f7> b7 88 00 00 00 5d 89 d0 48 c1 e0 07 48 03 87 90 00 00 00 c3
[  138.010664] RIP: svc_pool_for_cpu+0x2b/0x80 [sunrpc] RSP: ffff9873c2607c18
[  138.011061] ---[ end trace b3468224cafa7d11 ]---

Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name nfsv4.x-callback-create-the-callback-service-through.patch

NFSv4: Fix callback server shutdown

We want to use kthread_stop() in order to ensure the threads are
shut down before we tear down the nfs_callback_info in nfs_callback_down.

Tested-and-reviewed-by: Kinglong Mee <kinglongmee@gmail.com>
Reported-by: Kinglong Mee <kinglongmee@gmail.com>
Fixes: bb6aeba736ba9 ("NFSv4.x: Switch to using svc_set_num_threads()...")
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name nfsv4-fix-callback-server-shutdown.patch

SUNRPC: Refactor svc_set_num_threads()

Refactor to separate out the functions of starting and stopping threads
so that they can be used in other helpers.

Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Tested-and-reviewed-by: Kinglong Mee <kinglongmee@gmail.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name sunrpc-refactor-svc_set_num_threads.patch

dccp/tcp: do not inherit mc_list from parent

syzkaller found a way to trigger double frees from ip_mc_drop_socket()

It turns out that leave a copy of parent mc_list at accept() time,
which is very bad.

Very similar to commit 8b485ce69876 ("tcp: do not inherit
fastopen_req from parent")

Initial report from Pray3r, completed by Andrey one.
Thanks a lot to them !

Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Pray3r <pray3r.z@gmail.com>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name dccp-tcp-do-not-inherit-mc_list-from-parent.patch

tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline()

Strcpy is inherently not safe, and strlcpy() should be used instead.
__trace_find_cmdline() uses strcpy() because the comms saved must have a
terminating nul character, but it doesn't hurt to add the extra protection
of using strlcpy() instead of strcpy().

Link: http://lkml.kernel.org/r/1493806274-13936-1-git-send-email-amit.pundir@linaro.org
Signed-off-by: Amey Telawane <ameyt@codeaurora.org>
[AmitP: Cherry-picked this commit from CodeAurora kernel/msm-3.10
https://source.codeaurora.org/quic/la/kernel/msm-3.10/commit/?id=2161ae9a70b12cf18ac8e5952a20161ffbccb477]
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
[ Updated change log and removed the "- 1" from len parameter ]
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name tracing-Use-strlcpy-instead-of-strcpy-in-__trace_fin.patch

time: Mark TIMER_STATS as broken

This is a substitute for upstream commit dfb4357da6dd "time: Remove
CONFIG_TIMER_STATS", which avoids the need to resolve conflicts with
the PREEMPT_RT patch series.

Gbp-Pq: Topic debian
Gbp-Pq: Name time-mark-timer_stats-as-broken.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 set securelevel when in Secure Boot mode

Add a kernel configuration option to enable securelevel, 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>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name arm64-add-kernel-config-option-to-set-securelevel-wh.patch

arm64/efi: Disable secure boot if shim is in insecure mode

Port to arm64 a patch originally written by Josh Boyer for the x86 EFI
stub.

A user can manually tell the shim boot loader to disable validation of
images it loads.  When a user does this, it creates a UEFI variable called
MokSBState that does not have the runtime attribute set.  Given that the
user explicitly disabled validation, we can honor that and not enable
secure boot mode if that variable is set.

Signed-off-by: Linn Crosetto <linn@hpe.com>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name arm64-efi-disable-secure-boot-if-shim-is-in-insecure.patch

mtd: Disable slram and phram when securelevel is enabled

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 securelevel is set.

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

Enable cold boot attack mitigation

Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name enable-cold-boot-attack-mitigation.patch

acpi: Disable APEI error injection if securelevel is set

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
securelevel is set.

Signed-off-by: Linn Crosetto <linn@hpe.com>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name acpi-disable-apei-error-injection-if-securelevel-is-.patch

acpi: Disable ACPI table override if securelevel is set

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 securelevel is set.

Signed-off-by: Linn Crosetto <linn@hpe.com>
[bwh: Forward-ported to 4.7: ACPI override code moved to drivers/acpi/tables.c]
[bwh: Forward-ported to 4.9: adjust context]

Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name acpi-disable-acpi-table-override-if-securelevel-is-s.patch

kexec/uefi: 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>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name kexec-uefi-copy-secure_boot-flag-in-boot-params-acro.patch

hibernate: Disable when securelevel is set

There is currently no way to verify the resume image when returning
from hibernate.  This might compromise the securelevel trust model,
so until we can work with signed hibernate images we disable it in
a secure modules environment.

Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name hibernate-disable-when-securelevel-is-set.patch

efi: Disable secure boot if shim is in insecure mode

A user can manually tell the shim boot loader to disable validation of
images it loads.  When a user does this, it creates a UEFI variable called
MokSBState that does not have the runtime attribute set.  Given that the
user explicitly disabled validation, we can honor that and not enable
secure boot mode if that variable is set.

Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name efi-disable-secure-boot-if-shim-is-in-insecure-mode.patch

Add option to automatically set securelevel when 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 the kernel prevent userspace from inserting untrusted kernel
code at runtime. Add a configuration option that enforces this automatically
when enabled.

Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name add-option-to-automatically-set-securelevel-when-in-.patch

asus-wmi: Restrict debugfs interface when securelevel is set

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. Prevent that if securelevel is set.

Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name asus-wmi-restrict-debugfs-interface-when-securelevel.patch

x86: Restrict MSR access when securelevel is set

Permitting write access to MSRs allows userspace to modify the running
kernel. Prevent this if securelevel has been set. Based on a patch by Kees
Cook.

Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name x86-restrict-msr-access-when-securelevel-is-set.patch

uswsusp: Disable when securelevel is set

uswsusp allows a user process to dump and then restore kernel state, which
makes it possible to modify the running kernel. Disable this if securelevel
has been set.

Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name uswsusp-disable-when-securelevel-is-set.patch

kexec: Disable at runtime if securelevel has been set.

kexec permits the loading and execution of arbitrary code in ring 0, which
permits the modification of the running kernel. Prevent this if securelevel
has been set.

Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name kexec-disable-at-runtime-if-securelevel-has-been-set.patch

acpi: Ignore acpi_rsdp kernel parameter when securelevel is set

This option allows userspace to pass the RSDP address to the kernel, which
makes it possible for a user to execute arbitrary code in the kernel.
Disable this when securelevel is set.

Signed-off-by: Josh Boyer <jwboyer@redhat.com>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name acpi-ignore-acpi_rsdp-kernel-parameter-when-securele.patch

acpi: Limit access to custom_method if securelevel is set

custom_method effectively allows arbitrary access to system memory, making
it possible for an attacker to modify the kernel at runtime. Prevent this
if securelevel has been set.

Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name acpi-limit-access-to-custom_method-if-securelevel-is.patch

Restrict /dev/mem and /dev/kmem when securelevel is set.

Allowing users to write to address space provides mechanisms that may permit
modification of the kernel at runtime. Prevent this if securelevel has been
set.

Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
[bwh: Forward-ported to 4.9: adjust context]

Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name restrict-dev-mem-and-dev-kmem-when-securelevel-is-se.patch

x86: Lock down IO port access when securelevel is enabled

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 when securelevel is set.

Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name x86-lock-down-io-port-access-when-securelevel-is-ena.patch

PCI: Lock down BAR access when securelevel is enabled

Any hardware that can potentially generate DMA has to be locked down from
userspace in order to avoid it being possible for an attacker to modify
kernel code. This should be prevented if securelevel has been set. Default
to paranoid - in future we can potentially relax this for sufficiently
IOMMU-isolated devices.

Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name pci-lock-down-bar-access-when-securelevel-is-enabled.patch

Enforce module signatures when securelevel is greater than 0

If securelevel has been set to 1 or greater, require that all modules have
valid signatures.

Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name enforce-module-signatures-when-securelevel-is-greate.patch