Commit graph

114 commits

Author SHA1 Message Date
Robin Gloster dcdf68ee01
xen_4_10: 4.10.0 -> 4.10.4
glusterfs compatibility fix, also added Wno-error flags for gcc8
compatibility
2019-09-14 14:06:16 +02:00
Daniel Schaefer dc0e697038 xen: Ignore GCC8 errors 2019-09-13 15:12:18 +02:00
volth 08f68313a4 treewide: remove redundant rec 2019-08-28 11:07:32 +00:00
Frederik Rietdijk 5061fe0c2c Merge staging-next into staging 2019-08-28 08:26:42 +02:00
volth 35d68ef143 treewide: remove redundant quotes 2019-08-26 21:40:19 +00:00
Danylo Hlynskyi 8fe244edce
fix hash 2019-08-21 20:18:14 +03:00
danbst f0a805f5e5 xen: 4.8.3 -> 4.8.5, unbreak
It was broken during GlusterFs upgrade: https://github.com/NixOS/nixpkgs/pull/66736
2019-08-20 23:28:13 +03:00
Frederik Rietdijk d531da6f8a
Merge pull request #54094 from rnhmjoj/shell
treewide: use ${stdenv.shell} instead of /bin/sh where possible
2019-01-19 14:15:51 +01:00
rnhmjoj bcf54ce5bb
treewide: use ${stdenv.shell} instead of /bin/sh where possible 2019-01-16 20:37:15 +01:00
Will Dietz 48027e8373 xen: patch to work with newer acpica-tools (iasl)
https://xenbits.xen.org/gitweb/?p=xen.git;a=patch;h=858dbaaeda33b05c1ac80aea0ba9a03924e09005

Local copy to ensure stable.

https://lists.xenproject.org/archives/html/xen-devel/2018-06/msg01172.html
2018-12-19 13:42:44 -06:00
Benjamin Hipple 87a089bacc xen: add license 2018-10-09 21:29:08 -04:00
Vincent Laporte 8a23558db1
xen_4_10: use OCaml 4.05 2018-08-29 12:49:35 +00:00
Vincent Laporte 6a220840af
xen_4_8: use OCaml 4.05 2018-08-29 12:49:34 +00:00
Frederik Rietdijk 1a6af9f88e
Merge pull request #43857 from volth/unused
[bot] treewide: remove unreferenced code
2018-07-20 21:06:32 +02:00
volth 87f5930c3f [bot]: remove unreferenced code 2018-07-20 18:48:37 +00:00
Matthew Bauer 76999cc40e treewide: remove aliases in nixpkgs
This makes the command ‘nix-env -qa -f. --arg config '{skipAliases =
true;}'’ work in Nixpkgs.

Misc...

- qtikz: use libsForQt5.callPackage

  This ensures we get the right poppler.

- rewrites:

  docbook5_xsl -> docbook_xsl_ns
  docbook_xml_xslt -> docbook_xsl

diffpdf: fixup
2018-07-18 23:25:20 -04:00
Orivej Desh b42cf67084 xen: enable parallel building 2018-06-09 07:22:29 +00:00
xeji 3c4efe448d xen_4_10: fix build (qemu-xen memfd patch) 2018-04-29 00:58:50 +02:00
Herwig Hochleitner d81f3ecb83 xen-4.8: fix qemu-xen build error in memfd.c
Apply 75e5b70e6b
see also https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg08648.html

cc @eelco @tstrobel @oxij
2018-04-13 22:06:52 +02:00
Jan Malakhovski 3e3d72b95a xenPackages: deprecate Xen 4.5, security support ended 2018-03-10 21:35:55 +00:00
xeji fc790cb0f6 xen: add v 4.10 2018-03-07 22:38:45 +01:00
xeji fbc0b8282e xen: fix broken version comparisons
string compare breaks with xen 4.10 (because "4.10" < "4.8")
2018-03-07 22:37:40 +01:00
xeji 2b14491a77 xen 4.8.3: fix qemu-xen hash 2018-03-06 22:40:27 +01:00
xeji 1c357efdfc xen: 4.8.2 -> 4.8.3 2018-03-06 19:59:33 +01:00
xeji 73dbc73196 xen 4.8: add xsa security patches 252-256 2018-03-06 16:17:30 +01:00
xeji c84cf5f642 xen 4.8: fix gcc7-related build errors 2018-03-05 20:54:55 +00:00
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