- 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>
- Use fetchFromGitHub
- Some files in bin/ are now shell scripts, so skip patchelf on any
non-ELF files.
With this U-Boot can be successfully launched on a RPi 3.
Without these patches, specifically the
0001-Do-not-assume-fixed-line-lengths-for-proc-acpi-wakeu.patch (wakeu
patch typo from upstream,) acpitool will consume 100% CPU when reading
long lines (>40 characters) like:
ADP1 S4 *disabled platform:ACPI0003:00
In line with the Nixpkgs manual.
A mechanical change, done with this command:
find pkgs -name "*.nix" | \
while read f; do \
sed -e 's/description\s*=\s*"\([a-z]\)/description = "\u\1/' -i "$f"; \
done
I manually skipped some:
* Descriptions starting with an abbreviation, a user name or package name
* Frequently generated expressions (haskell-packages.nix)
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.
