nixpkgs/pkgs/os-specific/linux/kernel/patches.nix

155 lines
4.2 KiB
Nix
Raw Normal View History

{ stdenv, fetchurl, fetchpatch, pkgs }:
let
makeTuxonicePatch = { version, kernelVersion, sha256,
url ? "http://tuxonice.nigelcunningham.com.au/downloads/all/tuxonice-for-linux-${kernelVersion}-${version}.patch.bz2" }:
{ name = "tuxonice-${kernelVersion}";
patch = stdenv.mkDerivation {
name = "tuxonice-${version}-for-${kernelVersion}.patch";
src = fetchurl {
inherit url sha256;
};
phases = [ "installPhase" ];
installPhase = ''
source $stdenv/setup
bunzip2 -c $src > $out
'';
};
};
grsecurity: implement a single NixOS kernel This patch replaces the old grsecurity kernels with a single NixOS specific grsecurity kernel. This kernel is intended as a general purpose kernel, tuned for casual desktop use. Providing only a single kernel may seem like a regression compared to offering a multitude of flavors. It is impossible, however, to effectively test and support that many options. This is amplified by the reality that very few seem to actually use grsecurity on NixOS, meaning that bugs go unnoticed for long periods of time, simply because those code paths end up never being exercised. More generally, it is hopeless to anticipate imagined needs. It is better to start from a solid foundation and possibly add more flavours on demand. While the generic kernel is intended to cover a wide range of use cases, it cannot cover everything. For some, the configuration will be either too restrictive or too lenient. In those cases, the recommended solution is to build a custom kernel --- this is *strongly* recommended for security sensitive deployments. Building a custom grsec kernel should be as simple as ```nix linux_grsec_nixos.override { extraConfig = '' GRKERNSEC y PAX y # and so on ... ''; } ``` The generic kernel should be usable both as a KVM guest and host. When running as a host, the kernel assumes hardware virtualisation support. Virtualisation systems other than KVM are *unsupported*: users of non-KVM systems are better served by compiling a custom kernel. Unlike previous Grsecurity kernels, this configuration disables `/proc` restrictions in favor of `security.hideProcessInformation`. Known incompatibilities: - ZFS: can't load spl and zfs kernel modules; claims incompatibility with KERNEXEC method `or` and RAP; changing to `bts` does not fix the problem, which implies we'd have to disable RAP as well for ZFS to work - `kexec()`: likely incompatible with KERNEXEC (unverified) - Xen: likely incompatible with KERNEXEC and UDEREF (unverified) - Virtualbox: likely incompatible with UDEREF (unverified)
2016-06-13 23:04:56 +01:00
grsecPatch = { grbranch ? "test", grver ? "3.1", kver, grrev, sha256 }: rec {
name = "grsecurity-${grver}-${kver}-${grrev}";
# Pass these along to allow the caller to determine compatibility
inherit grver kver grrev;
patch = fetchurl {
urls = [
"https://grsecurity.net/${grbranch}/${name}.patch"
# When updating versions/hashes, ALWAYS use the official
# version; we use this mirror only because upstream removes
# source files immediately upon releasing a new version ...
"https://raw.githubusercontent.com/slashbeast/grsecurity-scrape/master/${grbranch}/${name}.patch"
];
grsecurity: implement a single NixOS kernel This patch replaces the old grsecurity kernels with a single NixOS specific grsecurity kernel. This kernel is intended as a general purpose kernel, tuned for casual desktop use. Providing only a single kernel may seem like a regression compared to offering a multitude of flavors. It is impossible, however, to effectively test and support that many options. This is amplified by the reality that very few seem to actually use grsecurity on NixOS, meaning that bugs go unnoticed for long periods of time, simply because those code paths end up never being exercised. More generally, it is hopeless to anticipate imagined needs. It is better to start from a solid foundation and possibly add more flavours on demand. While the generic kernel is intended to cover a wide range of use cases, it cannot cover everything. For some, the configuration will be either too restrictive or too lenient. In those cases, the recommended solution is to build a custom kernel --- this is *strongly* recommended for security sensitive deployments. Building a custom grsec kernel should be as simple as ```nix linux_grsec_nixos.override { extraConfig = '' GRKERNSEC y PAX y # and so on ... ''; } ``` The generic kernel should be usable both as a KVM guest and host. When running as a host, the kernel assumes hardware virtualisation support. Virtualisation systems other than KVM are *unsupported*: users of non-KVM systems are better served by compiling a custom kernel. Unlike previous Grsecurity kernels, this configuration disables `/proc` restrictions in favor of `security.hideProcessInformation`. Known incompatibilities: - ZFS: can't load spl and zfs kernel modules; claims incompatibility with KERNEXEC method `or` and RAP; changing to `bts` does not fix the problem, which implies we'd have to disable RAP as well for ZFS to work - `kexec()`: likely incompatible with KERNEXEC (unverified) - Xen: likely incompatible with KERNEXEC and UDEREF (unverified) - Virtualbox: likely incompatible with UDEREF (unverified)
2016-06-13 23:04:56 +01:00
inherit sha256;
2013-05-11 06:44:30 +01:00
};
features.grsecurity = true;
grsecurity: implement a single NixOS kernel This patch replaces the old grsecurity kernels with a single NixOS specific grsecurity kernel. This kernel is intended as a general purpose kernel, tuned for casual desktop use. Providing only a single kernel may seem like a regression compared to offering a multitude of flavors. It is impossible, however, to effectively test and support that many options. This is amplified by the reality that very few seem to actually use grsecurity on NixOS, meaning that bugs go unnoticed for long periods of time, simply because those code paths end up never being exercised. More generally, it is hopeless to anticipate imagined needs. It is better to start from a solid foundation and possibly add more flavours on demand. While the generic kernel is intended to cover a wide range of use cases, it cannot cover everything. For some, the configuration will be either too restrictive or too lenient. In those cases, the recommended solution is to build a custom kernel --- this is *strongly* recommended for security sensitive deployments. Building a custom grsec kernel should be as simple as ```nix linux_grsec_nixos.override { extraConfig = '' GRKERNSEC y PAX y # and so on ... ''; } ``` The generic kernel should be usable both as a KVM guest and host. When running as a host, the kernel assumes hardware virtualisation support. Virtualisation systems other than KVM are *unsupported*: users of non-KVM systems are better served by compiling a custom kernel. Unlike previous Grsecurity kernels, this configuration disables `/proc` restrictions in favor of `security.hideProcessInformation`. Known incompatibilities: - ZFS: can't load spl and zfs kernel modules; claims incompatibility with KERNEXEC method `or` and RAP; changing to `bts` does not fix the problem, which implies we'd have to disable RAP as well for ZFS to work - `kexec()`: likely incompatible with KERNEXEC (unverified) - Xen: likely incompatible with KERNEXEC and UDEREF (unverified) - Virtualbox: likely incompatible with UDEREF (unverified)
2016-06-13 23:04:56 +01:00
};
in
rec {
2015-01-13 23:49:14 +00:00
bridge_stp_helper =
{ name = "bridge-stp-helper";
patch = ./bridge-stp-helper.patch;
};
no_xsave =
{ name = "no-xsave";
patch = ./no-xsave.patch;
features.noXsave = true;
};
mips_fpureg_emu =
{ name = "mips-fpureg-emulation";
patch = ./mips-fpureg-emulation.patch;
};
mips_fpu_sigill =
{ name = "mips-fpu-sigill";
patch = ./mips-fpu-sigill.patch;
};
mips_ext3_n32 =
{ name = "mips-ext3-n32";
patch = ./mips-ext3-n32.patch;
};
modinst_arg_list_too_long =
{ name = "modinst-arglist-too-long";
patch = ./modinst-arg-list-too-long.patch;
};
ubuntu_fan_4_4 =
{ name = "ubuntu-fan";
patch = ./ubuntu-fan-4.4.patch;
};
ubuntu_unprivileged_overlayfs =
{ name = "ubuntu-unprivileged-overlayfs";
patch = ./ubuntu-unprivileged-overlayfs.patch;
};
tuxonice_3_10 = makeTuxonicePatch {
version = "2013-11-07";
kernelVersion = "3.10.18";
sha256 = "00b1rqgd4yr206dxp4mcymr56ymbjcjfa4m82pxw73khj032qw3j";
};
grsecurity: implement a single NixOS kernel This patch replaces the old grsecurity kernels with a single NixOS specific grsecurity kernel. This kernel is intended as a general purpose kernel, tuned for casual desktop use. Providing only a single kernel may seem like a regression compared to offering a multitude of flavors. It is impossible, however, to effectively test and support that many options. This is amplified by the reality that very few seem to actually use grsecurity on NixOS, meaning that bugs go unnoticed for long periods of time, simply because those code paths end up never being exercised. More generally, it is hopeless to anticipate imagined needs. It is better to start from a solid foundation and possibly add more flavours on demand. While the generic kernel is intended to cover a wide range of use cases, it cannot cover everything. For some, the configuration will be either too restrictive or too lenient. In those cases, the recommended solution is to build a custom kernel --- this is *strongly* recommended for security sensitive deployments. Building a custom grsec kernel should be as simple as ```nix linux_grsec_nixos.override { extraConfig = '' GRKERNSEC y PAX y # and so on ... ''; } ``` The generic kernel should be usable both as a KVM guest and host. When running as a host, the kernel assumes hardware virtualisation support. Virtualisation systems other than KVM are *unsupported*: users of non-KVM systems are better served by compiling a custom kernel. Unlike previous Grsecurity kernels, this configuration disables `/proc` restrictions in favor of `security.hideProcessInformation`. Known incompatibilities: - ZFS: can't load spl and zfs kernel modules; claims incompatibility with KERNEXEC method `or` and RAP; changing to `bts` does not fix the problem, which implies we'd have to disable RAP as well for ZFS to work - `kexec()`: likely incompatible with KERNEXEC (unverified) - Xen: likely incompatible with KERNEXEC and UDEREF (unverified) - Virtualbox: likely incompatible with UDEREF (unverified)
2016-06-13 23:04:56 +01:00
grsecurity_testing = grsecPatch
{ kver = "4.8.13";
grrev = "201612082118";
sha256 = "0cvw6sbinzlcxap8mf934ksgksgdd8w8pf8jfp82fbyiz53klfn1";
};
grsecurity: implement a single NixOS kernel This patch replaces the old grsecurity kernels with a single NixOS specific grsecurity kernel. This kernel is intended as a general purpose kernel, tuned for casual desktop use. Providing only a single kernel may seem like a regression compared to offering a multitude of flavors. It is impossible, however, to effectively test and support that many options. This is amplified by the reality that very few seem to actually use grsecurity on NixOS, meaning that bugs go unnoticed for long periods of time, simply because those code paths end up never being exercised. More generally, it is hopeless to anticipate imagined needs. It is better to start from a solid foundation and possibly add more flavours on demand. While the generic kernel is intended to cover a wide range of use cases, it cannot cover everything. For some, the configuration will be either too restrictive or too lenient. In those cases, the recommended solution is to build a custom kernel --- this is *strongly* recommended for security sensitive deployments. Building a custom grsec kernel should be as simple as ```nix linux_grsec_nixos.override { extraConfig = '' GRKERNSEC y PAX y # and so on ... ''; } ``` The generic kernel should be usable both as a KVM guest and host. When running as a host, the kernel assumes hardware virtualisation support. Virtualisation systems other than KVM are *unsupported*: users of non-KVM systems are better served by compiling a custom kernel. Unlike previous Grsecurity kernels, this configuration disables `/proc` restrictions in favor of `security.hideProcessInformation`. Known incompatibilities: - ZFS: can't load spl and zfs kernel modules; claims incompatibility with KERNEXEC method `or` and RAP; changing to `bts` does not fix the problem, which implies we'd have to disable RAP as well for ZFS to work - `kexec()`: likely incompatible with KERNEXEC (unverified) - Xen: likely incompatible with KERNEXEC and UDEREF (unverified) - Virtualbox: likely incompatible with UDEREF (unverified)
2016-06-13 23:04:56 +01:00
# This patch relaxes grsec constraints on the location of usermode helpers,
# e.g., modprobe, to allow calling into the Nix store.
grsecurity_nixos_kmod =
{
name = "grsecurity-nixos-kmod";
patch = ./grsecurity-nixos-kmod.patch;
};
crc_regression =
{ name = "crc-backport-regression";
patch = ./crc-regression.patch;
};
genksyms_fix_segfault =
{ name = "genksyms-fix-segfault";
patch = ./genksyms-fix-segfault.patch;
};
chromiumos_Kconfig_fix_entries_3_14 =
{ name = "Kconfig_fix_entries_3_14";
patch = ./chromiumos-patches/fix-double-Kconfig-entry-3.14.patch;
};
chromiumos_Kconfig_fix_entries_3_18 =
{ name = "Kconfig_fix_entries_3_18";
patch = ./chromiumos-patches/fix-double-Kconfig-entry-3.18.patch;
};
chromiumos_no_link_restrictions =
{ name = "chromium-no-link-restrictions";
patch = ./chromiumos-patches/no-link-restrictions.patch;
};
chromiumos_mfd_fix_dependency =
{ name = "mfd_fix_dependency";
patch = ./chromiumos-patches/mfd-fix-dependency.patch;
};
hiddev_CVE_2016_5829 =
{ name = "hiddev_CVE_2016_5829";
patch = fetchpatch {
url = "https://sources.debian.net/data/main/l/linux/4.6.3-1/debian/patches/bugfix/all/HID-hiddev-validate-num_values-for-HIDIOCGUSAGES-HID.patch";
sha256 = "14rm1qr87p7a5prz8g5fwbpxzdp3ighj095x8rvhm8csm20wspyy";
};
};
cpu-cgroup-v2 = import ./cpu-cgroup-v2-patches;
lguest_entry-linkage =
{ name = "lguest-asmlinkage.patch";
patch = fetchpatch {
url = "https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git"
+ "/patch/drivers/lguest/x86/core.c?id=cdd77e87eae52";
sha256 = "04xlx6al10cw039av6jkby7gx64zayj8m1k9iza40sw0fydcfqhc";
};
};
}