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
(cherry picked from commit ba52ae5048)
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
* $out/bin/qemu-kvm should point to qemu-system-aarch64 on aarch64, libvirt expect it
* makeWrapper codes are separated as some architectures might require additional command flags (https://github.com/NixOS/nixpkgs/issues/31606#issuecomment-349675127)
* x86_64-on-i686 is not a native emulation and not supported by KVM, so it is removed from the list
This reverts commit 3a4e2376e4.
The reverted commit caused the fix for CVE-2016-9602 not to be applied
for qemu_test because it conflicts with the force-uid0-on-9p.patch.
So with the rebase of the patch on top of the changes of the
CVE-2016-9602.patch, both patches no longer conflict with each other.
I've tested this with the "misc" NixOS test and it succeeds.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
New upstream patch function and patches for fixing a bug in the patch for
CVE-2017-5667 and the following security issues:
* CVE-2016-7907
* CVE-2016-9602
* CVE-2016-10155
* CVE-2017-2620
* CVE-2017-2630
* CVE-2017-5525
* CVE-2017-5526
* CVE-2017-5579
* CVE-2017-5856
* CVE-2017-5857
* CVE-2017-5987
* CVE-2017-6058
Fixes:
* CVE-2017-2615
* CVE-2017-5667
* CVE-2017-5898
* CVE-2017-5931
* CVE-2017-5973
We are vulnerable to even more CVEs but those are either not severe like
memory leaks in obscure situations or upstream hasn't acknowledged the
patch yet.
cc #23072
Enables support for accessing files over HTTP:
qemu-system-x86_64 -drive media=cdrom,file=http://host/path.iso,readonly
Increases the closures size from 445 to 447 MiB.
The reason to patch QEMU is that with latest Nix, tests like "printing"
or "misc" fail because they expect the store paths to be owned by uid 0
and gid 0.
Starting with NixOS/nix@5e51ffb1c265e16486fcdd888ce4a04db9e5552b, Nix
builds inside of a new user namespace. Unfortunately this also means
that bind-mounted store paths that are part of the derivation's inputs
are no longer owned by uid 0 and gid 0 but by uid 65534 and gid 65534.
This in turn causes things like sudo or cups to fail with errors about
insecure file permissions.
So in order to avoid that, let's make sure the VM always gets files
owned by uid 0 and gid 0 and does a no-op when doing a chmod on a store
path.
In addition, this adds a virtualisation.qemu.program option so that we
can make sure that we only use the patched version if we're *really*
running NixOS VM tests (that is, whenever we have imported
test-instrumentation.nix).
Tested against the "misc" and "printing" tests.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
xeji