XSA-206 Issue Description:
> xenstored supports transactions, such that if writes which would
> invalidate assumptions of a transaction occur, the entire transaction
> fails. Typical response on a failed transaction is to simply retry
> the transaction until it succeeds.
>
> Unprivileged domains may issue writes to xenstore which conflict with
> transactions either of the toolstack or of backends such as the driver
> domain. Depending on the exact timing, repeated writes may cause
> transactions made by these entities to fail indefinitely.
More: https://xenbits.xen.org/xsa/advisory-206.html
XSA-211 Issue Description:
> When a graphics update command gets passed to the VGA emulator, there
> are 3 possible modes that can be used to update the display:
>
> * blank - Clears the display
> * text - Treats the display as showing text
> * graph - Treats the display as showing graphics
>
> After the display geometry gets changed (i.e., after the CIRRUS VGA
> emulation has resized the display), the VGA emulator will resize the
> console during the next update command. However, when a blank mode is
> also selected during an update, this resize doesn't happen. The resize
> will be properly handled during the next time a non-blank mode is
> selected during an update.
>
> However, other console components - such as the VNC emulation - will
> operate as though this resize had happened. When the display is
> resized to be larger than before, this can result in a heap overflow
> as console components will expect the display buffer to be larger than
> it is currently allocated.
More: https://xenbits.xen.org/xsa/advisory-211.html
XSA-212 Issue Description:
> The XSA-29 fix introduced an insufficient check on XENMEM_exchange
> input, allowing the caller to drive hypervisor memory accesses outside
> of the guest provided input/output arrays.
More: https://xenbits.xen.org/xsa/advisory-212.html
XSA-213 Issue Description:
> 64-bit PV guests typically use separate (root) page tables for their
> kernel and user modes. Hypercalls are accessible to guest kernel
> context only, which certain hypercall handlers make assumptions on.
> The IRET hypercall (replacing the identically name CPU instruction)
> is used by guest kernels to transfer control from kernel mode to user
> mode. If such an IRET hypercall is placed in the middle of a multicall
> batch, subsequent operations invoked by the same multicall batch may
> wrongly assume the guest to still be in kernel mode. If one or more of
> these subsequent operations involve operations on page tables, they may
> be using the wrong root page table, confusing internal accounting. As
> a result the guest may gain writable access to some of its page tables.
More: https://xenbits.xen.org/xsa/advisory-213.html
XSA-214 Issue Description:
> The GNTTABOP_transfer operation allows one guest to transfer a page to
> another guest. The internal processing of this, however, does not
> include zapping the previous type of the page being transferred. This
> makes it possible for a PV guest to transfer a page previously used as
> part of a segment descriptor table to another guest while retaining the
> "contains segment descriptors" property.
>
> If the destination guest is a PV one of different bitness, it may gain
> access to segment descriptors it is not normally allowed to have, like
> 64-bit code segments in a 32-bit PV guest.
>
> If the destination guest is a HVM one, that guest may freely alter the
> page contents and then hand the page back to the same or another PV
> guest.
>
> In either case, if the destination PV guest then inserts that page into
> one of its own descriptor tables, the page still having the designated
> type results in validation of its contents being skipped.
More: https://xenbits.xen.org/xsa/advisory-214.html
XSA-215 Issue Description:
> Under certain special conditions Xen reports an exception resulting
> from returning to guest mode not via ordinary exception entry points,
> but via a so call failsafe callback. This callback, unlike exception
> handlers, takes 4 extra arguments on the stack (the saved data
> selectors DS, ES, FS, and GS). Prior to placing exception or failsafe
> callback frames on the guest kernel stack, Xen checks the linear
> address range to not overlap with hypervisor space. The range spanned
> by that check was mistakenly not covering these extra 4 slots.
More: https://xenbits.xen.org/xsa/advisory-215.html
Recent commit #c10af9e744c91dff1ccc07a52a0b57d1e4d339f3 changed the
behaviour of wrapPythonPrograms, which caused pygrub to no longer
being wrapped. This commit fixes this.
- Moves to a more recent kernel (4.10, I think ...)
- API break re the previous version
- cptofs: fix root directory copy
- add support for disks with custom ops
- add LKL_HIJACK_NET_QDISC to configure qdisc policy
- add LKL_HIJACK_SYSCTL to configure sysctl values
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.
