Commit graph

105 commits

Author SHA1 Message Date
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
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