Commit Graph

838 Commits

Author SHA1 Message Date
John Ericson
9be40841ea Merge remote-tracking branch 'upstream/master' into staging-base
Conflicts:
	pkgs/build-support/cc-wrapper/default.nix
	pkgs/build-support/gcc-wrapper-old/builder.sh
	pkgs/build-support/trivial-builders.nix
	pkgs/desktops/kde-4.14/kde-package/default.nix
	pkgs/development/compilers/openjdk-darwin/8.nix
	pkgs/development/compilers/openjdk-darwin/default.nix
	pkgs/development/compilers/openjdk/7.nix
	pkgs/development/compilers/openjdk/8.nix
	pkgs/development/compilers/oraclejdk/jdk-linux-base.nix
	pkgs/development/compilers/zulu/default.nix
	pkgs/development/haskell-modules/generic-builder.nix
	pkgs/misc/misc.nix
	pkgs/stdenv/generic/builder.sh
	pkgs/stdenv/generic/setup.sh
2017-07-26 13:46:04 -04:00
Tim Steinbach
ee6edb8af5
virtualbox: 5.1.22 -> 5.1.24 2017-07-23 22:22:33 -04:00
Frederik Rietdijk
29f91c107f Merge remote-tracking branch 'upstream/master' into HEAD 2017-07-23 11:23:43 +02:00
Thomas Tuegel
fe800447c2
qemu: unset CPP
Commit 093cc00cdd sets the environment variable
`CPP' by default, but this interferes with dependency calculation.
2017-07-21 16:49:24 -05:00
Vincent Demeester
19325558f1 Fix docker packaging without sandbox
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
2017-07-21 10:00:47 +02:00
AndersonTorres
a3aa0ba18b bochs: 2.6.8 -> 2.6.9 2017-07-15 08:53:15 -03:00
Vincent Demeester
ec570448a0
docker-ce: 17.03.02-ce -> 17.06.0-ce
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
2017-07-10 09:58:32 +02:00
aszlig
12ee0fbd88
virtualbox: Add patch for Linux 4.12
Compiling the kernel modules on Linux 4.12 fails, so I've included an
upstream patch from:

https://www.virtualbox.org/changeset/66927/vbox

The patch is applied against the guest additions as well, where we need
to transform the patch a bit so that we get CR LF line endings (DOS
format), which is what is the case for the guest additions ISO.

I've tested this with all the subtests of the "virtualbox" NixOS VM
tests and they all succeed on x86_64-linux.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2017-07-04 20:08:42 +02:00
Joachim F
a8ba50db3e Merge pull request #26492 from michalpalka/new-xen
xen_4_8: init at 4.8.1
2017-06-30 20:27:04 +01:00
Tim Steinbach
4cc729644e Merge pull request #26867 from michalpalka/xen-security-2017.06-new
xen: patch for XSAs: 216, 217, 218, 219, 220, 221, 222, and 224
2017-06-28 22:43:46 -04:00
Tim Steinbach
fb8a66dcc9 Merge pull request #26945 from NeQuissimus/virtualbox_32bit
virtualbox: Add ability to disable 32-bit guest support
2017-06-28 22:32:12 -04:00
Tim Steinbach
312c2f7961
virtualbox: Add ability to disable 32-bit guest support 2017-06-28 22:24:19 -04:00
Joachim Fasting
0bc3429e77
lkl: 2017-03-24 -> 2017-06-27
Now based on Linux 4.11
2017-06-28 20:14:00 +02:00
Tim Steinbach
add90948bc
docker: 17.03.1-ce -> 17.03.2-ce 2017-06-28 12:49:59 -04:00
Michał Pałka
7b5d72ce04 xen: patch for XSAs: 216, 217, 218, 219, 220, 221, 222, and 224 (xen 4.8)
This commit contains security patches for xen 4.8. The patches
for XSA-216 applied to the kernel are omitted, as they are part of
80e0cda7ff.

XSA-216 Issue Description:

> The block interface response structure has some discontiguous fields.
> Certain backends populate the structure fields of an otherwise
> uninitialized instance of this structure on their stacks, leaking
> data through the (internal or trailing) padding field.

More: https://xenbits.xen.org/xsa/advisory-216.html

XSA-217 Issue Description:

> Domains controlling other domains are permitted to map pages owned by
> the domain being controlled.  If the controlling domain unmaps such a
> page without flushing the TLB, and if soon after the domain being
> controlled transfers this page to another PV domain (via
> GNTTABOP_transfer or, indirectly, XENMEM_exchange), and that third
> domain uses the page as a page table, the controlling domain will have
> write access to a live page table until the applicable TLB entry is
> flushed or evicted.  Note that the domain being controlled is
> necessarily HVM, while the controlling domain is PV.

More: https://xenbits.xen.org/xsa/advisory-217.html

XSA-218 Issue Description:

> We have discovered two bugs in the code unmapping grant references.
>
> * When a grant had been mapped twice by a backend domain, and then
> unmapped by two concurrent unmap calls, the frontend may be informed
> that the page had no further mappings when the first call completed rather
> than when the second call completed.
>
> * A race triggerable by an unprivileged guest could cause a grant
> maptrack entry for grants to be "freed" twice.  The ultimate effect of
> this would be for maptrack entries for a single domain to be re-used.

More: https://xenbits.xen.org/xsa/advisory-218.html

XSA-219 Issue Description:

> When using shadow paging, writes to guest pagetables must be trapped and
> emulated, so the shadows can be suitably adjusted as well.
>
> When emulating the write, Xen maps the guests pagetable(s) to make the final
> adjustment and leave the guest's view of its state consistent.
>
> However, when mapping the frame, Xen drops the page reference before
> performing the write.  This is a race window where the underlying frame can
> change ownership.
>
> One possible attack scenario is for the frame to change ownership and to be
> inserted into a PV guest's pagetables.  At that point, the emulated write will
> be an unaudited modification to the PV pagetables whose value is under guest
> control.

More: https://xenbits.xen.org/xsa/advisory-219.html

XSA-220 Issue Description:

> Memory Protection Extensions (MPX) and Protection Key (PKU) are features in
> newer processors, whose state is intended to be per-thread and context
> switched along with all other XSAVE state.
>
> Xen's vCPU context switch code would save and restore the state only
> if the guest had set the relevant XSTATE enable bits.  However,
> surprisingly, the use of these features is not dependent (PKU) or may
> not be dependent (MPX) on having the relevant XSTATE bits enabled.
>
> VMs which use MPX or PKU, and context switch the state manually rather
> than via XSAVE, will have the state leak between vCPUs (possibly,
> between vCPUs in different guests).  This in turn corrupts state in
> the destination vCPU, and hence may lead to weakened protections
>
> Experimentally, MPX appears not to make any interaction with BND*
> state if BNDCFGS.EN is set but XCR0.BND{CSR,REGS} are clear.  However,
> the SDM is not clear in this case; therefore MPX is included in this
> advisory as a precaution.

More: https://xenbits.xen.org/xsa/advisory-220.html

XSA-221 Issue Description:

> When polling event channels, in general arbitrary port numbers can be
> specified.  Specifically, there is no requirement that a polled event
> channel ports has ever been created.  When the code was generalised
> from an earlier implementation, introducing some intermediate
> pointers, a check should have been made that these intermediate
> pointers are non-NULL.  However, that check was omitted.

More: https://xenbits.xen.org/xsa/advisory-221.html

XSA-222 Issue Description:

> Certain actions require removing pages from a guest's P2M
> (Physical-to-Machine) mapping.  When large pages are in use to map
> guest pages in the 2nd-stage page tables, such a removal operation may
> incur a memory allocation (to replace a large mapping with individual
> smaller ones).  If this allocation fails, these errors are ignored by
> the callers, which would then continue and (for example) free the
> referenced page for reuse.  This leaves the guest with a mapping to a
> page it shouldn't have access to.
>
> The allocation involved comes from a separate pool of memory created
> when the domain is created; under normal operating conditions it never
> fails, but a malicious guest may be able to engineer situations where
> this pool is exhausted.

More: https://xenbits.xen.org/xsa/advisory-222.html

XSA-224 Issue Description:

> We have discovered a number of bugs in the code mapping and unmapping
> grant references.
>
> * If a grant is mapped with both the GNTMAP_device_map and
> GNTMAP_host_map flags, but unmapped only with host_map, the device_map
> portion remains but the page reference counts are lowered as though it
> had been removed. This bug can be leveraged cause a page's reference
> counts and type counts to fall to zero while retaining writeable
> mappings to the page.
>
> * Under some specific conditions, if a grant is mapped with both the
> GNTMAP_device_map and GNTMAP_host_map flags, the operation may not
> grab sufficient type counts.  When the grant is then unmapped, the
> type count will be erroneously reduced.  This bug can be leveraged
> cause a page's reference counts and type counts to fall to zero while
> retaining writeable mappings to the page.
>
> * When a grant reference is given to an MMIO region (as opposed to a
> normal guest page), if the grant is mapped with only the
> GNTMAP_device_map flag set, a mapping is created at host_addr anyway.
> This does *not* cause reference counts to change, but there will be no
> record of this mapping, so it will not be considered when reporting
> whether the grant is still in use.

More: https://xenbits.xen.org/xsa/advisory-224.html
2017-06-27 12:02:59 +00:00
Michał Pałka
9e6bfbb2f9 xen_4_8: init at 4.8.1
This commit adds the xen_4_8 package to be used instead of
xen (currently at 4.5.5):
 * Add packages xen_4_8, xen_4_8-slim and xen_4_8-light
 * Add packages qemu_xen_4_8 and qemu_xen_4_8-light to be used
   with xen_4_8-slim and xen_4_8-light respectively.
 * Add systemd to buildInputs of xen (it is required by oxenstored)
 * Adapt xen service to work with the new version of xen
 * Use xen-init-dom0 to initlilise dom0 in xen-store
 * Currently, the virtualisation.xen.stored option is ignored
   if xen 4.8 is used
2017-06-27 12:01:53 +00:00
Michał Pałka
80e0cda7ff xen: patch for XSAs: 216, 217, 218, 219, 220, 221, 222, and 224
XSA-216 Issue Description:

> The block interface response structure has some discontiguous fields.
> Certain backends populate the structure fields of an otherwise
> uninitialized instance of this structure on their stacks, leaking
> data through the (internal or trailing) padding field.

More: https://xenbits.xen.org/xsa/advisory-216.html

XSA-217 Issue Description:

> Domains controlling other domains are permitted to map pages owned by
> the domain being controlled.  If the controlling domain unmaps such a
> page without flushing the TLB, and if soon after the domain being
> controlled transfers this page to another PV domain (via
> GNTTABOP_transfer or, indirectly, XENMEM_exchange), and that third
> domain uses the page as a page table, the controlling domain will have
> write access to a live page table until the applicable TLB entry is
> flushed or evicted.  Note that the domain being controlled is
> necessarily HVM, while the controlling domain is PV.

More: https://xenbits.xen.org/xsa/advisory-217.html

XSA-218 Issue Description:

> We have discovered two bugs in the code unmapping grant references.
>
> * When a grant had been mapped twice by a backend domain, and then
> unmapped by two concurrent unmap calls, the frontend may be informed
> that the page had no further mappings when the first call completed rather
> than when the second call completed.
>
> * A race triggerable by an unprivileged guest could cause a grant
> maptrack entry for grants to be "freed" twice.  The ultimate effect of
> this would be for maptrack entries for a single domain to be re-used.

More: https://xenbits.xen.org/xsa/advisory-218.html

XSA-219 Issue Description:

> When using shadow paging, writes to guest pagetables must be trapped and
> emulated, so the shadows can be suitably adjusted as well.
>
> When emulating the write, Xen maps the guests pagetable(s) to make the final
> adjustment and leave the guest's view of its state consistent.
>
> However, when mapping the frame, Xen drops the page reference before
> performing the write.  This is a race window where the underlying frame can
> change ownership.
>
> One possible attack scenario is for the frame to change ownership and to be
> inserted into a PV guest's pagetables.  At that point, the emulated write will
> be an unaudited modification to the PV pagetables whose value is under guest
> control.

More: https://xenbits.xen.org/xsa/advisory-219.html

XSA-220 Issue Description:

> Memory Protection Extensions (MPX) and Protection Key (PKU) are features in
> newer processors, whose state is intended to be per-thread and context
> switched along with all other XSAVE state.
>
> Xen's vCPU context switch code would save and restore the state only
> if the guest had set the relevant XSTATE enable bits.  However,
> surprisingly, the use of these features is not dependent (PKU) or may
> not be dependent (MPX) on having the relevant XSTATE bits enabled.
>
> VMs which use MPX or PKU, and context switch the state manually rather
> than via XSAVE, will have the state leak between vCPUs (possibly,
> between vCPUs in different guests).  This in turn corrupts state in
> the destination vCPU, and hence may lead to weakened protections
>
> Experimentally, MPX appears not to make any interaction with BND*
> state if BNDCFGS.EN is set but XCR0.BND{CSR,REGS} are clear.  However,
> the SDM is not clear in this case; therefore MPX is included in this
> advisory as a precaution.

More: https://xenbits.xen.org/xsa/advisory-220.html

XSA-221 Issue Description:

> When polling event channels, in general arbitrary port numbers can be
> specified.  Specifically, there is no requirement that a polled event
> channel ports has ever been created.  When the code was generalised
> from an earlier implementation, introducing some intermediate
> pointers, a check should have been made that these intermediate
> pointers are non-NULL.  However, that check was omitted.

More: https://xenbits.xen.org/xsa/advisory-221.html

XSA-222 Issue Description:

> Certain actions require removing pages from a guest's P2M
> (Physical-to-Machine) mapping.  When large pages are in use to map
> guest pages in the 2nd-stage page tables, such a removal operation may
> incur a memory allocation (to replace a large mapping with individual
> smaller ones).  If this allocation fails, these errors are ignored by
> the callers, which would then continue and (for example) free the
> referenced page for reuse.  This leaves the guest with a mapping to a
> page it shouldn't have access to.
>
> The allocation involved comes from a separate pool of memory created
> when the domain is created; under normal operating conditions it never
> fails, but a malicious guest may be able to engineer situations where
> this pool is exhausted.

More: https://xenbits.xen.org/xsa/advisory-222.html

XSA-224 Issue Description:

> We have discovered a number of bugs in the code mapping and unmapping
> grant references.
>
> * If a grant is mapped with both the GNTMAP_device_map and
> GNTMAP_host_map flags, but unmapped only with host_map, the device_map
> portion remains but the page reference counts are lowered as though it
> had been removed. This bug can be leveraged cause a page's reference
> counts and type counts to fall to zero while retaining writeable
> mappings to the page.
>
> * Under some specific conditions, if a grant is mapped with both the
> GNTMAP_device_map and GNTMAP_host_map flags, the operation may not
> grab sufficient type counts.  When the grant is then unmapped, the
> type count will be erroneously reduced.  This bug can be leveraged
> cause a page's reference counts and type counts to fall to zero while
> retaining writeable mappings to the page.
>
> * When a grant reference is given to an MMIO region (as opposed to a
> normal guest page), if the grant is mapped with only the
> GNTMAP_device_map flag set, a mapping is created at host_addr anyway.
> This does *not* cause reference counts to change, but there will be no
> record of this mapping, so it will not be considered when reporting
> whether the grant is still in use.

More: https://xenbits.xen.org/xsa/advisory-224.html
2017-06-26 07:01:24 +00:00
Tim Steinbach
328617accd
rkt: 1.26.0 -> 1.27.0 2017-06-23 19:24:19 -04:00
aszlig
63fb845fcf
virtualbox: Rebase hardened.patch on top of 5.1.22
The merge of the version bump in
6fb9f89238 didn't take care of our patch
for the hardening mode and thus enabling VirtualBox without also
force-disabling hardening mode will result in a build error.

While the patch is largely identical with the old version, I've removed
one particular change around the following code:

    if (pFsObjState->Stat.st_mode & S_IWOTH)
        return supR3HardenedSetError3(VERR_SUPLIB_WORLD_WRITABLE, pErrInfo,
                                      "World writable: '", pszPath, "'");

In the old version of the patch we have checked whether the path is
within the Nix store and suppressed the error return if that's the case.

The reason why I did that in the first place was because we had a bunch
of symlinks which were writable.

In VirtualBox 5.1.22 the code specifically checks whether the file is a
symlink, so we can safely drop our change.

Tested via all of the "virtualbox" NixOS VM subtests and they now all
succeed.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2017-06-23 05:48:54 +02:00
Tim Steinbach
6fb9f89238 Merge pull request #25368 from bachp/virtualbox-5.1.22
virtualbox: 5.1.18 -> 5.1.22
2017-06-22 21:23:47 -04:00
Peter Hoeg
63011015b9 virtmanager-qt: 0.43.70.2 -> 0.43.72 2017-06-19 19:26:19 +08:00
Thomas Tuegel
c816bbc8a8
qt5: remove makeQtWrapper 2017-06-18 08:44:42 -05:00
Jörg Thalheim
f2e1e7f3cd Merge pull request #26503 from vdemeester/update-runc
Update runc to 1.0.0-rc3
2017-06-10 22:48:03 +01:00
Vincent Demeester
46b00e0b15
Update runc to 1.0.0-rc3
- Fix compilation problems
- Remove patches as those are included in the sources now

Signed-off-by: Vincent Demeester <vincent@sbr.pm>
2017-06-10 18:05:57 +02:00
Graham Christensen
7d8218a351 Merge pull request #26489 from michalpalka/xen-security
xen: patch for XSAs: 206, 211, 212, 213, 214 and 215
2017-06-09 09:31:42 -04:00
Michał Pałka
dd3dcceb23 xen: patch for XSAs: 206, 211, 212, 213, 214 and 215
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
2017-06-09 13:09:01 +00:00
Vladimír Čunát
cc9a72a286
virtualboxGuestAdditions: don't install setuid/setgid 2017-06-09 13:09:21 +02:00
Michał Pałka
965668903a xen: fix pygrub by making sure it is wrapped
Recent commit #c10af9e744c91dff1ccc07a52a0b57d1e4d339f3 changed the
behaviour of wrapPythonPrograms, which caused pygrub to no longer
being wrapped. This commit fixes this.
2017-06-09 06:22:03 +00:00
midchildan
7060a692c5
virtmanager: Fix python import error 2017-06-05 23:42:25 +09:00
Robin Gloster
13f2f8673b
OVMF: fix build
$fd for the output was overwritten during the build
2017-05-29 12:21:17 +02:00
Tim Steinbach
9237459d60
rkt: 1.25.0 -> 1.26.0 2017-05-25 18:13:54 -04:00
Joachim Fasting
49ecd62c08
lkl: split outputs
Breaking out lib allows users to link against lkl without pulling the
kitchen sink into their closure.
2017-05-24 01:07:26 +02:00
Joachim Fasting
e0b623a56d
lkl: break description into longDescription and a briefer descr 2017-05-24 01:07:24 +02:00
Joachim Fasting
8c8f40a128
lkl: d747073 -> 2017-03-24
- 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
2017-05-24 01:07:23 +02:00
Joachim Fasting
e983d4306e
lkl: bc & python are native build inputs 2017-05-24 01:07:22 +02:00
Joachim Fasting
e845495edb
lkl: add meta.homepage 2017-05-24 01:07:14 +02:00
Peter Hoeg
5b45342832 virtmanager-qt: 0.43.70 -> 0.43.70.2 2017-05-23 17:54:20 +08:00
Joachim F
07ceaa2ec8 Merge pull request #25896 from joachifm/ovmf
ovmf: split firmware image files
2017-05-21 14:48:29 +01:00
Joachim Fasting
874b81b31f
treewide: s,enableParallelBuild(s),enableParallelBuilding,g 2017-05-20 17:16:17 +02:00
Joachim Fasting
252dcd62f3
OVMF: separate output for ovmf binaries
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
2017-05-20 12:33:48 +02:00
Jörg Thalheim
618f9aa52c
docker-proxy: remove go references
related to #25861
2017-05-17 22:14:34 +01:00
Peter Hoeg
68f335c6cd virtmanager-qt: 0.42.67 -> 0.43.70 2017-05-14 11:21:51 +08:00
Vincent Demeester
398f6ed7d3
docker-edge: 17.04 to 17.05
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
2017-05-09 10:11:05 +02:00
Frederik Rietdijk
ef4442e827 Python: replace requests2 with requests tree-wide
See f63eb58573

The `requests2` attribute now throws an error informing that `requests`
should be used instead.
2017-05-07 12:56:09 +02:00
Olegs Jeremejevs
670afd010c virt-manager: add requests as dependency 2017-05-07 12:15:19 +03:00
Frederik Rietdijk
95534bc4ee virtinst: do not depend on glanceclient
because its not a dependency and because its broken.
2017-05-07 10:02:33 +02:00
Frederik Rietdijk
e184e02e7a virt-manager: do not depend on glanceclient
because its not a dependency and because its broken.
2017-05-07 10:01:47 +02:00
Pascal Bach
c4a48600bf virtualbox: 5.1.18 -> 5.1.22 2017-04-30 22:55:23 +02:00
Michał Pałka
7c918ff7d4 virtualisation-xen: Fix xendomains startup
* Revert to using bash, not sh for the xendomains script to avoid syntax error
* Rewrite /bin/ls to ls in the xendomains script
2017-04-27 07:55:34 +00:00
Bjørn Forsman
ddb788b671 OVMF: get version number from edk2
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.)
2017-04-23 19:28:34 +02:00
Volth
1931ad0e2c qemu: 2.8.1 -> 2.9.0 2017-04-23 14:20:48 +02:00
Michael Raskin
f45f2fb67a Merge pull request #24549 from volth/qemu-2.8.1
qemu: 2.8.0 -> 2.8.1
2017-04-23 11:07:44 +02:00
Tim Steinbach
d95fb5f2ac Merge pull request #24632 from NeQuissimus/docker_17_04
docker-edge: init at 17.04
2017-04-05 20:51:14 -04:00
Tim Steinbach
1e589239b3
docker-edge: init at 17.04 2017-04-05 20:49:26 -04:00
Tim Steinbach
89188e2972
docker-distribution: 2.5.1 -> 2.6.0 2017-04-04 21:01:27 -04:00
Tim Steinbach
aefb9671bf
docker: 17.03.0 -> 17.03.1 2017-04-04 13:43:57 -04:00
Volth
160a84013e qemu: 2.8.0 -> 2.8.1 2017-04-02 00:21:56 +00:00
Franz Pletz
0018cd5a2d
libvirt packages: fix & clean up dependencies 2017-03-28 19:45:01 +02:00
Kosyrev Serge
0c3138e602 virtualbox: a more maintenance-free way of patching refs to dlopen()-affected dependencies 2017-03-28 01:32:11 +03:00
Nikolay Amiantov
52451067c7 virtualbox: wrap with Qt dependencies
Fixes GTK file open dialogs. Also make sure that linked applications really
exist, and update their list.
2017-03-28 00:29:40 +03:00
Franz Pletz
160fd7231e
virt-manager: needs file for building translations 2017-03-25 14:57:45 +01:00
volth
4e749683e6 virt-manager: 1.4.0 -> 1.4.1 (#24149) 2017-03-21 10:20:55 +01:00
Robin Gloster
07252dc83b
virtualbox: 5.1.14 -> 5.1.18 2017-03-20 16:05:20 +01:00
Michael Raskin
dfbd2dd659 Merge pull request #23624 from volth/virt-viewer-5.0
virt-viewer: 2.0 -> 5.0
2017-03-18 19:05:11 +01:00
Peter Hoeg
ee20e89644 virtmanager-qt: 0.39.60 -> 0.42.67 2017-03-18 12:32:49 +08:00
Tim Steinbach
f1c2d047ed Merge pull request #23872 from NeQuissimus/docker_17_03_0
docker: 1.13.1 -> 17.03.0-ce
2017-03-17 10:07:04 -04:00
Dan Peebles
dc61ff31a7 xhyve: update and fix to use our Hypervisor framework
(this is a cherry-picked version of f3b65f67d9,
which got reverted because it depended on my 10.11 frameworks, which were
flawed)
2017-03-14 22:38:35 -04:00
Tim Steinbach
aed4918795
docker: 1.13.1 -> 17.03.0-ce 2017-03-14 08:02:35 -04:00
Volth
d4294265fd virt-viewer: 2.0 -> 5.0 2017-03-14 04:54:11 +00:00
Joachim Fasting
d082a29c3a
runc: use removeReferencesTo 2017-03-11 15:17:36 +01:00
Joachim Fasting
c4fe196087
docker: use removeReferencesTo 2017-03-11 15:17:34 +01:00
Joachim Fasting
0c6a1eaa43
containerd: use removeReferencesTo 2017-03-11 15:17:32 +01:00
aszlig
0a7673d202
qemu_test: Rebase force-uid0-on-9p.patch
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>
2017-03-11 15:16:49 +01:00
Franz Pletz
3a4e2376e4
qemu_test: don't apply patch for CVE-2016-9602
Both patches are conflicting. Keeping the vulnerability unpatched in qemu
binaries used for nixos test is tolerable.
2017-03-11 13:43:42 +01:00
Franz Pletz
621e7a9945
qemu: fetch vnc bugfix patch from debian
This version of the patch applies cleanly to the 2.8.0 release.
2017-03-11 09:32:48 +01:00
Franz Pletz
c512180f9c
qemu: add patches for multiple CVEs
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
2017-03-11 08:14:29 +01:00
Peter Hoeg
bce352949e virtmanager-qt: init at 0.39.60 2017-03-10 11:08:19 +08:00
Jan Malakhovski
916fa0a610 xen: rewrite build expression to be more modular, support upstream qemu and seabios
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
2017-03-05 13:59:28 +00:00
Jan Malakhovski
1c8940a2b8 qemu: add xen support 2017-03-05 13:59:28 +00:00
Jan Malakhovski
eff9b09fb7 qemu: separate usbredirSupport option out of spiceSupport option 2017-03-05 13:59:28 +00:00
Tuomas Tynkkynen
439facec2a lkl: Broken on i686
http://hydra.nixos.org/build/49534265
2017-03-02 03:59:31 +02:00
Alexey Shmalko
0d31a76813
virtualbox: fix build
The issue was caused by upgrading `qt` from `qt56` to `qt57`, which
now requires C++11.

For more info, see https://github.com/NixOS/nixpkgs/issues/23257.
2017-02-28 05:35:52 +02:00
Franz Pletz
6bafe64a20
qemu: apply patches for multiple CVEs
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
2017-02-25 09:40:53 +01:00
Vladimír Čunát
145d3ea81c
Merge branch 'master' into staging 2017-02-22 17:47:49 +01:00
Vladimír Čunát
1d1dc2dcc3
open-vm-tools: fixup build with glibc-2.25 2017-02-22 16:54:07 +01:00
Graham Christensen
cc4919da89
xen: patch for XSAs: 197, 199, 207, 208, 209
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
2017-02-22 08:00:45 -05:00
Tim Steinbach
8b60413e95
rkt: 1.24.0 -> 1.25.0 2017-02-21 18:51:34 -05:00
Vladimír Čunát
3d600726b3
xen: fixup build with glibc-2.25 2017-02-21 18:26:52 +01:00
Benjamin Staffin
b42f820bdc Merge pull request #22745 from vdemeester/docker_1_13_1
docker: 1.13.0 -> 1.13.1
2017-02-14 11:47:40 -05:00
Parnell Springmeyer
9e36a58649
Merging against upstream master 2017-02-13 17:16:28 -06:00
Vincent Demeester
a50b4d0e03
docker: 1.13.0 -> 1.13.1
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
2017-02-13 16:42:39 +01:00
Vladimír Čunát
31eba21d1d
virtualbox: force xorg-server-1.18 for now
This is getting a little hacky, but hopefully it won't break anything.
2017-02-12 21:07:49 +01:00
Tuomas Tynkkynen
a14ef4ad52 open-vm-tools: 10.0.7 -> 10.1.0
Also add an option to disable all the X11 stuff.
2017-02-10 20:12:00 +02:00
Christoph Hrdinka
de9720b65f
aqemu: init at 0.9.2 2017-02-10 12:48:29 +01:00
Dan Peebles
03cab2d923 ecs-agent: init at 1.14.0 2017-02-10 04:33:48 +00:00
Tim Steinbach
f65a3515f4
rkt: 1.23.0 -> 1.24.0 2017-02-05 11:51:05 -05:00
volth
762cc106b4 virt-top: init at 1.0.8 (#21536) 2017-02-04 16:07:45 +01:00
Pascal Bach
5ca3a7e56f virtualbox: remove upstream-info.json as it is no longer used
We keep the script as it might be useful in the future.
2017-02-02 21:11:08 +01:00
Pascal Bach
599df5e108 virtualbox: 5.1.10 -> 5.1.14 2017-02-02 21:10:01 +01:00
Eelco Dolstra
c20cc6d0b3
Excise use of importJSON
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.
2017-01-30 11:44:08 +01:00