For instance, the current 3.10 kernel build fails at the end with:
unused option: BRCMFMAC_PCIE
unused option: FW_LOADER_USER_HELPER_FALLBACK
unused option: KEXEC_FILE
unused option: RANDOMIZE_BASE
However, it's not obvious that only the _last_ one is actually fatal to
the build. After this change it's at least somewhat better:
warning: unused option: BRCMFMAC_PCIE
warning: unused option: FW_LOADER_USER_HELPER_FALLBACK
warning: unused option: KEXEC_FILE
error: unused option: RANDOMIZE_BASE
Adds basic support for Intel GMA3600/3650 (Intel Cedar Trail) platforms
and support for GMA600 (Intel Moorestown/Oaktrail) platforms with LVDS
ports via the gma500_gfx module.
Resolves#14727Closes#17519
While useless for binaries within the Nix store, user xattrs are a convenient
alternative for setting PaX flags to executables outside of the store.
To use disable secure memory protections for a non-store file foo, do
$ setfattr -n user.pax.flags -v em foo
Fixed for all available 4.x series kernels.
From CVE-2016-5829:
Multiple heap-based buffer overflows in the hiddev_ioctl_usage function
in drivers/hid/usbhid/hiddev.c in the Linux kernel through 4.6.3 allow
local users to cause a denial of service or possibly have unspecified
other impact via a crafted (1) HIDIOCGUSAGES or (2) HIDIOCSUSAGES ioctl
call.
This enables a few features that should be useful and safe (they're
all used by the default Ubuntu kernel config), in particular zswap,
wakelocks, kernel load address randomization, userfaultfd (useful for
QEMU), paravirtualized spinlocks and automatic process group
scheduling.
Also removes some configuration conditional on kernel versions that we
no longer support.
- Add a patch to unset CONFIG_LOCALVERSION in the v7 build.
- Copy all the device trees to match the upstream names so U-Boot can
find them. (This is a hack.)
The config option DEVPTS_MULTIPLE_INSTANCES now no longer exists since
torvalds/linux@eedf265aa0.
Built successfully on my Hydra instance:
https://headcounter.org/hydra/log/r4n6sv0zld0aj65r7l494757s2r8w8sr-linux-4.7-rc6.drv
Verified unpacked tarball with GnuPG:
ABAF 11C6 5A29 70B1 30AB E3C4 79BE 3E43 0041 1886
gpg: Signature made Mon 04 Jul 2016 08:13:05 AM CEST
gpg: using RSA key 79BE3E4300411886
gpg: Good signature from "Linus Torvalds <torvalds@linux-foundation.org>"
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
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)
Per my own testing, the NixOS grsecurity kernel works both as a
KVM-based virtualisation host and guest; there appears to be no good
reason to making these conditional on `features.grsecurity`.
More generally, it's unclear what `features.grsecurity` *means*. If
someone configures a grsecurity kernel in such a fashion that it breaks
KVM support, they should know to disable KVM themselves.
This was presumably set for grsecurity compatibility, but now appears
redundant. Grsecurity does not expect nor require /dev/kmem to be
present and so it makes little sense to continue making its inclusion in
the standard kernel dependent on grsecurity.
More generally, given the large number of possible grsecurity
configurations, it is unclear what `features.grsecurity` even
*means* and its use should be discouraged.
Also revert to using the grsecurity-scrape mirror; relying on upstream
just isn't viable. Lately, updates have been so frequent that a new
version is released before Hydra even gets around to building the
previous one.
It takes some extra 13MB (and in dev, not out), but allows perf to show kernel
symbols when profiling. I think it is worth it.
In my NixOS, I refer to it in the system derivation, for easy telling to perf
through /run/booted-system/vmlinux:
system.extraSystemBuilderCmds = ''
ln -s ${config.boot.kernelPackages.kernel.dev}/vmlinux $out/vmlinux
'';
From now on, only the testing branch of grsecurity will be supported.
Additionally, use only patches from upstream.
It's impossible to provide meaningful support for grsecurity stable.
First, because building and testing \(m \times n \times z) [1], packages
is infeasible. Second, because stable patches are only available from
upstream for-pay, making us reliant on third-parties for patches. In
addition to creating yet more work for the maintainers, using stable
patches provided by a third-party goes against the wishes of upstream.
nixpkgs provides the tools necessary to build grsecurity kernels for any
version the user chooses, however, provided they pay for, or otherwise
acquire, the patch themselves.
Eventually, we'll want to remove the now obsolete top-level attributes,
but leave them in for now to smoothe migration (they have been removed
from top-level/release.nix, though, because it makes no sense to have
them there).
[1]: where \(m\) is the number of grsecurity flavors, \(n\) is the
number of kernel versions, and z is the size of the `linuxPackages` set
Patch drivers/crypto/qat/qat_common/Makefile so that qat_asym_algs.o
explicitly depends on headers qat_rsaprivkey-asn1.h and qat_rsapubkey-asn1.h
Hopefully fixes#14595
- Enable BPF_SYSCALL and BPF_EVENTS
- Build modules for NET_CLS_BPF and NET_ACT_BPF
With these config options we can leverage the full potential of BPF for
tracing and instrumenting Linux systems, for example using
libraries/tools like those provided by the bcc project.
First, The patch is outdated, I failed to find it anywhere in the mirror repos.
Second, the build fails, and while it may be "fixed" by ad-hoc patching (it
appears to simply need some missing includes), this would mean shipping a
potentially insecure software package. Given that the only reason to use
grsecurity is security, this is both misleading and exposes users to undue risk.
Finally, the build has been broken for quite a long time with no complaints,
leading me to believe that the number of actual users is quite low.
The following parameters are now available:
* hardeningDisable
To disable specific hardening flags
* hardeningEnable
To enable specific hardening flags
Only the cc-wrapper supports this right now, but these may be reused by
other wrappers, builders or setup hooks.
cc-wrapper supports the following flags:
* fortify
* stackprotector
* pie (disabled by default)
* pic
* strictoverflow
* format
* relro
* bindnow
Since commit 48f51f1185 we let the kernel build system compress the
modules, which makes the original strip expression not work. Let the
kernel build system strip them as well so they get stripped.
This hopefully fixes intermittent initrd failures where udevd cannot
create a Unix domain socket:
machine# running udev...
machine# error getting socket: Address family not supported by protocol
machine# error initializing udev control socket
machine# error getting socket: Address family not supported by protocol
The "unix" kernel module is supposed to be loaded automatically, and
clearly that works most of the time, but maybe there is a race
somewhere. In any case, no sane person would run a kernel without Unix
domain sockets, so we may as well make it builtin.
http://hydra.nixos.org/build/30001448
This reverts commit 79bd2b08ee.
The commit was from an upstream commit anyway and has since been applied
to mainline.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Regression introduced by 03a3a905b9.
Our default config includes all modules and since torvalds/linux@47ca6ec
this results in a regression due to in a circular dependency between
libcfs and LNet:
depmod: ERROR: Found 2 modules in dependency cycles!
depmod: ERROR: Cycle detected: lnet -> libcfs -> lnet
The discussion regarding this in the LKML is here:
https://lkml.org/lkml/2015/11/2/388
So this adds a patch which is not yet included in mainline and has been
submitted to the LKML at:
https://lkml.org/lkml/2015/11/6/987
Built successfully via "nix-build -A linux-testing".
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
