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>
Vincent Demeester
Graham Christensen
Michał Pałka
Vladimír Čunát
midchildan
Robin Gloster
Tim Steinbach
Joachim Fasting
Peter Hoeg
Joachim F
Jörg Thalheim
Frederik Rietdijk
Olegs Jeremejevs
Pascal Bach
Bjørn Forsman
Volth
Michael Raskin
Tim Steinbach
Franz Pletz
Kosyrev Serge
Nikolay Amiantov
Dan Peebles
aszlig
Peter Hoeg
Jan Malakhovski
Tuomas Tynkkynen
Alexey Shmalko
Benjamin Staffin
Parnell Springmeyer
Christoph Hrdinka
Eelco Dolstra
Jaka Hudoklin
Antoine Eiche