I dropped autoPatchelfHook because it got confused with the debug
objects, and I can't reproduce the pixman linker errors that caused it
to be introduced in #106988 ("qemu: 5.1.0 -> 5.2.0").
first patch fixes crash in 9p code that occasionally happens also in nixos tests
second patch fixes io errors from discards in aio io engine with virtio-scsi
Tested building qemu_kvm, qemu_full, and qemu_test on x86_64-linux.
Also tested booting a VM generated with nixos-rebuild build-vm.
I wasn't able to test building pkgsMusl.qemu_kvm, because of many
build failures in dependencies.
5e25995295 ("qemu: 2.6.1 -> 2.7.0") added this, because the QEMU
build failed without it. That's no longer the case, so we can bring
back stack protection.
It fails on darwin due to missing `patchelf` and the missing ELFs:
```
/nix/store/...-auto-patchelf-hook/nix-support/setup-hook: line 220: -l: command not found
```
In libc++ starting with LLVM8 there's `<version>` include in `cstddef`:
The following things also align:
* QEMU has a file called `VERSION` in repo root
* QEMU prepends repo root to include path in build
* macOS has a case-insensetive filesystem
All of this combined means that `VERSION` file is included as a header.
Working around this be renaming `VERSION` -> `QEMU_VERSION` to resolve ambiguity.
The problem really only appears on `aarch64-darwin`, since on `x86_64-darwin`
there are no C++ files to compile. The workaround is harmless enough to apply.
This change produces the following warning:
```
... configure: line 619: sysctl: command not found
```
It's benign and sysctl is only useful on MacOS X Leopard:
* https://github.com/qemu/qemu/blob/v5.2.0/configure#L615-L621
Leopard is 13 years old and is not supported by Nix.
The sysctl check is removed in qemu master branch already.
Plus aarch64-darwin is coming in #105026, so there's no reason to force x86_64.
The qemu-user variants as used by binfmt emulation through
`(lib.systems.elaborate lib.systems.examples.aarch64-multiplatform).emulator pkgs`
does not install a .desktop file since qemu 5.2.0. This change allows
the build to continue if deletion of the desktop file fails.
Updates to latest version of QEMU.
The build system has changed to ninja.
There are several configuration flags that aren't enabled. I will
defer to maintainers on those.
Adds autoPatchelfHook for patching output dynamically linked binaries.
qemu: use Nix's meson vs bundled
qemu: remove custom directory locations
It appears that these directories are no longer automatically prefixed
with $out/, so they are now trying to write to the system /etc/, /var/
directories, which is not permitted in sandbox.
The default directories seem to work OK, so using those.
While receiving packets via e1000e_write_packet_to_guest an infinite
loop could be triggered if the receive descriptor had a NULL buffer
address.
A privileged guest user could use this to induce a DoS Scenario.
Fixes: CVE-2020-28916
An assert(3) failure issue was found in the networking helper functions of QEMU. It could occur in the eth_get_gso_type() routine, if a packet does not have a valid networking L3 protocol (ex. IPv4, IPv6) value. A guest user may use this flaw to crash the QEMU process on the host resulting in DoS scenario.
Fixes: CVE-2020-27617
Applications using a different GTK version than the user session don't
work well, and people often run NixOS VM tests on different channels.
Wrapping these GTK binaries is a common way to fix this.
Fixes#69158
Our VM tests and everything related to our virtualisation infrastructure
is currently broken if used with kernel 4.19 or later.
The reason for this is that since 4.19, overlayfs uses the O_NOATIME
flag when opening files in lowerdir and this doesn't play nice with the
way we pass the Nix store to our QEMU guests.
On a NixOS system, paths in the Nix store are typically owned by root
but the QEMU process is usually run by an ordinary user. Using O_NOATIME
on a file where you're not the owner (or superuser) will return with
EPERM (Operation not permitted).
This is exactly what happens in our VM tests, because we're using
overlayfs in the guests to allow writes to the store.
Another implication of this is that the default kernel version for NixOS
19.03 has been reverted to Linux 4.14.
Work on getting this upstream is still ongoing and the patch I posted
previously was incomplete, needs rework and also some more review from
upstream maintainers - in summary: This will take a while.
So instead of rushing in a kernel patch to nixpkgs, which will affect
all users of overlayfs, not just NixOS VM tests, I opted to patch QEMU
for now to ignore the O_NOATIME flag in 9p.
I think this is also the least impacting change, because even if you
care about whether access times are written or not, you get the same
behaviour as with Linux 4.19 in conjunction with QEMU.
Signed-off-by: aszlig <aszlig@nix.build>
Fixes: https://github.com/NixOS/nixpkgs/issues/54509
You can use stdenv.hostPlatform.emulator to get an executable that
runs cross-built binaries. This could be any emulator. For instance,
we use QEMU to emulate Linux targets and Wine to emulate Windows
targets. To work with qemu, we need to support custom targets.
I’ve reworked the cross tests in pkgs/test/cross to use this
functionality.
Also, I’ve used talloc to cross-execute with the emulator. There
appears to be a cross-execute for all waf builds. In the future, it
would be nice to set this for all waf builds.
Adds stdenv.hostPlatform.qemuArch attrbute to get the qemuArch for
each platform.
Since years I'm not maintaining anything of the list below other
than some updates when I needed them for some reason. Other people
is doing that maintenance on my behalf so I better take me out but
for very few packages. Finally!
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
