Commit graph

138 commits

Author SHA1 Message Date
Jan Tojnar a31d98f312
tree-wide: autorename gnome packages to use dashes 2018-02-25 17:41:16 +01:00
Jan Malakhovski 23e68d119d xenPackages.xen_4_8-vanilla: stop overriding cc
Nothing requires gcc49 in this version.
2018-02-18 13:46:51 +00:00
Jan Malakhovski b1047f34f7 xenPackages.xen_4_8-vanilla: fix build of qemu-xen
They merged that XSA and moved the tag.
2018-02-18 13:46:44 +00:00
Jan Malakhovski 06adc17455 xen, qemu: passthru the path to qemu-system-i386 2018-02-09 19:51:07 +00:00
Graham Christensen b5a61f2c59
Revert "nixos: doc: implement related packages in the manual" 2017-12-23 07:19:45 -05:00
Arseniy Seroka 36e02645eb
Merge pull request #32424 from oxij/nixos/related-packages
nixos: doc: implement related packages in the manual
2017-12-23 03:34:58 +03:00
Andreas Rammhold 276683071b
xen: Added patches for XSA-248, XSA-249, XSA-250, XSA-251 2017-12-12 13:34:35 +01:00
Andreas Rammhold 834bdd25a3 xen: apply patches for XSA-246 & XSA-247 (CVE-2017-{17044,17045}) 2017-12-12 13:20:03 +01:00
Jan Malakhovski 7a92c2074d xen, qemu: passthru the path to qemu-system-i386 2017-12-07 21:27:32 +00:00
Tim Steinbach 54f8dfda53
xen: Create XSA patch directory 2017-10-28 10:19:12 -04:00
Vincent Laporte 1923cabeb4 ocamlPackages: default to 4.04 2017-10-19 17:57:14 +02:00
John Ericson ed14223f8c treewide: Manual fix more pkg-config build-inputs 2017-09-21 15:49:54 -04:00
Robert Hensing 57506bbb28 xen-4.8: update changed patch hash 2017-08-08 17:40:50 +00: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
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
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
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
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
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
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
Vladimír Čunát 145d3ea81c
Merge branch 'master' into staging 2017-02-22 17:47:49 +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
Vladimír Čunát 3d600726b3
xen: fixup build with glibc-2.25 2017-02-21 18:26:52 +01:00
Graham Christensen 4e6c7faf36
xen: patch for many XSAs
- XSA-190
 - XSA-191
 - XSA-192
 - XSA-193
 - XSA-195
 - XSA-196
 - XSA-198
 - XSA-200
 - XSA_202
 - XSA-204
2016-12-21 14:37:47 -05:00
Graham Christensen a2d6e8a2eb
xen: Fix patch hashes
I had used nix-prefetch-url, where fetchpatch doesn't support it.
2016-12-09 07:22:35 -05:00
Graham Christensen 86da9839b1
xen: Patch for CVE-2016-9385, CVE-2016-9377, and CVE-2016-9378 2016-12-07 20:16:05 -05:00
Frederik Rietdijk 4833f8bada xen: use python2 2016-10-22 16:47:21 +02:00
Vladimír Čunát 4d5b893002 Merge #19081: gnome-3.22
Also master commits are brought in.
2016-10-20 23:04:10 +02:00
Graham Christensen 4e89b237bc
xen: 4.5.2 -> 4.5.5, drop old versions 2016-10-14 17:09:18 -04:00
Vladimír Čunát 6eeea6effd Python: more evaluation fixups. 2016-10-14 00:03:12 +02:00
Kirill Boltaev e61663a233 treewide: move to ocaml-ng system 2016-09-26 02:36:49 +03:00
Robin Gloster 29c5ccea4a
xen: remove obsolete substituteInPlace 2016-08-27 21:54:30 +00:00
obadz 0e8d2725dc Merge branch 'master' into staging 2016-08-23 18:50:06 +01:00
Franz Pletz a12b2bfb8b xen: Fix build on Glibc 2.24 2016-08-23 19:17:36 +02:00
obadz 24a9183f90 Merge branch 'hardened-stdenv' into staging
Closes #12895

Amazing work by @globin & @fpletz getting hardened compiler flags by
enabled default on the whole package set
2016-08-22 01:19:35 +01:00
Jan Malakhovski fdca71776a xen: cleanup 4.5.0 expression a bit 2016-08-13 21:53:25 +00:00
Jan Malakhovski 16ce708555 xen: fix urls and hashes (fallout from #15469) 2016-08-13 21:53:24 +00:00
Robin Gloster d020caa5b2 Merge remote-tracking branch 'upstream/master' into hardened-stdenv 2016-04-18 13:49:22 +00:00
Vladimír Čunát ab15a62c68 Merge branch 'master' into closure-size
Beware that stdenv doesn't build. It seems something more will be needed
than just resolution of merge conflicts.
2016-04-01 10:06:01 +02:00
Robin Gloster 3f45f0948d Merge remote-tracking branch 'upstream/master' into hardened-stdenv 2016-03-15 01:44:24 +00:00
Domen Kožar 9ad60eae48 xen: remove unneeded depds now that stubdom is disabled 2016-03-09 18:56:25 +00:00
Domen Kožar 086a7d138d xen: disable stubdom due to #13590 2016-03-09 13:51:45 +00:00
Franz Pletz aff1f4ab94 Use general hardening flag toggle lists
The following parameters are now available:

  * hardeningDisable
    To disable specific hardening flags
  * hardeningEnable
    To enable specific hardening flags

Only the cc-wrapper supports this right now, but these may be reused by
other wrappers, builders or setup hooks.

cc-wrapper supports the following flags:

  * fortify
  * stackprotector
  * pie (disabled by default)
  * pic
  * strictoverflow
  * format
  * relro
  * bindnow
2016-03-05 18:55:26 +01:00
Robin Gloster a53bd9daa8 xen: turn off pic hardening 2016-02-11 01:44:23 +00:00
Robin Gloster 82daf82e61 xen: turn off fortify 2016-02-09 01:10:57 +00:00
Vladimír Čunát ae74c356d9 Merge recent 'staging' into closure-size
Let's get rid of those merge conflicts.
2016-02-03 16:57:19 +01:00
Robin Gloster 359b1726a5 xen: turn off stackprotector hardening 2016-01-30 16:36:57 +00:00
Robin Gloster f6d3b7a2ae switch hardening flags 2016-01-30 16:36:57 +00:00
Franz Pletz 954e9903ad Use a hardened stdenv by default 2016-01-30 16:36:57 +00:00
aszlig c92d7481a5
multipath_tools: Rename to multipath-tools
See http://nixos.org/nixpkgs/manual/#sec-package-naming

I've added an alias for multipath_tools to make sure that we don't break
existing configurations referencing the old name.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-01-21 16:18:38 +01:00
Luca Bruno 5b0352a6a4 Merge branch 'master' into closure-size 2015-12-11 18:31:00 +01:00
Michael Weiss 73058eb946 xen: 4.5.1 -> 4.5.2
Excerpt from upstream release notes:
This release also contains the security fixes for XSA-137, XSA-138, XSA-141 to XSA-153.
XSA-139 and XSA-140 only apply to QEMU Upstream and are fixed from versions 2.3.1 and 2.4.0 of QEMU.
The qemu portion of XSA-135 has also been applied to qemu-traditional.
2015-11-20 16:57:27 +01:00
Vladimír Čunát 91407a8bdf ncurses: split into multiple outputs
Some programs (e.g. tput) might better be moved somewhere else than
$dev/bin, but that can be improved later if need be.
2015-10-13 20:18:44 +02:00
Vladimír Čunát 88c9f8b574 xlibs: replace occurrences by xorg
This seems to have been confusing people, using both xlibs and xorg, etc.
- Avoided renaming local (and different) xlibs binding in gcc*.
- Fixed cases where both xorg and xlibs were used.
Hopefully everything still works as before.
2015-09-15 12:54:34 +02:00
Thomas Strobel e80b41e94f xen: remove 4.4.1 + fixes compilation of 4.5.x, fixes #9572 2015-09-02 08:33:24 +02:00
Thomas Strobel 2ff9129337 xen: fixes (authored by michalpalka)
Xen required a few changes in order to be usable:
* Include xenfs module in initrd as loading it in the activation
  script was failing.
* Include /etc/default/xendomains, which is needed by
  xen-domains service.
* Create /var/log/xen and /var/lib/xen directories in
  the xen-store service, which are needed by the xl command.
  The directories could be created by any other script as long as
  they are guaranteed to exist before xl is called.
* Fix a reference to /bin/ls in the xendomains script.
2015-07-15 12:38:37 +02:00
Thomas Strobel 649697ddcf Xen: add XEN 4.5.1 2015-07-02 16:37:03 +02:00
Thomas Strobel 6bd694321d Xen: enable Spice/QXL + add libhvm + minor fixes 2015-07-02 16:33:01 +02:00
Thomas Strobel 6ad73af7a2 Fix: Build Xen only for x86_64 Linux platforms. 2015-02-27 08:13:05 +01:00
Bjørn Forsman 34f8d2597c Fix eval (xen: bridge_utils => bridge-utils) 2015-02-26 20:49:33 +01:00
Thomas Strobel 3d4fbb874c Update: add new Xen versions + update NixOS Xen modules
Versions of XEN:
- Xen 4.5
- Xen 4.5 + XenServer patches
- Xen 4.4.1
2015-02-25 23:30:44 +01:00
Bjørn Forsman 97875ac175 bridge-utils: align attrname with pkgname 2015-02-20 22:30:51 +01:00
Thomas Strobel 732c303bb8 Update: Xen -> 4.4.1 2014-12-22 09:51:27 +01:00
Domen Kožar 58b6c4fce9 xen: note about security for next bump 2014-10-02 10:23:09 +02:00
Eelco Dolstra 8a7f3c3618 Mark a bunch of packages as broken or not supported on Darwin 2014-08-08 17:59:02 +02:00
Rob Vermaas 64561b437d Remove broken flag for xen, build with gcc45. 2014-08-01 17:18:27 +02:00
Eelco Dolstra 754704ea18 Allow packages to be marked as "broken" by setting meta.broken
The effect is that they won't show up in "nix-env -qa" anymore.
2013-11-04 21:11:00 +01:00
Jan Malakhovski da7408e105 xen: Support PCI passthrough.
Previous commit reverted Xen back to 4.0.3 because xend from 4.1.* and newer
hangs for unknown reasons.
The new "xl" toolstack from 4.1.* and unstable works, yet PCI passthrough is not
supported by xl in 4.1.* and is broken in the unstable.

With this patch I was able to passthrough ATI Radeon HD 6950 without 3D
acceleration, though, to both Linux and Windows guests. Which is the best
archived result with Xen PCI passthrough on NixOS after trying out all possible
Xen versions.
Same VGA card works fine if passed through into a guest with KVM (acceleration,
GPGPU, everything works). I should have tried KVM from the start.
2012-08-08 03:16:57 +04:00
Jan Malakhovski bff9f2720f Revert "xen: update to version 4.1.2"
This reverts commit af32fd6ce3.
2012-08-08 02:30:25 +04:00
Peter Simons af32fd6ce3 xen: update to version 4.1.2
Patch submitted by Jan Malakhovski <oxij@oxij.org>.
2012-07-02 17:45:47 +02:00
Eelco Dolstra a0bc441980 * Updated Xen to 4.0.3 (mostly to get it to build with GCC 4.6).
svn path=/nixpkgs/branches/stdenv-updates/; revision=32380
2012-02-18 00:18:26 +00:00
Eelco Dolstra ed58c55155 * xen: Build succesfully if $out already exists (needed for WCRE).
svn path=/nixpkgs/trunk/; revision=27580
2011-07-02 19:21:28 +00:00
Eelco Dolstra 353d450867 * wrapPythonPrograms: don't hard-code the Python library prefix.
svn path=/nixpkgs/branches/modular-python/; revision=26594
2011-03-29 15:19:59 +00:00
Eelco Dolstra c1b64da1c9 * xen: use wrapPython.
svn path=/nixpkgs/branches/modular-python/; revision=26584
2011-03-28 18:12:32 +00:00
Eelco Dolstra 770ca317ba * Get Xen to build with GCC 4.5 and Glibc 2.12.
svn path=/nixpkgs/branches/stdenv-updates/; revision=25247
2010-12-22 19:38:26 +00:00
Eelco Dolstra 3137cb5c59 * Apply some fixes to the xendomains script.
svn path=/nixpkgs/trunk/; revision=24120
2010-10-06 16:04:04 +00:00
Eelco Dolstra d11c271dcb * Install the Xen manpages.
svn path=/nixpkgs/trunk/; revision=24109
2010-10-06 11:04:07 +00:00
Eelco Dolstra b801c21d1f * Build Xen's stubdoms, in particular pv-grub (needed to securely boot
from a kernel/initrd stored on a guest filesystem).

svn path=/nixpkgs/trunk/; revision=24062
2010-10-04 23:25:03 +00:00
Eelco Dolstra fd538ef53d * Fix some more paths in Xen, and make it use /etc/xen for its
configuration files.

svn path=/nixpkgs/trunk/; revision=23821
2010-09-16 15:21:28 +00:00
Eelco Dolstra cdecced3b0 * Fix various references to /usr.
svn path=/nixpkgs/trunk/; revision=23788
2010-09-14 13:50:32 +00:00
Eelco Dolstra cea083bec9 * Set the Python search path for Xen's Python scripts. As an
experiment, do this by patching a line setting sys.path into the
  script, rather than using makeWrapper.
* Xen requires pythonFull because it needs https/ssl support.

svn path=/nixpkgs/trunk/; revision=23710
2010-09-10 10:53:17 +00:00
Eelco Dolstra c1867fe704 * Get Xen to build. It's not tested yet and doesn't include a Dom0
kernel.

svn path=/nixpkgs/trunk/; revision=23698
2010-09-09 16:45:18 +00:00
Marc Weber f7f938a1d1 big breaking change: renaming lib.getAttr to lib.attrByPath
getAttr was ambiguous. It's also a builtin function

fix

svn path=/nixpkgs/trunk/; revision=15692
2009-05-24 10:57:41 +00:00
Marc Weber 52647ea3b0 FullDepEntry -> fullDepEntry, PackEntry -> packEntry
svn path=/nixpkgs/trunk/; revision=15662
2009-05-19 23:25:58 +00:00
Michael Raskin 3a7ffa5c58 Some of preparation work for adding Xen. Troubles: 1. Xen Dom0 support not complete in mainline. 2. Xen's love to check for headers in /usr/include. To do afterwards: We need to change bootloading setup a bit.
svn path=/nixpkgs/trunk/; revision=12941
2008-10-04 15:24:08 +00:00