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
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
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
The first release in the 4.9 branch.
I've also migrated my update scripts to SHA-512 so that'll
be the hash of choice for grsec packages going forward.
In `scripts/Makefile.modinst`, the code that generates the list of
modules to install passes file names via the command line. When
installing a grsecurity kernel, this list appears to exceed the
shell's argument list limit, as in
make[2]: execvp: /nix/store/[...]-bash-4.3-p46/bin/bash: Argument list too long
The build does not fail, however, but the list of modules to be installed ends
up being empty. Thus, the resulting kernel package output contains no modules,
rendering it useless.
We work around this by patching the makefile to use `find -exec` to
process files. Why this would occur for grsecurity and not other
kernels is unknown, most likely there's something *else* that is
actually causing this behaviour, so this is a temporary fix until that
cause is found.
Fixes https://github.com/NixOS/nixpkgs/issues/20490
This reverts commit e02173c70c, reversing
changes made to c2b4a0d266.
Breaks all grsec packages; Not having binary substitutes for no good
reason is disruptive to my workflow, so I'll just revert this for now.
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>
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.
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 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)
