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.
Previously we could not override the input packages to docker at all as
that had been shadowed due to the usage of inherit in all-package.nix.
We are now mixing the "variable" variables for the build and the
dependency declarations for the package and using callPackage as if each
of the docker packages would be separate files that we evaluate.
This now enables overriding e.g. iptables for a single verison of
docker which previously was not feasible without importing the
default.nix again (and passing different arguments).
> pkgs.docker.override { iptables = pkgs.iptables-nftables-compat; }
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.
The `platform` field is pointless nesting: it's just stuff that happens
to be defined together, and that should be an implementation detail.
This instead makes `linux-kernel` and `gcc` top level fields in platform
configs. They join `rustc` there [all are optional], which was put there
and not in `platform` in anticipation of a change like this.
`linux-kernel.arch` in particular also becomes `linuxArch`, to match the
other `*Arch`es.
The next step after is this to combine the *specific* machines from
`lib.systems.platforms` with `lib.systems.examples`, keeping just the
"multiplatform" ones for defaulting.
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.
Thanks to Repology / Alpine Linux I noticed that the GNS3 team continued
the development. From their README:
> This is a continuation of VPCS, based on the last development version
> and improved with patches wrote by various people from the community.
> The original VPCS code, which is unfortunately not maintained anymore,
> can be viewed on https://sourceforge.net/p/vpcs/code/
I forogt to update the `commit` value in 8884729, which is why this the
version output was wrong:
```
❯ ./result/bin/containerd -v
containerd github.com/containerd/containerd v1.4.3 7ad184331fa3e55e52b890ea95e65ba581ae3429
```
This change corrects it.
```
❯ ./result/bin/containerd -v
containerd github.com/containerd/containerd v1.4.3 269548fa27e0089a8b8278fc4fc781d7f65a939b
```
Access controls for the shim’s API socket verified that the connecting
process had an effective UID of 0, but did not otherwise restrict
access to the abstract Unix domain socket. This would allow malicious
containers running in the same network namespace as the shim, with an
effective UID of 0 but otherwise reduced privileges, to cause new
processes to be run with elevated privileges.
Fixes: CVE-2020-15257
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
