Phil Elwell [Fri, 4 Dec 2015 17:41:50 +0000 (17:41 +0000)]
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.
Eric Anholt [Fri, 19 Dec 2014 00:07:15 +0000 (16:07 -0800)]
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.
Ben Hutchings [Tue, 14 Jun 2016 19:13:24 +0000 (20:13 +0100)]
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
Ben Hutchings [Tue, 14 Jun 2016 19:13:23 +0000 (20:13 +0100)]
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
Ben Hutchings [Tue, 14 Jun 2016 19:44:14 +0000 (20:44 +0100)]
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
Ben Hutchings [Tue, 14 Jun 2016 20:09:19 +0000 (21:09 +0100)]
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
Ben Hutchings [Thu, 3 Nov 2016 21:25:26 +0000 (15:25 -0600)]
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
Ben Hutchings [Thu, 9 Jun 2016 22:35:08 +0000 (23:35 +0100)]
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
Ben Hutchings [Sun, 20 Mar 2016 21:09:02 +0000 (21:09 +0000)]
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
Ben Hutchings [Sun, 21 Feb 2016 15:33:15 +0000 (15:33 +0000)]
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
Ben Hutchings [Tue, 29 Sep 2015 01:55:06 +0000 (02:55 +0100)]
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
Ben Hutchings [Fri, 25 Sep 2015 19:28:10 +0000 (20:28 +0100)]
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
Ben Hutchings [Fri, 25 Sep 2015 19:09:23 +0000 (20:09 +0100)]
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
Ben Hutchings [Fri, 2 Dec 2016 23:06:18 +0000 (23:06 +0000)]
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
Ben Hutchings [Fri, 2 Dec 2016 01:26:54 +0000 (01:26 +0000)]
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
Ben Hutchings [Fri, 2 Dec 2016 02:27:50 +0000 (02:27 +0000)]
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
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
Hugh Dickins [Tue, 20 Jun 2017 09:10:44 +0000 (02:10 -0700)]
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
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
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
WANG Cong [Tue, 9 May 2017 23:59:54 +0000 (16:59 -0700)]
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
Eric Dumazet [Wed, 17 May 2017 14:16:40 +0000 (07:16 -0700)]
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
David S. Miller [Mon, 5 Jun 2017 01:41:10 +0000 (21:41 -0400)]
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
Ben Hutchings [Wed, 31 May 2017 12:15:41 +0000 (13:15 +0100)]
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
David S. Miller [Thu, 18 May 2017 02:54:11 +0000 (22:54 -0400)]
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
Craig Gallek [Tue, 16 May 2017 18:36:23 +0000 (14:36 -0400)]
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.
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
Kinglong Mee [Thu, 27 Apr 2017 03:13:38 +0000 (11:13 +0800)]
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.
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
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
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
Amey Telawane [Wed, 3 May 2017 10:11:14 +0000 (15:41 +0530)]
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
Ben Hutchings [Sun, 26 Feb 2017 21:01:50 +0000 (21:01 +0000)]
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
Ben Hutchings [Tue, 16 Feb 2016 02:45:42 +0000 (02:45 +0000)]
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
Linn Crosetto [Tue, 30 Aug 2016 17:54:38 +0000 (11:54 -0600)]
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
Linn Crosetto [Mon, 22 Feb 2016 19:54:37 +0000 (12:54 -0700)]
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
Ben Hutchings [Thu, 2 Jun 2016 23:48:39 +0000 (00:48 +0100)]
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
Linn Crosetto [Wed, 16 Mar 2016 20:43:33 +0000 (14:43 -0600)]
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
Linn Crosetto [Fri, 4 Mar 2016 23:08:24 +0000 (16:08 -0700)]
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
Dave Young [Tue, 6 Oct 2015 12:31:31 +0000 (13:31 +0100)]
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
Josh Boyer [Fri, 20 Jun 2014 12:53:24 +0000 (08:53 -0400)]
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
Josh Boyer [Wed, 6 Feb 2013 00:25:05 +0000 (19:25 -0500)]
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
Matthew Garrett [Fri, 9 Aug 2013 22:36:30 +0000 (18:36 -0400)]
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
Matthew Garrett [Fri, 9 Mar 2012 13:46:50 +0000 (08:46 -0500)]
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
Matthew Garrett [Fri, 8 Feb 2013 19:12:13 +0000 (11:12 -0800)]
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
Matthew Garrett [Tue, 3 Sep 2013 15:23:29 +0000 (11:23 -0400)]
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
Matthew Garrett [Fri, 9 Aug 2013 07:33:56 +0000 (03:33 -0400)]
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
Josh Boyer [Mon, 25 Jun 2012 23:57:30 +0000 (19:57 -0400)]
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
Matthew Garrett [Fri, 9 Mar 2012 13:39:37 +0000 (08:39 -0500)]
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
Matthew Garrett [Fri, 9 Mar 2012 14:28:15 +0000 (09:28 -0500)]
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
Matthew Garrett [Thu, 8 Mar 2012 15:35:59 +0000 (10:35 -0500)]
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
Matthew Garrett [Thu, 8 Mar 2012 15:10:38 +0000 (10:10 -0500)]
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
Matthew Garrett [Mon, 9 Sep 2013 12:46:52 +0000 (08:46 -0400)]
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
I decided to add a new expression, given that this doesn't fit into the
existing set operation. Notrack doesn't need a source register, and an
hypothetical NFT_CT_NOTRACK key makes no sense since matching the
untracked state is done through NFT_CT_STATE.
I'm placing this new notrack expression into nft_ct.c, I think a single
module is too much.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Gbp-Pq: Topic features/all
Gbp-Pq: Name netfilter-nft_ct-add-notrack-support.patch
Ben Hutchings [Sat, 4 Mar 2017 01:44:15 +0000 (01:44 +0000)]
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
Ben Hutchings [Wed, 11 Jan 2017 04:30:40 +0000 (04:30 +0000)]
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
Ben Hutchings [Fri, 26 Aug 2016 00:31:28 +0000 (01:31 +0100)]
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
Ian Campbell [Wed, 20 Nov 2013 08:30:14 +0000 (08:30 +0000)]
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
Ben Hutchings [Sat, 19 Oct 2013 18:43:35 +0000 (19:43 +0100)]
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
Aleksey Makarov [Tue, 4 Oct 2016 07:15:32 +0000 (10:15 +0300)]
serial: pl011: add console matching function
This patch adds function pl011_console_match() that implements
method match of struct console. It allows to match consoles against
data specified in a string, for example taken from command line or
compiled by ACPI SPCR table handler.
This patch was merged to tty-next but then reverted because of
conflict with
commit 46e36683f433 ("serial: earlycon: Extend earlycon command line option to support 64-bit addresses")
Now it is fixed.
Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org> Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Tested-by: Christopher Covington <cov@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gbp-Pq: Topic features/arm64
Gbp-Pq: Name serial-pl011-add-console-matching-function.patch
Roger Shimizu [Mon, 30 Jan 2017 11:07:30 +0000 (20:07 +0900)]
ARM: dts: orion5x-lschl: More consistent naming on linkstation series
DTS files, which includes orion5x-linkstation.dtsi, are named:
orion5x-linkstation-*.dts
So we rename the file below:
arch/arm/boot/dts/orion5x-lschl.dts
to the new name:
arch/arm/boot/dts/orion5x-linkstation-lschl.dts
Because DTS conversion of this device was just introduced in 4.9, Debian
is still using legacy device support, other distros are the same,
so here we won't expect any impact actually.
Fixes: f94f268979a2 ("ARM: dts: orion5x: convert ls-chl to FDT") Cc: Ashley Hughes <ashley.hughes@blueyonder.co.uk> Signed-off-by: Roger Shimizu <rogershimizu@gmail.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name ARM-dts-orion5x-lschl-More-consistent-naming-on-link.patch
Neil Armstrong [Wed, 18 Jan 2017 16:50:45 +0000 (17:50 +0100)]
ARM64: dts: meson-gx: Add firmware reserved memory zones
The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
this patch adds these reserved zones.
Without such reserved memory zones, running the following stress command :
$ stress-ng --vm 16 --vm-bytes 128M --timeout 10s
multiple times:
Could lead to the following kernel crashes :
[ 46.937975] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
...
[ 47.058536] Internal error: Attempting to execute userspace memory: 8600000f [#3] PREEMPT SMP
...
Instead of the OOM killer.
Fixes: 4f24eda8401f ("ARM64: dts: Prepare configs for Amlogic Meson GXBaby") Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Andreas Färber <afaerber@suse.de>
[khilman: added Fixes tag, added _reserved and unit addresses] Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
[bwh: Backported to 4.9: adjust filename]
Gbp-Pq: Topic features/arm64
Gbp-Pq: Name dts-meson-gx-add-firmware-reserved-memory-zone.patch
Ashley Hughes [Sat, 19 Nov 2016 07:10:27 +0000 (08:10 +0100)]
ARM: dts: orion5x: convert ls-chl to FDT
This patch converts my orion5x ls-chl Linkstation device to device tree.
[gregory.clement@free-electrons.com: fix title, add back the commit log,
move the removal of the platform in an other patch] Signed-off-by: Ashley Hughes <ashley.hughes@blueyonder.co.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name ARM-dts-orion5x-convert-ls-chl-to-FDT.patch
Ben Hutchings [Fri, 25 Jul 2014 00:16:15 +0000 (01:16 +0100)]
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
Ben Hutchings [Mon, 5 Dec 2011 04:00:58 +0000 (04:00 +0000)]
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
projects / linux-4.9.git / log