This is the simplest way to reenable the use of BLCR
(which at present requires linux version >3.12 <3.18)
until we find a better solution.
This reverts commit 6a9e765e27.
Cleanup:
- Restructure & add some commentary
- Remove redundant option specs given the auto config
constraints (some are left in for documentation purposes)
Changes:
- GRKERNSEC_CONFIG_VIRT_HOST -> GUEST
The former deselects paravirtualization and friends
- PAX_LATENT_ENTROPY n -> y (implied by auto)
- GRKERNSEC_ACL_HIDEKERN y -> n
Possibly useless with redistribution
With the default kernel and thus with the build I have tested in
74ec94bfa2, we get an error during
modules_install:
make[2]: execvp: /nix/store/.../bin/bash: Argument list too long
I haven't noticed this build until I actually tried booting using this
kernel because make didn't fail here.
The reason this happens within Nix and probably didn't yet surface in
other distros is that programs only have a limited amount of memory
available for storing the environment and the arguments.
Environment variables however are quite common on Nix and thus we
stumble on problems like this way earlier - in this case Linux 4.8 - but
I have noticed this in 4.7-next as well already.
The fix is far from perfect and suffers performance overhead because we
now run grep for every *.mod file instead of passing all *.mod files
into one single invocation of grep.
But comparing the performance overhead (around 1s on my machine) with
the overall build time of the kernel I think the overhead really is
neglicible.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Tested by only building the linux_testing attribute, but haven't yet
tested it in production.
I've also fixed the extraMeta.branch attribute.
Verified-with-PGP: ABAF 11C6 5A29 70B1 30AB E3C4 79BE 3E43 0041 1886
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Previously, features.grsecurity wasn't actually set due to a bug in the
grsec builder. We now rely on the generic kernel builder to set features
from kernelPatches.
List of what to enable taken from https://lwn.net/Articles/672587/.
This doesn't change the resulting x86 configs, but is more useful for
other architectures. For instance, POSIX_MQUEUE is currently missing
on ARM.
glibc 2.24 deprecated readdir_r, breaking the perf build:
$ nix-build -A linuxPackages.perf
...
CC util/event.o
CC util/evlist.o
util/event.c: In function '__event__synthesize_thread':
util/event.c:448:2: error: 'readdir_r' is deprecated [-Werror=deprecated-declarations]
while (!readdir_r(tasks, &dirent, &next) && next) {
^
In file included from /nix/store/8ic0jwg3p5vcwx52k4781n987hmv0bks-glibc-2.24-dev/include/features.h:368:0,
from /nix/store/8ic0jwg3p5vcwx52k4781n987hmv0bks-glibc-2.24-dev/include/stdint.h:25,
from /nix/store/jsazxc1b86g2ww569ziwhhvkz8z43vjd-gcc-5.4.0/lib/gcc/x86_64-unknown-linux-gnu/5.4.0/include/stdint.h:9,
from /tmp/nix-build-perf-linux-4.4.19.drv-0/linux-4.4.19/tools/include/linux/types.h:6,
from util/event.c:1:
/nix/store/8ic0jwg3p5vcwx52k4781n987hmv0bks-glibc-2.24-dev/include/dirent.h:189:12: note: declared here
extern int __REDIRECT (readdir_r,
^
util/event.c: In function 'perf_event__synthesize_threads':
util/event.c:586:2: error: 'readdir_r' is deprecated [-Werror=deprecated-declarations]
while (!readdir_r(proc, &dirent, &next) && next) {
Fix by adding -Wno-error=deprecated-declarations compile flag.
Until we've made sure that most things actually work out of the box, we
need to give people a way of continuing to use the system without
completely disabling grsecurity.
Set sysctl kernel.pax.softmode=1 or boot with pax.softmode=1
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.
