Commit graph

396 commits

Author SHA1 Message Date
Eduard Bopp 6ac71f593d linux: backport support for RTL8761b to 5.4 2020-12-20 14:36:07 +01:00
Orivej Desh 4376b91b40 linux-rt_5_9: export symbols needed by zfs
Upstream issue: https://github.com/openzfs/zfs/issues/11097#issuecomment-740682245
2020-12-10 10:34:44 +00:00
Emily d6fe0a4e2d linux/hardened: move files into directory 2020-05-08 15:49:35 +01:00
Emily 2c1db9649e linux_*_hardened: index patches by major kernel version
This will avoid breaking the build whenever a non-major kernel update
happens. In the update script, we map each kernel version to the latest
patch for the latest kernel version less than or equal to what we
have packaged.
2020-04-23 18:50:26 +01:00
Emily 0d4f35efd4 linux_*_hardened: use linux-hardened patch set
This is an updated version of the former upstream,
https://github.com/AndroidHardeningArchive/linux-hardened, and provides
a minimal set of additional hardening patches on top of upstream.

The patch already incorporates many of our hardened profile defaults,
and releases are timely (Linux 5.5.15 and 5.6.2 were released on
2020-04-02; linux-hardened patches for them came out on 2020-04-03 and
2020-04-04 respectively).
2020-04-17 16:13:39 +01:00
Michael Reilly 84cf00f980
treewide: Per RFC45, remove all unquoted URLs 2020-04-10 17:54:53 +01:00
Tim Steinbach baa243d508
linux: Fix request-key for 4.4 and 4.9 2019-12-22 19:51:16 -05:00
Kai Wohlfahrt ea55a2d8a9 linux: patch request-key binary path
This is necessary for id mapping to work with NFS + Kerberos, and also
touches #68106 and 634638.
2019-12-12 12:23:30 +00:00
Jörg Thalheim 96097ab665
linux: update fpu patches for 5.3
At the moment we experience bad instabilities with linux 5.3:

https://github.com/zfsonlinux/zfs/issues/9346

as the zfs-native method of disabling the FPU is buggy.
2019-10-03 11:13:28 +01:00
Frederik Rietdijk ad1d58c622 Merge staging-next into staging 2019-08-31 10:04:20 +02:00
volth 08f68313a4 treewide: remove redundant rec 2019-08-28 11:07:32 +00:00
Samuel Leathers 13d5fc4232
kernelPatches: mac nvme t2 support 2019-08-20 14:22:28 -04:00
Jörg Thalheim 7b77c27caa
linux_5_0: restore __kernel_fpu_{begin,restore}
In 5.0er these function were removed from the public interface also zfs needs
them for AVX/AES-NI support. Without this patch for example throughput on a
encrypted zfs dataset drops to 200 MB/s from 1.2 GB/s. These functions were
removed as their was no user within the linux kernel tree itself.
2019-05-06 14:14:40 +01:00
Tim Steinbach c08aa32c90
linux: Remove i2c-oops patch 2019-04-27 08:08:33 -04:00
Ambroz Bizjak a9c40eef1f
Fix kernel oops on boot due to bug in i2c driver.
https://github.com/NixOS/nixpkgs/issues/60126
https://lkml.org/lkml/2019/4/24/1123

The patch should be removed in the next round of stable releases because the fix should be included.

(cherry picked from commit 1e8a0805890fbb1cce1aa751296c82342b0cae7e)
2019-04-25 20:24:34 -04:00
Tim Steinbach d607715ab3
linux: 5.0-rc6 -> 5.0-rc7
Also remove interpreter truncation patch, no longer needed in package tree.
2019-02-18 21:11:21 -05:00
Edmund Wu f0b8a113dd linux: allow for interpreter to be truncated
via https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb5b020a8d38f77209d0472a0fea755299a8ec78
see https://github.com/NixOS/nixpkgs/issues/53672
2019-02-14 21:01:00 -05:00
Samuel Dionne-Riel 09af2fb9e0 linux: Removes the previously removed raspberry pi patch
There seems to have been an oopsie with the rebase.
2019-02-02 14:29:01 -05:00
Samuel Dionne-Riel 196af4b359 Revert "linuxPackages_4_{19,20}: works around bug with overlayfs."
This reverts commit de86af48faa03a824917ac90f4776481c7ce9e54.

(Manual revert due to conflicts.)

See #54509

The patch is causing overlayfs to misbehave.
2019-02-02 12:18:16 -05:00
Tim Steinbach 705207ec9b
linux: 4.20.5 -> 4.20.6 2019-01-31 07:19:07 -05:00
Bastian Köcher a90fc6d3ef linux: Adds patch for fixing wifi on raspberry pi 2019-01-09 11:18:09 +01:00
Ivan Kozik 1c8fea18e2 kernel/patches.nix: remove hard tabs 2018-12-28 09:06:56 +01:00
Samuel Dionne-Riel 889ef35303 linuxPackages_4_{19,20}: works around bug with overlayfs.
See: https://github.com/NixOS/nixpkgs/issues/48828#issuecomment-445208626
2018-12-26 22:51:31 +00:00
Tim Steinbach 5fccac2b8d
kernel: Remove Copperhead
The patches are unmaintained and suggest a false sense of security
2018-09-03 11:18:11 -04:00
Bastian Köcher fb33305423 linux-kernel: Removes bcm2835_mmal_v4l2_camera_driver patch
The patch was only required for kernel 4.16.
2018-08-06 17:36:18 +03:00
volth 52f53c69ce pkgs/*: remove unreferenced function arguments 2018-07-21 02:48:04 +00:00
talyz 656335cd8b linux: Temporary fix for issue #42755
Fix a serious issue with the xen-netfront driver introduced in
upstream commit f599c64fdf7d ("xen-netfront: Fix race between device
setup and open") where the MTU of the device cannot be set
properly. This should be removed once it's included in upstream.
2018-07-07 10:08:57 +02:00
Tim Steinbach a444dcad03
linux-copperhead: LTS based on regular 4.14 2018-06-10 21:00:47 -04:00
Tim Steinbach 5c4a404b0d
linux-copperhead: 4.16.12.a -> 4.16.13.a 2018-06-04 10:22:39 -04:00
Yegor Timoshenko 59edce6414 kernel: drop tuxOnIce patch (#40411)
Hasn't been updated since 3.14, abandoned by its author, not actually used despite being inside a let binding.
2018-05-13 02:16:59 +02:00
Tuomas Tynkkynen 83b3e6d705 kernel: Drop bitrotted MIPS patches
Not a single one of these applies to even 4.4 anymore, so these have
clearly bitrotted a long, long time ago.
2018-05-11 12:27:31 +03:00
Bastian Köcher 438631e401 kernelPatches: Adds bcm2835_mmal_v4l2_camera_driver
The kernel patch is required for raspberry pi, to enable the camera
module.

[dezgeg: Add some comments indicating it's only needed for 4.16]
2018-04-16 04:26:02 +03:00
Shea Levy cb025f2285
linux_riscv: Move patches to my Linux fork.
All patches there are also submitted upstream and will be removed if
rejected.

Also includes some fixes to get module loading working.
2018-02-23 05:53:31 -05:00
Shea Levy 39ff498418
kernelPatches: Add pointer to ml threads for riscv patches. 2018-02-20 11:26:44 -05:00
Shea Levy f8b5b93b88
linux_riscv: Add patches for initrd support 2018-02-20 09:18:17 -05:00
Shea Levy 6173f2f945
linux_riscv: Add 4.16-rc1.
Fixes #35148.
2018-02-19 12:14:22 -05:00
Florian Klink f919c7faec linux_4_14: fix iwlwifi fw reset
Currently, moving to kernel_4_14 breaks at least Intel Wireless 8260 and
8265 cards due to a API change in the firmware, which is not yet honored
in the driver.
2017-11-15 11:30:24 +00:00
Matthieu Coudron 7dce131b86 kernelmptcp: 0.91.3 -> 0.92.1 2017-11-02 13:14:57 +01:00
Jörg Thalheim 44f93731d6 linux_chromiumos_3_18: remove kernel due lack of maintainer/breakage
There is no maintainer for this package, probably not many users.
It requires effort to fix all third-party modules for this old kernel
versions. It might contain unpatched security holes.

For Pixel chromebooks, we have the samus-kernel.
Apart from that https://github.com/GalliumOS/linux might be a good choice.
2017-09-05 14:42:23 +02:00
Joachim Fasting 697cbbc617
kernelPatches.grsecurity_testing: remove 2017-09-02 15:56:49 +02:00
Robin Gloster 05b8cae9ec
linux: remove unused kernel patches 2017-08-11 19:13:09 +02:00
Tim Steinbach ff10bafd00
linux: Expand hardened config
Based on latest recommendations at
http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings
2017-08-06 09:58:02 -04:00
Tim Steinbach d1aff8d2e5
linux: 4.9.34 -> 4.9.35
Also, remove XSA-216 patches, the fixes are now integrated upstream
2017-06-29 08:26:25 -04:00
Michał Pałka 80e0cda7ff xen: patch for XSAs: 216, 217, 218, 219, 220, 221, 222, and 224
XSA-216 Issue Description:

> The block interface response structure has some discontiguous fields.
> Certain backends populate the structure fields of an otherwise
> uninitialized instance of this structure on their stacks, leaking
> data through the (internal or trailing) padding field.

More: https://xenbits.xen.org/xsa/advisory-216.html

XSA-217 Issue Description:

> Domains controlling other domains are permitted to map pages owned by
> the domain being controlled.  If the controlling domain unmaps such a
> page without flushing the TLB, and if soon after the domain being
> controlled transfers this page to another PV domain (via
> GNTTABOP_transfer or, indirectly, XENMEM_exchange), and that third
> domain uses the page as a page table, the controlling domain will have
> write access to a live page table until the applicable TLB entry is
> flushed or evicted.  Note that the domain being controlled is
> necessarily HVM, while the controlling domain is PV.

More: https://xenbits.xen.org/xsa/advisory-217.html

XSA-218 Issue Description:

> We have discovered two bugs in the code unmapping grant references.
>
> * When a grant had been mapped twice by a backend domain, and then
> unmapped by two concurrent unmap calls, the frontend may be informed
> that the page had no further mappings when the first call completed rather
> than when the second call completed.
>
> * A race triggerable by an unprivileged guest could cause a grant
> maptrack entry for grants to be "freed" twice.  The ultimate effect of
> this would be for maptrack entries for a single domain to be re-used.

More: https://xenbits.xen.org/xsa/advisory-218.html

XSA-219 Issue Description:

> When using shadow paging, writes to guest pagetables must be trapped and
> emulated, so the shadows can be suitably adjusted as well.
>
> When emulating the write, Xen maps the guests pagetable(s) to make the final
> adjustment and leave the guest's view of its state consistent.
>
> However, when mapping the frame, Xen drops the page reference before
> performing the write.  This is a race window where the underlying frame can
> change ownership.
>
> One possible attack scenario is for the frame to change ownership and to be
> inserted into a PV guest's pagetables.  At that point, the emulated write will
> be an unaudited modification to the PV pagetables whose value is under guest
> control.

More: https://xenbits.xen.org/xsa/advisory-219.html

XSA-220 Issue Description:

> Memory Protection Extensions (MPX) and Protection Key (PKU) are features in
> newer processors, whose state is intended to be per-thread and context
> switched along with all other XSAVE state.
>
> Xen's vCPU context switch code would save and restore the state only
> if the guest had set the relevant XSTATE enable bits.  However,
> surprisingly, the use of these features is not dependent (PKU) or may
> not be dependent (MPX) on having the relevant XSTATE bits enabled.
>
> VMs which use MPX or PKU, and context switch the state manually rather
> than via XSAVE, will have the state leak between vCPUs (possibly,
> between vCPUs in different guests).  This in turn corrupts state in
> the destination vCPU, and hence may lead to weakened protections
>
> Experimentally, MPX appears not to make any interaction with BND*
> state if BNDCFGS.EN is set but XCR0.BND{CSR,REGS} are clear.  However,
> the SDM is not clear in this case; therefore MPX is included in this
> advisory as a precaution.

More: https://xenbits.xen.org/xsa/advisory-220.html

XSA-221 Issue Description:

> When polling event channels, in general arbitrary port numbers can be
> specified.  Specifically, there is no requirement that a polled event
> channel ports has ever been created.  When the code was generalised
> from an earlier implementation, introducing some intermediate
> pointers, a check should have been made that these intermediate
> pointers are non-NULL.  However, that check was omitted.

More: https://xenbits.xen.org/xsa/advisory-221.html

XSA-222 Issue Description:

> Certain actions require removing pages from a guest's P2M
> (Physical-to-Machine) mapping.  When large pages are in use to map
> guest pages in the 2nd-stage page tables, such a removal operation may
> incur a memory allocation (to replace a large mapping with individual
> smaller ones).  If this allocation fails, these errors are ignored by
> the callers, which would then continue and (for example) free the
> referenced page for reuse.  This leaves the guest with a mapping to a
> page it shouldn't have access to.
>
> The allocation involved comes from a separate pool of memory created
> when the domain is created; under normal operating conditions it never
> fails, but a malicious guest may be able to engineer situations where
> this pool is exhausted.

More: https://xenbits.xen.org/xsa/advisory-222.html

XSA-224 Issue Description:

> We have discovered a number of bugs in the code mapping and unmapping
> grant references.
>
> * If a grant is mapped with both the GNTMAP_device_map and
> GNTMAP_host_map flags, but unmapped only with host_map, the device_map
> portion remains but the page reference counts are lowered as though it
> had been removed. This bug can be leveraged cause a page's reference
> counts and type counts to fall to zero while retaining writeable
> mappings to the page.
>
> * Under some specific conditions, if a grant is mapped with both the
> GNTMAP_device_map and GNTMAP_host_map flags, the operation may not
> grab sufficient type counts.  When the grant is then unmapped, the
> type count will be erroneously reduced.  This bug can be leveraged
> cause a page's reference counts and type counts to fall to zero while
> retaining writeable mappings to the page.
>
> * When a grant reference is given to an MMIO region (as opposed to a
> normal guest page), if the grant is mapped with only the
> GNTMAP_device_map flag set, a mapping is created at host_addr anyway.
> This does *not* cause reference counts to change, but there will be no
> record of this mapping, so it will not be considered when reporting
> whether the grant is still in use.

More: https://xenbits.xen.org/xsa/advisory-224.html
2017-06-26 07:01:24 +00:00
Joachim Fasting ab4fa1cce4
tree-wide: prune some dead grsec leaves
The beginning of pruning grsecurity/PaX from the tree.
2017-04-30 12:05:41 +02:00
Joachim Fasting 32b8512e54
grsecurity: discontinue support
Upstream has decided to make -testing patches private, effectively ceasing
free support for grsecurity/PaX [1].  Consequently, we can no longer
responsibly support grsecurity on NixOS.

This patch turns the kernel and patch expressions into build errors and
adds a warning to the manual, but retains most of the infrastructure, in
an effort to make the transition smoother.  For 17.09 all of it should
probably be pruned.

[1]: https://grsecurity.net/passing_the_baton.php
2017-04-28 12:35:15 +02:00
Jason A. Donenfeld b1750d699c linux-chromiumos: remove 3.14
3.14 is no longer supported upstream by kernel.org and thus no longer
receives security patches. The git commit mentioned in this .nix isn't
even available in the linked repository --
https://chromium.googlesource.com/chromiumos/third_party/kernel -- so I
think this .nix might be dead anyway. Finally, it specifies 3.14.0,
which is so ridiculously old (the latest was 3.14.79) that nobody
develops for it.

Fixes: #25145
Supports: #25127
2017-04-23 15:47:46 +02:00
Joachim Fasting 9e6c96f8fc
grsecurity: 4.9.24-201704210851 -> 4.9.24-2201704220732 2017-04-22 16:37:24 +02:00
Joachim Fasting 05911da7bb
grsecurity: 4.9.23-201704181901 -> 4.9.24-201704210851 2017-04-21 15:09:32 +02:00
Joachim Fasting 9902d63e84
grsecurity: 4.9.22-201704120836 -> 4.9.23-201704181901 2017-04-20 00:21:41 +02:00