Add a kconfig knob which allows for unprivileged bpf to be disabled by default.
If set, the knob sets /proc/sys/kernel/unprivileged_bpf_disabled to value of 2.
This still allows a transition of 2 -> {0,1} through an admin. Similarly,
this also still keeps 1 -> {1} behavior intact, so that once set to permanently
disabled, it cannot be undone aside from a reboot.
We've also added extra2 with max of 2 for the procfs handler, so that an admin
still has a chance to toggle between 0 <-> 2.
Either way, as an additional alternative, applications can make use of CAP_BPF
that we added a while ago.
Follow-up to fe9a5ca7e370 ("bpf: Do not mark insn as seen under speculative
path verification"). The sanitize_insn_aux_data() helper does not serve a
particular purpose in today's code. The original intention for the helper
was that if function-by-function verification fails, a given program would
be cleared from temporary insn_aux_data[], and then its verification would
be re-attempted in the context of the main program a second time.
However, a failure in do_check_subprogs() will skip do_check_main() and
propagate the error to the user instead, thus such situation can never occur.
Given its interaction is not compatible to the Spectre v1 mitigation (due to
comparing aux->seen with env->pass_cnt), just remove sanitize_insn_aux_data()
to avoid future bugs in this area.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name bpf-remove-superfluous-aux-sanitation-on-subprog-rejection.patch
Spectre v4 gadgets make use of memory disambiguation, which is a set of
techniques that execute memory access instructions, that is, loads and
stores, out of program order; Intel's optimization manual, section 2.4.4.5:
A load instruction micro-op may depend on a preceding store. Many
microarchitectures block loads until all preceding store addresses are
known. The memory disambiguator predicts which loads will not depend on
any previous stores. When the disambiguator predicts that a load does
not have such a dependency, the load takes its data from the L1 data
cache. Eventually, the prediction is verified. If an actual conflict is
detected, the load and all succeeding instructions are re-executed.
af86ca4e3088 ("bpf: Prevent memory disambiguation attack") tried to mitigate
this attack by sanitizing the memory locations through preemptive "fast"
(low latency) stores of zero prior to the actual "slow" (high latency) store
of a pointer value such that upon dependency misprediction the CPU then
speculatively executes the load of the pointer value and retrieves the zero
value instead of the attacker controlled scalar value previously stored at
that location, meaning, subsequent access in the speculative domain is then
redirected to the "zero page".
The sanitized preemptive store of zero prior to the actual "slow" store is
done through a simple ST instruction based on r10 (frame pointer) with
relative offset to the stack location that the verifier has been tracking
on the original used register for STX, which does not have to be r10. Thus,
there are no memory dependencies for this store, since it's only using r10
and immediate constant of zero; hence af86ca4e3088 /assumed/ a low latency
operation.
However, a recent attack demonstrated that this mitigation is not sufficient
since the preemptive store of zero could also be turned into a "slow" store
and is thus bypassed as well:
[...]
// r2 = oob address (e.g. scalar)
// r7 = pointer to map value
31: (7b) *(u64 *)(r10 -16) = r2
// r9 will remain "fast" register, r10 will become "slow" register below
32: (bf) r9 = r10
// JIT maps BPF reg to x86 reg:
// r9 -> r15 (callee saved)
// r10 -> rbp
// train store forward prediction to break dependency link between both r9
// and r10 by evicting them from the predictor's LRU table.
33: (61) r0 = *(u32 *)(r7 +24576)
34: (63) *(u32 *)(r7 +29696) = r0
35: (61) r0 = *(u32 *)(r7 +24580)
36: (63) *(u32 *)(r7 +29700) = r0
37: (61) r0 = *(u32 *)(r7 +24584)
38: (63) *(u32 *)(r7 +29704) = r0
39: (61) r0 = *(u32 *)(r7 +24588)
40: (63) *(u32 *)(r7 +29708) = r0
[...]
543: (61) r0 = *(u32 *)(r7 +25596)
544: (63) *(u32 *)(r7 +30716) = r0
// prepare call to bpf_ringbuf_output() helper. the latter will cause rbp
// to spill to stack memory while r13/r14/r15 (all callee saved regs) remain
// in hardware registers. rbp becomes slow due to push/pop latency. below is
// disasm of bpf_ringbuf_output() helper for better visual context:
//
// ffffffff8117ee20: 41 54 push r12
// ffffffff8117ee22: 55 push rbp
// ffffffff8117ee23: 53 push rbx
// ffffffff8117ee24: 48 f7 c1 fc ff ff ff test rcx,0xfffffffffffffffc
// ffffffff8117ee2b: 0f 85 af 00 00 00 jne ffffffff8117eee0 <-- jump taken
// [...]
// ffffffff8117eee0: 49 c7 c4 ea ff ff ff mov r12,0xffffffffffffffea
// ffffffff8117eee7: 5b pop rbx
// ffffffff8117eee8: 5d pop rbp
// ffffffff8117eee9: 4c 89 e0 mov rax,r12
// ffffffff8117eeec: 41 5c pop r12
// ffffffff8117eeee: c3 ret
545: (18) r1 = map[id:4]
547: (bf) r2 = r7
548: (b7) r3 = 0
549: (b7) r4 = 4
550: (85) call bpf_ringbuf_output#194288
// instruction 551 inserted by verifier \
551: (7a) *(u64 *)(r10 -16) = 0 | /both/ are now slow stores here
// storing map value pointer r7 at fp-16 | since value of r10 is "slow".
552: (7b) *(u64 *)(r10 -16) = r7 /
// following "fast" read to the same memory location, but due to dependency
// misprediction it will speculatively execute before insn 551/552 completes.
553: (79) r2 = *(u64 *)(r9 -16)
// in speculative domain contains attacker controlled r2. in non-speculative
// domain this contains r7, and thus accesses r7 +0 below.
554: (71) r3 = *(u8 *)(r2 +0)
// leak r3
As can be seen, the current speculative store bypass mitigation which the
verifier inserts at line 551 is insufficient since /both/, the write of
the zero sanitation as well as the map value pointer are a high latency
instruction due to prior memory access via push/pop of r10 (rbp) in contrast
to the low latency read in line 553 as r9 (r15) which stays in hardware
registers. Thus, architecturally, fp-16 is r7, however, microarchitecturally,
fp-16 can still be r2.
Initial thoughts to address this issue was to track spilled pointer loads
from stack and enforce their load via LDX through r10 as well so that /both/
the preemptive store of zero /as well as/ the load use the /same/ register
such that a dependency is created between the store and load. However, this
option is not sufficient either since it can be bypassed as well under
speculation. An updated attack with pointer spill/fills now _all_ based on
r10 would look as follows:
[...]
// r2 = oob address (e.g. scalar)
// r7 = pointer to map value
[...]
// longer store forward prediction training sequence than before.
2062: (61) r0 = *(u32 *)(r7 +25588)
2063: (63) *(u32 *)(r7 +30708) = r0
2064: (61) r0 = *(u32 *)(r7 +25592)
2065: (63) *(u32 *)(r7 +30712) = r0
2066: (61) r0 = *(u32 *)(r7 +25596)
2067: (63) *(u32 *)(r7 +30716) = r0
// store the speculative load address (scalar) this time after the store
// forward prediction training.
2068: (7b) *(u64 *)(r10 -16) = r2
// preoccupy the CPU store port by running sequence of dummy stores.
2069: (63) *(u32 *)(r7 +29696) = r0
2070: (63) *(u32 *)(r7 +29700) = r0
2071: (63) *(u32 *)(r7 +29704) = r0
2072: (63) *(u32 *)(r7 +29708) = r0
2073: (63) *(u32 *)(r7 +29712) = r0
2074: (63) *(u32 *)(r7 +29716) = r0
2075: (63) *(u32 *)(r7 +29720) = r0
2076: (63) *(u32 *)(r7 +29724) = r0
2077: (63) *(u32 *)(r7 +29728) = r0
2078: (63) *(u32 *)(r7 +29732) = r0
2079: (63) *(u32 *)(r7 +29736) = r0
2080: (63) *(u32 *)(r7 +29740) = r0
2081: (63) *(u32 *)(r7 +29744) = r0
2082: (63) *(u32 *)(r7 +29748) = r0
2083: (63) *(u32 *)(r7 +29752) = r0
2084: (63) *(u32 *)(r7 +29756) = r0
2085: (63) *(u32 *)(r7 +29760) = r0
2086: (63) *(u32 *)(r7 +29764) = r0
2087: (63) *(u32 *)(r7 +29768) = r0
2088: (63) *(u32 *)(r7 +29772) = r0
2089: (63) *(u32 *)(r7 +29776) = r0
2090: (63) *(u32 *)(r7 +29780) = r0
2091: (63) *(u32 *)(r7 +29784) = r0
2092: (63) *(u32 *)(r7 +29788) = r0
2093: (63) *(u32 *)(r7 +29792) = r0
2094: (63) *(u32 *)(r7 +29796) = r0
2095: (63) *(u32 *)(r7 +29800) = r0
2096: (63) *(u32 *)(r7 +29804) = r0
2097: (63) *(u32 *)(r7 +29808) = r0
2098: (63) *(u32 *)(r7 +29812) = r0
// overwrite scalar with dummy pointer; same as before, also including the
// sanitation store with 0 from the current mitigation by the verifier.
2099: (7a) *(u64 *)(r10 -16) = 0 | /both/ are now slow stores here
2100: (7b) *(u64 *)(r10 -16) = r7 | since store unit is still busy.
// load from stack intended to bypass stores.
2101: (79) r2 = *(u64 *)(r10 -16)
2102: (71) r3 = *(u8 *)(r2 +0)
// leak r3
[...]
Looking at the CPU microarchitecture, the scheduler might issue loads (such
as seen in line 2101) before stores (line 2099,2100) because the load execution
units become available while the store execution unit is still busy with the
sequence of dummy stores (line 2069-2098). And so the load may use the prior
stored scalar from r2 at address r10 -16 for speculation. The updated attack
may work less reliable on CPU microarchitectures where loads and stores share
execution resources.
This concludes that the sanitizing with zero stores from af86ca4e3088 ("bpf:
Prevent memory disambiguation attack") is insufficient. Moreover, the detection
of stack reuse from af86ca4e3088 where previously data (STACK_MISC) has been
written to a given stack slot where a pointer value is now to be stored does
not have sufficient coverage as precondition for the mitigation either; for
several reasons outlined as follows:
1) Stack content from prior program runs could still be preserved and is
therefore not "random", best example is to split a speculative store
bypass attack between tail calls, program A would prepare and store the
oob address at a given stack slot and then tail call into program B which
does the "slow" store of a pointer to the stack with subsequent "fast"
read. From program B PoV such stack slot type is STACK_INVALID, and
therefore also must be subject to mitigation.
2) The STACK_SPILL must not be coupled to register_is_const(&stack->spilled_ptr)
condition, for example, the previous content of that memory location could
also be a pointer to map or map value. Without the fix, a speculative
store bypass is not mitigated in such precondition and can then lead to
a type confusion in the speculative domain leaking kernel memory near
these pointer types.
While brainstorming on various alternative mitigation possibilities, we also
stumbled upon a retrospective from Chrome developers [0]:
[...] For variant 4, we implemented a mitigation to zero the unused memory
of the heap prior to allocation, which cost about 1% when done concurrently
and 4% for scavenging. Variant 4 defeats everything we could think of. We
explored more mitigations for variant 4 but the threat proved to be more
pervasive and dangerous than we anticipated. For example, stack slots used
by the register allocator in the optimizing compiler could be subject to
type confusion, leading to pointer crafting. Mitigating type confusion for
stack slots alone would have required a complete redesign of the backend of
the optimizing compiler, perhaps man years of work, without a guarantee of
completeness. [...]
From BPF side, the problem space is reduced, however, options are rather
limited. One idea that has been explored was to xor-obfuscate pointer spills
to the BPF stack:
[...]
// preoccupy the CPU store port by running sequence of dummy stores.
[...]
2106: (63) *(u32 *)(r7 +29796) = r0
2107: (63) *(u32 *)(r7 +29800) = r0
2108: (63) *(u32 *)(r7 +29804) = r0
2109: (63) *(u32 *)(r7 +29808) = r0
2110: (63) *(u32 *)(r7 +29812) = r0
// overwrite scalar with dummy pointer; xored with random 'secret' value
// of 943576462 before store ...
2111: (b4) w11 = 943576462
2112: (af) r11 ^= r7
2113: (7b) *(u64 *)(r10 -16) = r11
2114: (79) r11 = *(u64 *)(r10 -16)
2115: (b4) w2 = 943576462
2116: (af) r2 ^= r11
// ... and restored with the same 'secret' value with the help of AX reg.
2117: (71) r3 = *(u8 *)(r2 +0)
[...]
While the above would not prevent speculation, it would make data leakage
infeasible by directing it to random locations. In order to be effective
and prevent type confusion under speculation, such random secret would have
to be regenerated for each store. The additional complexity involved for a
tracking mechanism that prevents jumps such that restoring spilled pointers
would not get corrupted is not worth the gain for unprivileged. Hence, the
fix in here eventually opted for emitting a non-public BPF_ST | BPF_NOSPEC
instruction which the x86 JIT translates into a lfence opcode. Inserting the
latter in between the store and load instruction is one of the mitigations
options [1]. The x86 instruction manual notes:
[...] An LFENCE that follows an instruction that stores to memory might
complete before the data being stored have become globally visible. [...]
The latter meaning that the preceding store instruction finished execution
and the store is at minimum guaranteed to be in the CPU's store queue, but
it's not guaranteed to be in that CPU's L1 cache at that point (globally
visible). The latter would only be guaranteed via sfence. So the load which
is guaranteed to execute after the lfence for that local CPU would have to
rely on store-to-load forwarding. [2], in section 2.3 on store buffers says:
[...] For every store operation that is added to the ROB, an entry is
allocated in the store buffer. This entry requires both the virtual and
physical address of the target. Only if there is no free entry in the store
buffer, the frontend stalls until there is an empty slot available in the
store buffer again. Otherwise, the CPU can immediately continue adding
subsequent instructions to the ROB and execute them out of order. On Intel
CPUs, the store buffer has up to 56 entries. [...]
One small upside on the fix is that it lifts constraints from af86ca4e3088
where the sanitize_stack_off relative to r10 must be the same when coming
from different paths. The BPF_ST | BPF_NOSPEC gets emitted after a BPF_STX
or BPF_ST instruction. This happens either when we store a pointer or data
value to the BPF stack for the first time, or upon later pointer spills.
The former needs to be enforced since otherwise stale stack data could be
leaked under speculation as outlined earlier. For non-x86 JITs the BPF_ST |
BPF_NOSPEC mapping is currently optimized away, but others could emit a
speculation barrier as well if necessary. For real-world unprivileged
programs e.g. generated by LLVM, pointer spill/fill is only generated upon
register pressure and LLVM only tries to do that for pointers which are not
used often. The program main impact will be the initial BPF_ST | BPF_NOSPEC
sanitation for the STACK_INVALID case when the first write to a stack slot
occurs e.g. upon map lookup. In future we might refine ways to mitigate
the latter cost.
In case of JITs, each of the JIT backends compiles the BPF nospec instruction
/either/ to a machine instruction which emits a speculation barrier /or/ to
/no/ machine instruction in case the underlying architecture is not affected
by Speculative Store Bypass or has different mitigations in place already.
This covers both x86 and (implicitly) arm64: In case of x86, we use 'lfence'
instruction for mitigation. In case of arm64, we rely on the firmware mitigation
as controlled via the ssbd kernel parameter. Whenever the mitigation is enabled,
it works for all of the kernel code with no need to provide any additional
instructions here (hence only comment in arm64 JIT). Other archs can follow
as needed. The BPF nospec instruction is specifically targeting Spectre v4
since i) we don't use a serialization barrier for the Spectre v1 case, and
ii) mitigation instructions for v1 and v4 might be different on some archs.
The BPF nospec is required for a future commit, where the BPF verifier does
annotate intermediate BPF programs with speculation barriers.
Co-developed-by: Piotr Krysiuk <piotras@gmail.com> Co-developed-by: Benedict Schlueter <benedict.schlueter@rub.de> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Piotr Krysiuk <piotras@gmail.com> Signed-off-by: Benedict Schlueter <benedict.schlueter@rub.de> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name bpf-introduce-bpf-nospec-instruction-for-mitigating-.patch
The first chunk in a packet is ensured to be present at the beginning of
sctp_rcv(), as a packet needs to have at least 1 chunk. But the second
one, may not be completely available and ch->length can be over
uninitialized memory.
Fix here is by only trying to walk on the next chunk if there is enough to
hold at least the header, and then proceed with the ch->length validation
that is already there.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name sctp-add-size-validation-when-walking-chunks.patch
Ilja reported that, simply putting it, nothing was validating that
from_addr_param functions were operating on initialized memory. That is,
the parameter itself was being validated by sctp_walk_params, but it
doesn't check for types and their specific sizes and it could be a 0-length
one, causing from_addr_param to potentially work over the next parameter or
even uninitialized memory.
The fix here is to, in all calls to from_addr_param, check if enough space
is there for the wanted IP address type.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name sctp-validate-from_addr_param-return.patch
Even though we validate user-provided inputs we then traverse past
validated data when applying the new map. The issue was originally
discovered by Murray McAllister with this simple POC (if the following
is executed by an unprivileged user it will instantly panic the system):
int main(void) {
int fd, ret;
unsigned int buffer[10000];
It's possible to create a region which maps valid but non-refcounted
pages (e.g., tail pages of non-compound higher order allocations). These
host pages can then be returned by gfn_to_page, gfn_to_pfn, etc., family
of APIs, which take a reference to the page, which takes it from 0 to 1.
When the reference is dropped, this will free the page incorrectly.
Fix this by only taking a reference on valid pages if it was non-zero,
which indicates it is participating in normal refcounting (and can be
released with put_page).
This addresses CVE-2021-22543.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Tested-by: Paolo Bonzini <pbonzini@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name KVM-do-not-allow-mapping-valid-but-non-reference-cou.patch
can_rx_register() callbacks may be called concurrently to the call to
can_rx_unregister(). The callbacks and callback data, though, are
protected by RCU and the struct sock reference count.
So the callback data is really attached to the life of sk, meaning
that it should be released on sk_destruct. However, bcm_remove_op()
calls tasklet_kill(), and RCU callbacks may be called under RCU
softirq, so that cannot be used on kernels before the introduction of
HRTIMER_MODE_SOFT.
However, bcm_rx_handler() is called under RCU protection, so after
calling can_rx_unregister(), we may call synchronize_rcu() in order to
wait for any RCU read-side critical sections to finish. That is,
bcm_rx_handler() won't be called anymore for those ops. So, we only
free them, after we do that synchronize_rcu().
Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") Link: https://lore.kernel.org/r/20210619161813.2098382-1-cascardo@canonical.com Cc: linux-stable <stable@vger.kernel.org> Reported-by: syzbot+0f7e7e5e2f4f40fa89c0@syzkaller.appspotmail.com Reported-by: Norbert Slusarek <nslusarek@gmx.net> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name can-bcm-delay-release-of-struct-bcm_op-after-synchro.patch
Ben Hutchings [Tue, 16 Feb 2016 02:45:42 +0000 (02:45 +0000)]
[i386/686-pae] PCI: Set pci=nobios by default
Forwarded: not-needed
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
This patch completes commit 278311e417be ("kexec, KEYS: Make use of
platform keyring for signature verify") which, while adding the
platform keyring for bzImage verification, neglected to also add
this keyring for module verification.
As such, kernel modules signed with keys from the MokList variable
were not successfully verified.
Signed-off-by: Robert Holmes <robeholmes@gmail.com> Signed-off-by: Jeremy Cline <jcline@redhat.com>
Gbp-Pq: Topic features/all/db-mok-keyring
Gbp-Pq: Name KEYS-Make-use-of-platform-keyring-for-module-signature.patch
Ben Hutchings [Sun, 5 May 2019 12:45:06 +0000 (13:45 +0100)]
MODSIGN: Make shash allocation failure fatal
mod_is_hash_blacklisted() currently returns 0 (suceess) if
crypto_alloc_shash() fails. This should instead be a fatal error,
so unwrap and pass up the error code.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/all/db-mok-keyring
Gbp-Pq: Name modsign-make-shash-allocation-failure-fatal.patch
That's better for checking the attributes of db and mok variables
before loading certificates to kernel keyring.
For db and dbx, both of them are authenticated variables. Which
means that they can only be modified by manufacturer's key. So
the kernel should checks EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS
attribute before we trust it.
For mok-rt and mokx-rt, both of them are created by shim boot loader
to forward the mok/mokx content to runtime. They must be runtime-volatile
variables. So kernel should checks that the attributes map did not set
EFI_VARIABLE_NON_VOLATILE bit before we trust it.
Cc: David Howells <dhowells@redhat.com> Cc: Josh Boyer <jwboyer@fedoraproject.org> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com>
[Rebased by Luca Boccassi]
[bwh: Forward-ported to 5.5.9:
- get_cert_list() takes a pointer to status and returns the cert list
- Adjust filename, context]
[bwh: Forward-ported to 5.10: MokListRT and MokListXRT are now both
loaded through a single code path.]
Gbp-Pq: Topic features/all/db-mok-keyring
Gbp-Pq: Name 0004-MODSIGN-check-the-attributes-of-db-and-mok.patch
Ben Hutchings [Sun, 15 Nov 2020 01:01:03 +0000 (01:01 +0000)]
MODSIGN: load blacklist from MOKx
Loosely based on a patch by "Lee, Chun-Yi" <joeyli.kernel@gmail.com>
at <https://lore.kernel.org/patchwork/patch/933177/> which was later
rebased by Luca Boccassi.
This patch adds the logic to load the blacklisted hash and
certificates from MOKx which is maintained by shim bootloader.
Since MOK list loading became more complicated in 5.10 and was moved
to load_moklist_certs(), add parameters to that and call it once for
each of MokListRT and MokListXRT.
Signed-off-by: Ben Hutchings <benh@debian.org>
Gbp-Pq: Topic features/all/db-mok-keyring
Gbp-Pq: Name 0002-MODSIGN-load-blacklist-from-MOKx.patch
The mok can not be trusted when the secure boot is disabled. Which
means that the kernel embedded certificate is the only trusted key.
Due to db/dbx are authenticated variables, they needs manufacturer's
KEK for update. So db/dbx are secure when secureboot disabled.
Cc: David Howells <dhowells@redhat.com> Cc: Josh Boyer <jwboyer@fedoraproject.org> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com>
[Rebased by Luca Boccassi]
[bwh: Forward-ported to 5.5.9:
- get_cert_list() takes a pointer to status and returns the cert list
- Adjust filename]
[Salvatore Bonaccorso: Forward-ported to 5.10: Refresh for changes in 38a1f03aa240 ("integrity: Move import of MokListRT certs to a separate
routine")]
Gbp-Pq: Topic features/all/db-mok-keyring
Gbp-Pq: Name 0001-MODSIGN-do-not-load-mok-when-secure-boot-disabled.patch
Linn Crosetto [Tue, 30 Aug 2016 17:54:38 +0000 (11:54 -0600)]
arm64: add kernel config option to lock down when in Secure Boot mode
Bug-Debian: https://bugs.debian.org/831827
Forwarded: no
Add a kernel configuration option to lock down the kernel, to restrict
userspace's ability to modify the running kernel when UEFI Secure Boot is
enabled. Based on the x86 patch by Matthew Garrett.
Determine the state of Secure Boot in the EFI stub and pass this to the
kernel using the FDT.
Signed-off-by: Linn Crosetto <linn@hpe.com>
[bwh: Forward-ported to 4.10: adjust context]
[Lukas Wunner: Forward-ported to 4.11: drop parts applied upstream]
[bwh: Forward-ported to 4.15 and lockdown patch set:
- Pass result of efi_get_secureboot() in stub through to
efi_set_secure_boot() in main kernel
- Use lockdown API and naming]
[bwh: Forward-ported to 4.19.3: adjust context in update_fdt()]
[dannf: Moved init_lockdown() call after uefi_init(), fixing SB detection]
[bwh: Drop call to init_lockdown(), as efi_set_secure_boot() now calls this]
[bwh: Forward-ported to 5.6: efi_get_secureboot() no longer takes a
sys_table parameter]
[bwh: Forward-ported to 5.7: EFI initialisation from FDT was rewritten, so:
- Add Secure Boot mode to the parameter enumeration in fdtparams.c
- Add a parameter to efi_get_fdt_params() to return the Secure Boot mode
- Since Xen does not have a property name defined for Secure Boot mode,
change efi_get_fdt_prop() to handle a missing property name by clearing
the output variable]
[Salvatore Bonaccorso: Forward-ported to 5.10: f30f242fb131 ("efi: Rename
arm-init to efi-init common for all arch") renamed arm-init.c to efi-init.c]
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name arm64-add-kernel-config-option-to-lock-down-when.patch
These drivers allow mapping arbitrary memory ranges as MTD devices.
This should be disabled to preserve the kernel's integrity when it is
locked down.
* Add the HWPARAM flag to the module parameters
* When slram is built-in, it uses __setup() to read kernel parameters,
so add an explicit check security_locked_down() check
Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Cc: Matthew Garrett <mjg59@google.com> Cc: David Howells <dhowells@redhat.com> Cc: Joern Engel <joern@lazybastard.org> Cc: linux-mtd@lists.infradead.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name mtd-disable-slram-and-phram-when-locked-down.patch
Ben Hutchings [Tue, 10 Sep 2019 10:54:28 +0000 (11:54 +0100)]
efi: Lock down the kernel if booted in secure boot mode
Based on an earlier patch by David Howells, who wrote the following
description:
> UEFI Secure Boot provides a mechanism for ensuring that the firmware will
> only load signed bootloaders and kernels. Certain use cases may also
> require that all kernel modules also be signed. Add a configuration option
> that to lock down the kernel - which includes requiring validly signed
> modules - if the kernel is secure-booted.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name efi-lock-down-the-kernel-if-booted-in-secure-boot-mo.patch
UEFI machines can be booted in Secure Boot mode. Add an EFI_SECURE_BOOT
flag that can be passed to efi_enabled() to find out whether secure boot is
enabled.
Move the switch-statement in x86's setup_arch() that inteprets the
secure_boot boot parameter to generic code and set the bit there.
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
cc: linux-efi@vger.kernel.org
[rperier: Forward-ported to 5.5:
- Use pr_warn()
- Adjust context]
[bwh: Forward-ported to 5.6: adjust context]
[bwh: Forward-ported to 5.7:
- Use the next available bit in efi.flags
- Adjust context]
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name efi-add-an-efi_secure_boot-flag-to-indicate-secure-b.patch
memcpy() breaks when using connlimit in set elements. Use
nft_expr_clone() to initialize the connlimit expression list, otherwise
connlimit garbage collector crashes when walking on the list head copy.
After commit 07173c3ec276 ("block: enable multipage bvecs"), a bvec can
have multiple pages. But bio_will_gap() still assumes one page bvec while
checking for merging. If the pages in the bvec go across the
seg_boundary_mask, this check for merging can potentially succeed if only
the 1st page is tested, and can fail if all the pages are tested.
Later, when SCSI builds the SG list the same check for merging is done in
__blk_segment_map_sg_merge() with all the pages in the bvec tested. This
time the check may fail if the pages in bvec go across the
seg_boundary_mask (but tested okay in bio_will_gap() earlier, so those
BIOs were merged). If this check fails, we end up with a broken SG list
for drivers assuming the SG list not having offsets in intermediate pages.
This results in incorrect pages written to the disk.
Fix this by returning the multi-page bvec when testing gaps for merging.
Cc: Jens Axboe <axboe@kernel.dk> Cc: Johannes Thumshirn <johannes.thumshirn@wdc.com> Cc: Pavel Begunkov <asml.silence@gmail.com> Cc: Ming Lei <ming.lei@redhat.com> Cc: Tejun Heo <tj@kernel.org> Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org> Cc: Jeffle Xu <jefflexu@linux.alibaba.com> Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Fixes: 07173c3ec276 ("block: enable multipage bvecs") Signed-off-by: Long Li <longli@microsoft.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/1623094445-22332-1-git-send-email-longli@linuxonhyperv.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name block-return-the-correct-bvec-when-checking-for-gaps.patch
in case of driver wants to sync part of ranges with offset,
swiotlb_tbl_sync_single() copies from orig_addr base to tlb_addr with
offset and ends up with data mismatch.
It was removed from
"swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single",
but said logic has to be added back in.
From Linus's email:
"That commit which the removed the offset calculation entirely, because the old
(unsigned long)tlb_addr & (IO_TLB_SIZE - 1)
was wrong, but instead of removing it, I think it should have just
fixed it to be
(tlb_addr - mem->start) & (IO_TLB_SIZE - 1);
instead. That way the slot offset always matches the slot index calculation."
(Unfortunatly that broke NVMe).
The use-case that drivers are hitting is as follow:
[One fix which was Linus's that made more sense to as it created a
symmetry would break NVMe. The reason for that is the:
unsigned int offset = (tlb_addr - mem->start) & (IO_TLB_SIZE - 1);
would come up with the proper offset, but it would lose the
alignment (which this patch contains).]
Fixes: 16fc3cef33a0 ("swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single") Signed-off-by: Bumyong Lee <bumyong.lee@samsung.com> Signed-off-by: Chanho Park <chanho61.park@samsung.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reported-by: Dominique MARTINET <dominique.martinet@atmark-techno.com> Reported-by: Horia Geantă <horia.geanta@nxp.com> Tested-by: Horia Geantă <horia.geanta@nxp.com> CC: stable@vger.kernel.org Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name swiotlb-manipulate-orig_addr-when-tlb_addr-has-offse.patch
Revert commit 4514d991d992 ("PCI: PM: Do not read power state in
pci_enable_device_flags()") that is reported to cause PCI device
initialization issues on some systems.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=213481 Link: https://lore.kernel.org/linux-acpi/YNDoGICcg0V8HhpQ@eldamar.lan Reported-by: Michael <phyre@rogers.com> Reported-by: Salvatore Bonaccorso <carnil@debian.org> Fixes: 4514d991d992 ("PCI: PM: Do not read power state in pci_enable_device_flags()") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name Revert-PCI-PM-Do-not-read-power-state-in-pci_enable_.patch
The introduction of SIOCGSTAMP{,NS}_OLD and move of SICOGSTAMP{,NS} to
a different header has caused build failures for various user-space
programs including qemu and suricata. It also causes a test failure
for glibc.
For now, remove the _OLD suffix on the old ioctl numbers and require
programs using 64-bit timestamps to explicitly use SIOCGSTAMP{,NS}_NEW.
References: https://lore.kernel.org/lkml/af0eb47a-5b98-1bd9-3e8d-652e7f28b01f@de.ibm.com/
References: https://bugs.debian.org/934316
References: https://ci.debian.net/data/autopkgtest/testing/amd64/g/glibc/2772289/log.gz Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name partially-revert-net-socket-implement-64-bit-timestamps.patch
Ben Hutchings [Mon, 7 Sep 2020 02:38:04 +0000 (03:38 +0100)]
Makefile: Do not check for libelf when building OOT module
When building out-of-tree modules, the necessary tools should have
already been built. We therefore do not need libelf-dev to be
installed.
This effectively reverts commit 9f0c18aec620 "objtool: Fix
CONFIG_STACK_VALIDATION=y warning for out-of-tree modules", and
similarly moves the check introduced by commit 33a57ce0a54d "bpf:
Compile resolve_btfids tool at kernel compilation start".
Gbp-Pq: Topic debian
Gbp-Pq: Name makefile-do-not-check-for-libelf-when-building-oot-module.patch
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
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
Enabling x32 in the standard amd64 kernel would increase its attack
surface while provide no benefit to the vast majority of its users.
No-one seems interested in regularly checking for vulnerabilities
specific to x32 (at least no-one with a white hat).
Still, adding another flavour just to turn on x32 seems wasteful. And
the only differences on syscall entry are a few instructions that mask
out the x32 flag and compare the syscall number.
Use a static key to control whether x32 syscalls are really enabled, a
Kconfig parameter to set its default value and a kernel parameter
"syscall.x32" to change it at boot time.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name x86-make-x32-syscall-support-conditional.patch
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
Jian-Hong Pan [Thu, 24 Sep 2020 06:30:43 +0000 (14:30 +0800)]
[PATCH] arm64: dts: rockchip: disable USB type-c DisplayPort
The cdn-dp sub driver probes the device failed on PINEBOOK Pro.
kernel: cdn-dp fec00000.dp: [drm:cdn_dp_probe [rockchipdrm]] *ERROR* missing extcon or phy
kernel: cdn-dp: probe of fec00000.dp failed with error -22
Then, the device halts all of the DRM related device jobs. For example,
the operations: vop_component_ops, vop_component_ops and
rockchip_dp_component_ops cannot be bound to corresponding devices. So,
Xorg cannot find the correct DRM device.
The USB type-C DisplayPort does not work for now. So, disable the
DisplayPort node until the type-C phy work has been done.
This patch is part of commit 5dcbe7e3862d ("arm64: dts: rockchip: move mmc
aliases to board dts on rk3399") upstream. It is applied here only for Kobol's
helios64 to simplify conflict resolution for some further patches. It currently
is a noop as the same aliases already exist in rk3399.dtsi.
According to the schematic there is an external pull up, so there is no
need to enable the internal one additionally. Using no pull up matches
the vendor device tree.
Commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay
config") sets the RX/TX delay according to the phy-mode property in the
device tree. For the Orange Pi Plus board this is "rgmii", which is the
wrong setting.
Following the example of a900cac3750b ("ARM: dts: sun7i: a20: bananapro:
Fix ethernet phy-mode") the phy-mode is changed to "rgmii-id" which gets
the Ethernet working again on this board.
Ben Hutchings [Tue, 25 Sep 2018 18:44:13 +0000 (19:44 +0100)]
x86-32: Disable 3D-Now in generic config
We want the 686 flavour to run on Geode LX and similar AMD family 5
CPUs as well as family 6 and higher CPUs. This used to work with
CONFIG_M686=y. However commit 25d76ac88821 "x86/Kconfig: Explicitly
enumerate i686-class CPUs in Kconfig" in Linux 4.16 has made the
kernel require family 6 or higher.
It looks like a sensible choice would be to enable CONFIG_MGEODE_LX
and CONFIG_X86_GENERIC (for more generic optimisations), but this
currently enables CONFIG_X86_USE_3D_NOW which will cause the kernel to
crash on CPUs without the AMD-specific 3D-Now instructions.
Make CONFIG_X86_USE_3DNOW depend on CONFIG_X86_GENERIC being disabled.
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name x86-32-disable-3dnow-in-generic-config.patch
Adds a new ACPI init routine acpi_fixup_m400_quirks that adds
a work-around for HPE ProLiant m400 APEI firmware problems.
The work-around disables APEI when CONFIG_ACPI_APEI is set and
m400 firmware is detected. Without this fixup m400 systems
experience errors like these on startup:
After commit faa16bc404d7 ("lib: Use existing define with
polynomial") the lib/xz/xz_crc32.c includes a header from include/linux
directory thus any other user of this code should define proper include
path.
This fixes the build error on powerpc with CONFIG_KERNEL_XZ:
In file included from ../arch/powerpc/boot/../../../lib/decompress_unxz.c:233:0,
from ../arch/powerpc/boot/decompress.c:42:
../arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:29: fatal error: linux/crc32poly.h: No such file or directory
Reported-by: Michal Kubecek <mkubecek@suse.cz> Fixes: faa16bc404d7 ("lib: Use existing define with polynomial") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reported-by: kbuild test robot <lkp@intel.com> Reported-by: Meelis Roos <mroos@linux.ee> Tested-by: Michal Kubecek <mkubecek@suse.cz>
Gbp-Pq: Topic bugfix/powerpc
Gbp-Pq: Name powerpc-boot-fix-missing-crc32poly.h-when-building-with-kernel_xz.patch
The xen-privcmd driver, which can be modular, calls set_pte_at()
which in turn may call __sync_icache_dcache().
The call to __sync_icache_dcache() may be optimised out because it is
conditional on !pte_special(), and xen-privcmd calls pte_mkspecial().
However, in a non-LPAE configuration there is no "special" bit and the
call is really unconditional.
Fixes: 3ad0876554ca ("xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE") Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/arm
Gbp-Pq: Name arm-mm-export-__sync_icache_dcache-for-xen-privcmd.patch
arch/sh/Makefile defines and exports ld-bfd to be used by
arch/sh/boot/Makefile and arch/sh/boot/compressed/Makefile. Similarly
arch/sh/boot/Makefile defines and exports suffix-y to be used by
arch/sh/boot/compressed/Makefile. However some shells, including
dash, will not pass through environment variables whose name includes
a hyphen. Usually GNU make does not use a shell to recurse, but if
e.g. $(srctree) contains '~' it will use a shell here.
Rename these variables to ld_bfd and suffix_y.
References: https://buildd.debian.org/status/fetch.php?pkg=linux&arch=sh4&ver=4.13%7Erc5-1%7Eexp1&stamp=1502943967&raw=0 Fixes: ef9b542fce00 ("sh: bzip2/lzma uImage support.") Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/sh
Gbp-Pq: Name sh-boot-do-not-use-hyphen-in-exported-variable-name.patch
Ben Hutchings [Sat, 22 Jul 2017 16:37:33 +0000 (17:37 +0100)]
perf tools: Fix unwind build on i386
Forwarded: no
EINVAL may not be defined when building unwind-libunwind.c with
REMOTE_UNWIND_LIBUNWIND, resulting in a compiler error in
LIBUNWIND__ARCH_REG_ID(). Its only caller, access_reg(), only checks
for a negative return value and doesn't care what it is. So change
-EINVAL to -1.
Fixes: 52ffe0ff02fc ("Support x86(32-bit) cross platform callchain unwind.") Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name perf-tools-fix-unwind-build-on-i386.patch
The old board code for the TS419 assigns MPP pins 15 and 16 as SATA
activity signals (and none as SATA presence signals). Currently the
device tree assigns the SoC's default pinmux groups for SATA, which
conflict with the second Ethernet port.
Reported-by: gmbh@gazeta.pl Tested-by: gmbh@gazeta.pl
References: https://bugs.debian.org/855017 Cc: stable@vger.kernel.org # 3.15+ Fixes: 934b524b3f49 ("ARM: Kirkwood: Add DT description of QNAP 419") Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/arm
Gbp-Pq: Name arm-dts-kirkwood-fix-sata-pinmux-ing-for-ts419.patch
Too many people come complaining about losing their data -- and indeed,
there's no warning outside a wiki and the mailing list tribal knowledge.
Message severity chosen for consistency with XFS -- "alert" makes dmesg
produce nice red background which should get the point across.
Signed-off-by: Adam Borowski <kilobyte@angband.pl>
[bwh: Also add_taint() so this is flagged in bug reports]
Gbp-Pq: Topic debian
Gbp-Pq: Name btrfs-warn-about-raid5-6-being-experimental-at-mount.patch
Ben Hutchings [Wed, 13 Jul 2016 00:37:22 +0000 (01:37 +0100)]
fanotify: Taint on use of FANOTIFY_ACCESS_PERMISSIONS
Forwarded: not-needed
Various free and proprietary AV products use this feature and users
apparently want it. But punting access checks to userland seems like
an easy way to deadlock the system, and there will be nothing we can
do about that. So warn and taint the kernel if this feature is
actually used.
Gbp-Pq: Topic debian
Gbp-Pq: Name fanotify-taint-on-use-of-fanotify_access_permissions.patch
Ben Hutchings [Sat, 18 Mar 2017 20:47:58 +0000 (20:47 +0000)]
fjes: Disable auto-loading
Bug-Debian: https://bugs.debian.org/853976
Forwarded: no
fjes matches a generic ACPI device ID, and relies on its probe
function to distinguish whether that really corresponds to a supported
device. Very few system will need the driver and it wastes memory on
all the other systems where the same device ID appears, so disable
auto-loading.
Gbp-Pq: Topic debian
Gbp-Pq: Name fjes-disable-autoload.patch
Ben Hutchings [Sat, 20 Apr 2013 14:52:02 +0000 (15:52 +0100)]
viafb: Autoload on OLPC XO 1.5 only
Bug-Debian: https://bugs.debian.org/705788
Forwarded: no
It appears that viafb won't work automatically on all the boards for
which it has a PCI device ID match. Currently, it is blacklisted by
udev along with most other framebuffer drivers, so this doesn't matter
much.
However, this driver is required for console support on the XO 1.5.
We need to allow it to be autoloaded on this model only, and then
un-blacklist it in udev.
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name viafb-autoload-on-olpc-xo1.5-only.patch
There are two drivers claiming the platform:pcspkr device:
- pcspkr creates an input(!) device that can only beep
- snd-pcsp creates an equivalent input device plus a PCM device that can
play barely recognisable renditions of sampled sound
snd-pcsp is blacklisted by the alsa-base package, but not everyone
installs that. On PCs where no sound is wanted at all, both drivers
will still be loaded and one or other will complain that it couldn't
claim the relevant I/O range.
In case anyone finds snd-pcsp useful, we continue to build it. But
remove the alias, to ensure it's not loaded where it's not wanted.
Gbp-Pq: Topic debian
Gbp-Pq: Name snd-pcsp-disable-autoload.patch
Ben Hutchings [Sun, 31 Mar 2013 02:58:04 +0000 (03:58 +0100)]
cdc_ncm,cdc_mbim: Use NCM by default
Forwarded: not-needed
Devices that support both NCM and MBIM modes should be kept in NCM
mode unless there is userland support for MBIM.
Set the default value of cdc_ncm.prefer_mbim to false and leave it to
userland (modem-manager) to override this with a modprobe.conf file
once it's ready to speak MBIM.
Gbp-Pq: Topic debian
Gbp-Pq: Name cdc_ncm-cdc_mbim-use-ncm-by-default.patch
There is still laptop firmware that touches the integrated GPU behind
the operating system's back, and doesn't say so in the RMRR table.
Enabling the IOMMU for all devices causes breakage.
Replace CONFIG_INTEL_IOMMU_DEFAULT_ON with a 3-way choice
corresponding to "on", "off", and "on,intgpu_off".
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name intel-iommu-add-kconfig-option-to-exclude-igpu-by-default.patch
There is still laptop firmware that touches the integrated GPU behind
the operating system's back, and doesn't say so in the RMRR table.
Enabling the IOMMU for all devices causes breakage, but turning it off
for all graphics devices seems like a major weakness.
Add an option, intel_iommu=igpu_off, to exclude only integrated GPUs
from remapping. This is a narrower exclusion than igfx_off: it only
affects Intel devices on the root bus. Devices attached through an
external port (Thunderbolt or ExpressCard) won't be on the root bus.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name intel-iommu-add-option-to-exclude-integrated-gpu-only.patch
Ben Hutchings [Mon, 11 Jan 2016 15:23:55 +0000 (15:23 +0000)]
security,perf: Allow further restriction of perf_event_open
Forwarded: https://lkml.org/lkml/2016/1/11/587
When kernel.perf_event_open is set to 3 (or greater), disallow all
access to performance events by users without CAP_SYS_ADMIN.
Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
makes this value the default.
This is based on a similar feature in grsecurity
(CONFIG_GRKERNSEC_PERF_HARDEN). This version doesn't include making
the variable read-only. It also allows enabling further restriction
at run-time regardless of whether the default is changed.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/all
Gbp-Pq: Name security-perf-allow-further-restriction-of-perf_event_open.patch
add sysctl to disallow unprivileged CLONE_NEWUSER by default
This is a short-term patch. Unprivileged use of CLONE_NEWUSER
is certainly an intended feature of user namespaces. However
for at least saucy we want to make sure that, if any security
issues are found, we have a fail-safe.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
[bwh: Remove unneeded binary sysctl bits]
[bwh: Keep this sysctl, but change the default to enabled]
Gbp-Pq: Topic debian
Gbp-Pq: Name add-sysctl-to-disallow-unprivileged-CLONE_NEWUSER-by-default.patch
Ben Hutchings [Sun, 4 Aug 2019 23:29:11 +0000 (00:29 +0100)]
hamradio: Disable auto-loading as mitigation against local exploits
Forwarded: not-needed
We can mitigate the effect of vulnerabilities in obscure protocols by
preventing unprivileged users from loading the modules, so that they
are only exploitable on systems where the administrator has chosen to
load the protocol.
The 'ham' radio protocols (ax25, netrom, rose) are not actively
maintained or widely used. Therefore disable auto-loading.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name hamradio-disable-auto-loading-as-mitigation-against-local-exploits.patch
Ben Hutchings [Thu, 16 Feb 2017 19:09:17 +0000 (19:09 +0000)]
dccp: Disable auto-loading as mitigation against local exploits
Forwarded: not-needed
We can mitigate the effect of vulnerabilities in obscure protocols by
preventing unprivileged users from loading the modules, so that they
are only exploitable on systems where the administrator has chosen to
load the protocol.
The 'dccp' protocol is not actively maintained or widely used.
Therefore disable auto-loading.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name dccp-disable-auto-loading-as-mitigation-against-local-exploits.patch
Ben Hutchings [Sat, 20 Nov 2010 02:24:55 +0000 (02:24 +0000)]
[PATCH] decnet: Disable auto-loading as mitigation against local exploits
Forwarded: not-needed
Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation. We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.
The 'decnet' protocol is unmaintained and of mostly historical
interest, and the user-space support package 'dnet-common' loads the
module explicitly. Therefore disable auto-loading.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name decnet-Disable-auto-loading-as-mitigation-against-lo.patch
Ben Hutchings [Fri, 19 Nov 2010 02:12:48 +0000 (02:12 +0000)]
[PATCH 1/3] rds: Disable auto-loading as mitigation against local exploits
Forwarded: not-needed
Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation. We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.
The 'rds' protocol is one such protocol that has been found to be
vulnerable, and which was not present in the 'lenny' kernel.
Therefore disable auto-loading.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name rds-Disable-auto-loading-as-mitigation-against-local.patch
Ben Hutchings [Fri, 19 Nov 2010 02:12:48 +0000 (02:12 +0000)]
[PATCH 2/3] af_802154: Disable auto-loading as mitigation against local exploits
Forwarded: not-needed
Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation. We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.
The 'af_802154' (IEEE 802.15.4) protocol is not widely used, was
not present in the 'lenny' kernel, and seems to receive only sporadic
maintenance. Therefore disable auto-loading.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name af_802154-Disable-auto-loading-as-mitigation-against.patch
If firmware loading fails due to a missing file, log a second error
message referring to our wiki page about firmware. This will explain
why some firmware is in non-free, or can't be packaged at all. Only
do this once per boot.
Do something similar in the radeon and amdgpu drivers, where we have
an early check to avoid failing at a point where we cannot display
anything.
Gbp-Pq: Topic debian
Gbp-Pq: Name firmware_class-refer-to-debian-wiki-firmware-page.patch
radeon requires firmware/microcode for the GPU in all chips, but for
newer chips (apparently R600 'Evergreen' onward) it also expects
firmware for the memory controller and other sub-blocks.
radeon attempts to gracefully fall back and disable some features if
the firmware is not available, but becomes unstable - the framebuffer
and/or system memory may be corrupted, or the display may stay black.
Therefore, perform a basic check for the existence of
/lib/firmware/{radeon,amdgpu} when a device is probed, and abort if it
is missing, except for the pre-R600 case.
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name radeon-amdgpu-firmware-is-required-for-drm-and-kms-on-r600-onward.patch
Ben Hutchings [Sun, 9 Dec 2012 16:02:00 +0000 (16:02 +0000)]
firmware_class: Log every success and failure against given device
Forwarded: no
The hundreds of users of request_firmware() have nearly as many
different log formats for reporting failures. They also have only the
vaguest hint as to what went wrong; only firmware_class really knows
that. Therefore, add specific log messages for the failure modes that
aren't currently logged.
In case of a driver that tries multiple names, this may result in the
impression that it failed to initialise. Therefore, also log successes.
This makes many error messages in drivers redundant, which will be
removed in later patches.
This does not cover the case where we fall back to a user-mode helper
(which is no longer enabled in Debian).
NOTE: hw-detect will depend on the "firmware: failed to load %s (%d)\n"
format to detect missing firmware.
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name firmware_class-log-every-success-and-failure.patch
The iwlwifi driver currently supports firmware API versions 4-6 for
these devices. It will request the file for the latest supported
version and then fall back to earlier versions. However, the latest
version that has actually been released is 4, so we expect the
requests for versions 6 and then 5 to fail.
The installer appears to report any failed request, and it is probably
not easy to detect that this particular failure is harmless. So stop
requesting the unreleased firmware.
Gbp-Pq: Topic debian
Gbp-Pq: Name iwlwifi-do-not-request-unreleased-firmware.patch
Ben Hutchings [Mon, 24 Aug 2009 22:19:58 +0000 (23:19 +0100)]
af9005: Use request_firmware() to load register init script
Forwarded: no
Read the register init script from the Windows driver. This is sick
but should avoid the potential copyright infringement in distributing
a version of the script which is directly derived from the driver.
Gbp-Pq: Topic features/all
Gbp-Pq: Name drivers-media-dvb-usb-af9005-request_firmware.patch
DKMS and module-assistant both build OOT modules as root. If they
build an old OOT module that still use SUBDIRS this causes Kbuild
to try building a full kernel, which obviously fails but not before
deleting files from the installed headers package.
To avoid such mishaps, detect this situation and abort the build.
The error message is based on that used in commit 0126be38d988
"kbuild: announce removal of SUBDIRS if used".
Gbp-Pq: Topic debian
Gbp-Pq: Name kbuild-abort-build-if-subdirs-used.patch
The module.lds linker script is now built under the scripts directory,
where previously it was under arch/$(SRCARCH).
However, we package the scripts directory as linux-kbuild, which is
meant to be able to do support native and cross-builds. That means it
shouldn't contain files for a specific target architecture without a
wrapper to select between them, and it doesn't appear that linker
scripts are powerful enough to implement such a wrapper.
Building module.lds in a different location would require relatively
large changes. Moving it in the package build rules can work, but we
need to support custom kernel builds from the same source so we can't
assume it's moved.
Therefore, we move module.lds under the arch build directory in
rules.real and change Makefile.modfinal to look for it in both places.
Gbp-Pq: Topic debian
Gbp-Pq: Name kbuild-look-for-module.lds-under-arch-directory-too.patch
Ben Hutchings [Fri, 22 Jun 2018 16:27:00 +0000 (17:27 +0100)]
android: Enable building ashmem and binder as modules
Bug-Debian: https://bugs.debian.org/901492
We want to enable use of the Android ashmem and binder drivers to
support Anbox, but they should not be built-in as that would waste
resources and increase security attack surface on systems that don't
need them.
- Add a MODULE_LICENSE declaration to ashmem
- Change the Makefiles to build each driver as an object with the
"_linux" suffix (which is what Anbox expects)
- Change config symbol types to tristate
Gbp-Pq: Topic debian
Gbp-Pq: Name android-enable-building-ashmem-and-binder-as-modules.patch
Ben Hutchings [Mon, 7 Sep 2020 01:51:53 +0000 (02:51 +0100)]
Export symbols needed by Android drivers
Bug-Debian: https://bugs.debian.org/901492
We want to enable use of the Android ashmem and binder drivers to
support Anbox, but they should not be built-in as that would waste
resources and increase security attack surface on systems that don't
need them.
Export the currently un-exported symbols they depend on.
Gbp-Pq: Topic debian
Gbp-Pq: Name export-symbols-needed-by-android-drivers.patch
Create manpages and binaries including the version
Forwarded: no
[bwh: Fix version insertion in perf man page cross-references and perf
man page title. Install bash_completion script for perf with a
version-dependent name. And do the same for trace.]
Gbp-Pq: Topic debian
Gbp-Pq: Name tools-perf-version.patch
YunQiang Su [Mon, 16 Nov 2020 01:11:00 +0000 (09:11 +0800)]
Use RELAXED ieee754 mode for Loongson-3 as 3A 4000 is 2008-only
Forwarded: not-needed
There are 2 mode of value of IEEE NaN hardcoded by CPU.
Currently, our mipsel/mips64el port is in so-called lagacy mode.
Loongson 3A 4000 is set as the so-called 2008 mode.
To make Debian workable on Loongson 3A 4000, we need set the kerenl in
RELAXED mode.
Here's a patch that simply uses hardcoded definitions instead of
doing the dynamic tests that require architecture-specific scripts.
I don't particularly like this approach because it restricts
portability and diverts from upstream. But, it is simpler, and this
really needs to be fixed somehow before etch (along with a rebuild of
linux-modules-extra-2.6), so I'm willing to live with it if my other
patch is deemed unacceptable.
My primary concern is that, in the future, the output of these scripts
will change and we (or our successors) will either not notice or
forget to update the hardcoded values.
Including the scripts in linux-kbuild will avoid this manual step
altogether, and allow for the possibility of other archs to provide
their own scripts in the future.
Gbp-Pq: Topic debian
Gbp-Pq: Name ia64-hardcode-arch-script-output.patch
Ben Hutchings [Tue, 12 May 2015 18:29:22 +0000 (19:29 +0100)]
Make mkcompile_h accept an alternate timestamp string
Forwarded: not-needed
We want to include the Debian version in the utsname::version string
instead of a full timestamp string. However, we still need to provide
a standard timestamp string for gen_initramfs_list.sh to make the
kernel image reproducible.
Make mkcompile_h use $KBUILD_BUILD_VERSION_TIMESTAMP in preference to
$KBUILD_BUILD_TIMESTAMP.
Gbp-Pq: Topic debian
Gbp-Pq: Name uname-version-timestamp.patch
Ben Hutchings [Sat, 2 Jun 2012 18:53:38 +0000 (19:53 +0100)]
video: Remove nvidiafb and rivafb
Bug-Debian: https://bugs.debian.org/383481
Forwarded: no
These drivers contain register programming code provided by the
hardware vendor that appears to have been deliberately obfuscated.
This is arguably not the preferred form for modification.
These drivers are also largely redundant with nouveau. The RIVA 128
(NV3) is not supported by nouveau but is about 15 years old and
probably discontinued 10 years ago.
Gbp-Pq: Topic debian/dfsg
Gbp-Pq: Name video-remove-nvidiafb-and-rivafb.patch
projects / linux.git / log