OVMF{,CODE,VARS}.fd are now available in a dedicated fd output, greatly
reducing the closure in the common case where only those files are used (a
few MBs versus several hundred MBs for the full OVMF).
Note: it's unclear why `dontPatchELF` is now necessary for the build to
pass (on my end, at any rate) but it doesn't make much sense to run this
fixup anyway,
Note: my reading of xen's INSTALL suggests that --with-system-ovmf should
point directly to the OVMF binary. As such, the previous invocation was
incorrect (it pointed to the root of the OVMF tree). In any case, I have
only built xen with `--with-system-ovmf`, I have not tested it.
Fixes https://github.com/NixOS/nixpkgs/issues/25854
Closes https://github.com/NixOS/nixpkgs/pull/25855
OVMF is built from edk2 sources so that's where its version number comes
from (logically). The edk2 version number is 2014-12-10, so this change
only ensures the version numbers won't drift apart in the future. (There
is no hash change.)
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
Also:
* provides a bunch of build options
* documents build options config in longDescription
* provides a bunch of predefined packages and documents them some more
* sources' hashes stay the same
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
XSA-197 Issue Description:
> The compiler can emit optimizations in qemu which can lead to double
> fetch vulnerabilities. Specifically data on the rings shared
> between qemu and the hypervisor (which the guest under control can
> obtain mappings of) can be fetched twice (during which time the
> guest can alter the contents) possibly leading to arbitrary code
> execution in qemu.
More: https://xenbits.xen.org/xsa/advisory-197.html
XSA-199 Issue Description:
> The code in qemu which implements ioport read/write looks up the
> specified ioport address in a dispatch table. The argument to the
> dispatch function is a uint32_t, and is used without a range check,
> even though the table has entries for only 2^16 ioports.
>
> When qemu is used as a standalone emulator, ioport accesses are
> generated only from cpu instructions emulated by qemu, and are
> therefore necessarily 16-bit, so there is no vulnerability.
>
> When qemu is used as a device model within Xen, io requests are
> generated by the hypervisor and read by qemu from a shared ring. The
> entries in this ring use a common structure, including a 64-bit
> address field, for various accesses, including ioport addresses.
>
> Xen will write only 16-bit address ioport accesses. However,
> depending on the Xen and qemu version, the ring may be writeable by
> the guest. If so, the guest can generate out-of-range ioport
> accesses, resulting in wild pointer accesses within qemu.
More: https://xenbits.xen.org/xsa/advisory-199.html
XSA-207 Issue Description:
> Certain internal state is set up, during domain construction, in
> preparation for possible pass-through device assignment. On ARM and
> AMD V-i hardware this setup includes memory allocation. On guest
> teardown, cleanup was erroneously only performed when the guest
> actually had a pass-through device assigned.
More: https://xenbits.xen.org/xsa/advisory-207.html
XSA-209 Issue Description:
> When doing bitblt copy backwards, qemu should negate the blit width.
> This avoids an oob access before the start of video memory.
More: https://xenbits.xen.org/xsa/advisory-208.html
XSA-208 Issue Description:
> In CIRRUS_BLTMODE_MEMSYSSRC mode the bitblit copy routine
> cirrus_bitblt_cputovideo fails to check wethehr the specified memory
> region is safe.
More: https://xenbits.xen.org/xsa/advisory-209.html
Putting information in external JSON files is IMHO not an improvement
over the idiomatic style of Nix expressions. The use of JSON doesn't
add anything over Nix expressions (in fact it removes expressive
power). And scattering package info over lots of little files makes
packages less readable over having the info in one file.
`DOCKER_GITCOMMIT` needs to match the tagged commit used to build the
binary. The current commit refers to 1.12.1 and wasn't update each
time we updated the package. Using a variable near the version and
adding a comment so we don't forget to update next time.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
- Update docker version to 1.13.0.
- Introduce now docker-proxy package (from libnetmork).
- Use overrideDerivation to set the correct version for docker.
- Update tini to make sure we can build it static.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
This brings VirtualBox to the latest upstream version, which also fixes
building the modules against kernel 4.9.0.
Tested against all the the "virtualbox" subtests on x86_64-linux.
The "misc" NixOS test is using Nix to query the store and it tries to
change the ownership of it while doing so.
This fails if Nix is not in a seccomp-sandboxed userid namespace, so
let's make chown() a no-op when applied to store paths.
Fixes the misc test (and possibly future tests) on older Nix versions.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
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@5e51ffb1c2, 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>
From LWN:
From the NVD entries:
CVE-2016-5501: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.0.28 and 5.1.x before 5.1.8 in Oracle
Virtualization allows local users to affect confidentiality,
integrity, and availability via vectors related to Core, a different
vulnerability than CVE-2016-5538.
CVE-2016-5538: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.0.28 and 5.1.x before 5.1.8 in Oracle
Virtualization allows local users to affect confidentiality,
integrity, and availability via vectors related to Core, a different
vulnerability than CVE-2016-5501.
CVE-2016-5605: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.1.4 in Oracle Virtualization allows remote
attackers to affect confidentiality and integrity via vectors related
to VRDE.
CVE-2016-5608: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.0.28 and 5.1.x before 5.1.8 in Oracle
Virtualization allows local users to affect availability via vectors
related to Core, a different vulnerability than CVE-2016-5613.
CVE-2016-5610: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.0.28 and 5.1.x before 5.1.8 in Oracle
Virtualization allows local users to affect confidentiality,
integrity, and availability via vectors related to Core.
CVE-2016-5611: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.0.28 and 5.1.x before 5.1.8 in Oracle
Virtualization allows local users to affect confidentiality via
vectors related to Core.
CVE-2016-5613: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.0.28 and 5.1.x before 5.1.8 in Oracle
Virtualization allows local users to affect availability via vectors
related to Core, a different vulnerability than CVE-2016-5608.
As of systemd 231, the LD_LIBRARY_PATH fix applied in the installPhase of rkt's
build was no longer valid, causing rkt to fail to work. This patch changes the
path to point to the new location of libsystemd, which is in ${systemd.lib}.
This introduces VirtualBox version 5.1.6 along with a few refactored
stuff, notably:
* Kernel modules and user space applications are now separate
derivations.
* If config.pulseaudio doesn't exist in nixpkgs config, the default is
now to build with PulseAudio modules.
* A new updater to keep VirtualBox up to date.
All subtests in nixos/tests/virtualbox.nix succeed on my machine and
VirtualBox was reported to be working by @DamienCassou (although with
unrelated audio problems for another fix/branch) and @calbrecht.
Upstream changelog without bug numbers:
* GUI: fixed issue with opening '.vbox' files and it's aliases
* GUI: keyboard grabbing fixes
* GUI: fix for passing through Ctrl + mouse-click
* GUI: fixed automatic deletion of extension pack files
* USB: fixed showing unknown device instead of the manufacturer or
product description under certain circumstances
* XHCI: another fix for a hanging guest under certain conditions, this
time for Windows 7 guests
* Serial: fixed high CPU usage with certain USB to serial converters
on Linux hosts
* Storage: fixed attaching stream optimized VMDK images
* Storage: reject image variants which are unsupported by the backend
* Storage: fixed loading saved states created with VirtualBox 5.0.10
and older when using a SCSI controller
* Storage: fixed broken NVMe emulation if the host I/O cache setting
is enabled
* Storage: fixed using multiple NVMe controllers if ICH9 is used
* NVMe: fixed a crash during reset which could happen under certain
circumstances
* Audio: fixed microphone input (5.1.2 regression)
* Audio: fixed crashes under certain conditions (5.1.0 regression)
* Audio: fixed recording with the ALSA backend (5.1 regression)
* Audio: fixed stream access mode with OSS backend (5.1 regression,
thanks to Jung-uk Kim)
* E1000: do also return masked bits when reading the ICR register,
this fixes booting from iPXE (5.1.2 regression)
* BIOS: fixed 4bpp scanline calculation
* API: relax the check for the version attribute in OVF/OVA appliances
* Windows hosts: fixed crashes when terminating the VM selector or
other VBox COM clients
* Linux Installer: fixed path to the documentation in .rpm packages
(5.1.0 regression)
* Linux Installer: fixed the vboxdrv.sh script to prevent an SELinux
complaint
* Linux hosts: don't use 32-bit legacy capabilities
* Linux Additions: Linux 4.8 fix for the kernel display driver
* Linux Additions: don't load the kernel modules provided by the Linux
distribution but load the kernel modules from the
official Guest Additions package instead
* Linux Additions: fix dynamic resizing problems in recent Linux
guests
* User Manual: fixed error in the VBoxManage chapter for the
getextradata enumerate example
The full upstream changelog with bug numbers can be found at:
https://www.virtualbox.org/wiki/Changelog-5.1#v6
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
In 2942815968, the dependencies for Qt 5
were passed using buildEnv with all the development binaries, headers
and libs. Unfortunately, the build output references that environment
which also increases the size of the runtime closure.
The upstream makefile assumes a common Qt 5 library path, but that's not
the case within Nix, because we have separate paths for the Qt 5
modules.
We now patch the makefile to recognize PATH_QT5_X11_EXTRAS_{LIB,INC} so
that we can pass in the relevant paths from Qt5X11Extras.
In summary, the closure size goes down to 525559600 bytes (501 MB)
instead of 863035544 bytes (823 MB) with vbox-qt5-env.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Putting the kernel modules into the same output path as the main
VirtualBox derivation causes all of VirtualBox to be rebuilt on every
single kernel update.
The build process of VirtualBox already outputs the kernel module source
along with the generated files for the configuration of the main
VirtualBox package. We put this into a different output called "modsrc"
which we re-use from linuxPackages.virtualbox, which is now only
containing the resulting kernel modules without the main user space
implementation.
This not only has the advantage of decluttering the Nix expression for
the user space portions but also gets rid of the need to nuke references
and the need to patch out "depmod -a".
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We now no longer need to update VirtualBox manually, which has a few
advantages. Along with making it just easier to update this also makes
the update procedure way less error-prone, for example if people forget
to bump the extension pack revision or to update the guest additions.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Just a small updater which should fetch the latest sha256sums from the
upstream site and check whether the current version is the latest one.
The output is in a JSON file in the same directory, which then will be
used by the Nix expressions to fetch the upstream files.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
See #11567.
Furthermore, it renames pythonPackages.dbus to pythonPackages.dbus-
python as that's the name upstream uses.
There is a small rebuild but I couldn't figure out the actual cause.
