Quite some fixing was needed to get this to work.
Changes in VirtualBox and additions:
- VirtualBox is no longer officially supported on 32-bit hosts so i686-linux is removed from platforms
for VirtualBox and the extension pack. 32-bit additions still work.
- There was a refactoring of kernel module makefiles and two resulting bugs affected us which had to be patched.
These bugs were reported to the bug tracker (see comments near patches).
- The Qt5X11Extras makefile patch broke. Fixed it to apply again, making the libraries logic simpler
and more correct (it just uses a different base path instead of always linking to Qt5X11Extras).
- Added a patch to remove "test1" and "test2" kernel messages due to forgotten debugging code.
- virtualbox-host NixOS module: the VirtualBoxVM executable should be setuid not VirtualBox.
This matches how the official installer sets it up.
- Additions: replaced a for loop for installing kernel modules with just a "make install",
which seems to work without any of the things done in the previous code.
- Additions: The package defined buildCommand which resulted in phases not running, including RUNPATH
stripping in fixupPhase, and installPhase was defined which was not even run. Fixed this by
refactoring using phases. Had to set dontStrip otherwise binaries were broken by stripping.
The libdbus path had to be added later in fixupPhase because it is used via dlopen not directly linked.
- Additions: Added zlib and libc to patchelf, otherwise runtime library errors result from some binaries.
For some reason the missing libc only manifested itself for mount.vboxsf when included in the initrd.
Changes in nixos/tests/virtualbox:
- Update the simple-gui test to send the right keys to start the VM. With VirtualBox 5
it was enough to just send "return", but with 6 the Tools thing may be selected by
default. Send "home" to reliably select Tools, "down" to move to the VM and "return"
to start it.
- Disable the VirtualBox UART by default because it causes a crash due to a regression
in VirtualBox (specific to software virtualization and serial port usage). It can
still be enabled using an option but there is an assert that KVM nested virtualization
is enabled, which works around the problem (see below).
- Add an option to enable nested KVM virtualization, allowing VirtualBox to use hardware
virtualization. This works around the UART problem and also allows using 64-bit
guests, but requires a kernel module parameter.
- Add an option to run 64-bit guests. Tested that the tests pass with that. As mentioned
this requires KVM nested virtualization.
Upstream issue: https://github.com/zfsonlinux/zfs/issues/8697
Upstream fix (zfs repo): 782dfae3218b5f2029ce78722b999cb04e8ef001
This can't be applied cleanly as a patch, since spl has been moved
into the zfs repo since 0.7.13.
The purpose of this LSM is to allow processes to drop to a less privileged
user id without having to grant them full CAP_SETUID (or use file caps).
The LSM allows configuring a whitelist policy of permitted from:to uid
transitions. The policy is enforced upon calls to setuid(2) and related
syscalls.
Policies are configured through securityfs by writing to
- safesetid/add_whitelist_policy ; and
- safesetid/flush_whitelist_policies
A process attempting a transition not permitted by current policy is killed
(to avoid accidentally running with higher privileges than intended).
A uid that has a configured policy is prevented from obtaining auxiliary
setuid privileges (e.g., setting up user namespaces).
See also: https://www.kernel.org/doc/html/latest/admin-guide/LSM/SafeSetID.html
In 5.0er these function were removed from the public interface also zfs needs
them for AVX/AES-NI support. Without this patch for example throughput on a
encrypted zfs dataset drops to 200 MB/s from 1.2 GB/s. These functions were
removed as their was no user within the linux kernel tree itself.
Requires a minor tweak to the deadlock detector patch (the file was
renamed in the upstream repo).
bcc now also wants a copy of libbpf, which it doesn't have in the source
release tarball. Clone a copy from GiHub that's synchronized with the
release, and put it in place.
Tested on Linux 5.1 (with bpftrace as well).
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Newer versions of perf in Linux 5.1+ support disassembling and
annotating eBPF programs inside the kernel. In order to do this, it uses
libbfd's support for bpf disassembly. There are two parts: libopcodes
and libbfd.
The 'perf' build system seems to expect libopcodes/libbfd to go "hand in
hand" -- always together, if one or the other is installed. If the build
system detects libbfd is available, then an import of <dis-asm.h> is
performed, but this fails since it wasn't in the buildInput. Fixing this
should be an easy, backwards-compatible change.
Fixes #60891, allowing linuxPackages_testing.perf to build again
(currently kernel version 5.1.0-rc7).
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Update bpftrace to the latest pre-release, with a real version number.
The most notable change now is that bpftrace can use a stable version of
the 'bcc' toolchain in order to build, meaning no more hacks are needed
to clone the source code and fix up the build system, etc. This
simplifies things greatly and removes the old bcc-source patch.
Similarly, we can remove our custom gtests patch (which disabled the
build) by just passing -DBUILD_TESTING=FALSE when running cmake. This
was also added upstream recently.
However, something does still need to be fixed, at a cost: bpftrace
requires the kernel -dev package because it wants both objects and
include directories (some files are only shipped in one or the other).
Therefore, we remove the dependency on linuxHeaders and instead use
kernel.dev as the sole input to the build.
This is both a positive and a negative: the positive is that tools work
without annoying fatal errors, and that the bpf toolchain is
synchronized to the linuxPackages.kernel derivation it was built
against. The downside is that the .dev expression is much heavier as a
dependency, so bpftrace is now closer to 700mb in closure size. (This
especially hurts across kernel upgrades requiring a whole new rebuild,
especially if you have existing nixos generations that won't GC, etc.)
We probably want to slim this down substantially in the future (and
there may be a few ways to do that), but as this will probably also
touch bcc, and as a first cut of the pre-releases, this is probably fine
while we work out other kinks.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
