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

1 files changed, 120 insertions, 0 deletions

diff --git a/pkgs/applications/virtualization/xen/4.5.nix b/pkgs/applications/virtualization/xen/4.5.nix
index 3fbdee981c4..c6aa1522160 100644
--- a/pkgs/applications/virtualization/xen/4.5.nix
+++ b/pkgs/applications/virtualization/xen/4.5.nix
@@ -67,6 +67,10 @@ callPackage (import ./generic.nix (rec {
           name = "209-qemuu/0002-cirrus-add-blit_is_unsafe-call-to-cirrus_bitblt_cput";
           sha256 = "0avxqs9922qjfsxxlk7bh10432a526j2yyykhags8dk1bzxkpxwv";
         })
+        (xsaPatch {
+          name = "211-qemuu-4.6";
+          sha256 = "1g090xs8ca8676vyi78b99z5yjdliw6mxkr521b8kimhf8crx4yg";
+        })
       ];
       meta.description = "Xen's fork of upstream Qemu";
     };
@@ -95,6 +99,10 @@ callPackage (import ./generic.nix (rec {
           name = "209-qemut";
           sha256 = "1hq8ghfzw6c47pb5vf9ngxwgs8slhbbw6cq7gk0nam44rwvz743r";
         })
+        (xsaPatch {
+          name = "211-qemut-4.5";
+          sha256 = "1z3phabvqmxv4b5923fx63hwdg4v1fnl15zbl88873ybqn0hp50f";
+        })
       ];
       postPatch = ''
         substituteInPlace xen-hooks.mak \
@@ -219,9 +227,121 @@ callPackage (import ./generic.nix (rec {
         sha256 = "083z9pbdz3f532fnzg7n2d5wzv6rmqc0f4mvc3mnmkd0rzqw8vcp";
       })
       (xsaPatch {
+        name = "206-4.5/0001-xenstored-apply-a-write-transaction-rate-limit";
+        sha256 = "07vsm8mlbxh2s01ny2xywnm1bqhhxas1az31fzwb6f1g14vkzwm4";
+      })
+      (xsaPatch {
+        name = "206-4.5/0002-xenstored-Log-when-the-write-transaction-rate-limit-";
+        sha256 = "17pnvxjmhny22abwwivacfig4vfsy5bqlki07z236whc2y7yzbsx";
+      })
+      (xsaPatch {
+        name = "206-4.5/0003-oxenstored-refactor-putting-response-on-wire";
+        sha256 = "0xf566yicnisliy82cydb2s9k27l3bxc43qgmv6yr2ir3ixxlw5s";
+      })
+      (xsaPatch {
+        name = "206-4.5/0004-oxenstored-remove-some-unused-parameters";
+        sha256 = "16cqx9i0w4w3x06qqdk9rbw4z96yhm0kbc32j40spfgxl82d1zlk";
+      })
+      (xsaPatch {
+        name = "206-4.5/0005-oxenstored-refactor-request-processing";
+        sha256 = "1g2hzlv7w03sqnifbzda85mwlz3bw37rk80l248180sv3k7k6bgv";
+      })
+      (xsaPatch {
+        name = "206-4.5/0006-oxenstored-keep-track-of-each-transaction-s-operatio";
+        sha256 = "0n65yfxvpfd4cz95dpbwqj3nablyzq5g7a0klvi2y9zybhch9cmg";
+      })
+      (xsaPatch {
+        name = "206-4.5/0007-oxenstored-move-functions-that-process-simple-operat";
+        sha256 = "0qllvbc9rnj7jhhlslxxs35gvphvih0ywz52jszj4irm23ka5vnz";
+      })
+      (xsaPatch {
+        name = "206-4.5/0008-oxenstored-replay-transaction-upon-conflict";
+        sha256 = "0lixkxjfzciy9l0f980cmkr8mcsx14c289kg0mn5w1cscg0hb46g";
+      })
+      (xsaPatch {
+        name = "206-4.5/0009-oxenstored-log-request-and-response-during-transacti";
+        sha256 = "09ph8ddcx0k7rndd6hx6kszxh3fhxnvdjsq13p97n996xrpl1x7b";
+      })
+      (xsaPatch {
+        name = "206-4.5/0010-oxenstored-allow-compilation-prior-to-OCaml-3.12.0";
+        sha256 = "1y0m7sqdz89z2vs4dfr45cyvxxas323rxar0xdvvvivgkgxawvxj";
+      })
+      (xsaPatch {
+        name = "206-4.5/0011-oxenstored-comments-explaining-some-variables";
+        sha256 = "1d3n0y9syya4kaavrvqn01d3wsn85gmw7qrbylkclznqgkwdsr2p";
+      })
+      (xsaPatch {
+        name = "206-4.5/0012-oxenstored-handling-of-domain-conflict-credit";
+        sha256 = "12zgid5y9vrhhpk2syxp0x01lzzr6447fa76n6rjmzi1xgdzpaf8";
+      })
+      (xsaPatch {
+        name = "206-4.5/0013-oxenstored-ignore-domains-with-no-conflict-credit";
+        sha256 = "0v3g9pm60w6qi360hdqjcw838s0qcyywz9qpl8gzmhrg7a35avxl";
+      })
+      (xsaPatch {
+        name = "206-4.5/0014-oxenstored-add-transaction-info-relevant-to-history-";
+        sha256 = "0vv3w0h5xh554i9v2vbc8gzm8wabjf2vzya3dyv5yzvly6ygv0sb";
+      })
+      (xsaPatch {
+        name = "206-4.5/0015-oxenstored-support-commit-history-tracking";
+        sha256 = "1iv2vy29g437vj73x9p33rdcr5ln2q0kx1b3pgxq202ghbc1x1zj";
+      })
+      (xsaPatch {
+        name = "206-4.5/0016-oxenstored-only-record-operations-with-side-effects-";
+        sha256 = "1cjkw5ganbg6lq78qsg0igjqvbgph3j349faxgk1p5d6nr492zzy";
+      })
+      (xsaPatch {
+        name = "206-4.5/0017-oxenstored-discard-old-commit-history-on-txn-end";
+        sha256 = "0lm15lq77403qqwpwcqvxlzgirp6ffh301any9g401hs98f9y4ps";
+      })
+      (xsaPatch {
+        name = "206-4.5/0018-oxenstored-track-commit-history";
+        sha256 = "1jh92p6vjhkm3bn5vz260npvsjji63g2imsxflxs4f3r69sz1nkd";
+      })
+      (xsaPatch {
+        name = "206-4.5/0019-oxenstored-blame-the-connection-that-caused-a-transa";
+        sha256 = "17k264pk0fvsamj85578msgpx97mw63nmj0j9v5hbj4bgfazvj4h";
+      })
+      (xsaPatch {
+        name = "206-4.5/0020-oxenstored-allow-self-conflicts";
+        sha256 = "15z3rd49q0pa72si0s8wjsy2zvbm613d0hjswp4ikc6nzsnsh4qy";
+      })
+      (xsaPatch {
+        name = "206-4.5/0021-oxenstored-do-not-commit-read-only-transactions";
+        sha256 = "04wpzazhv90lg3228z5i6vnh1z4lzd08z0d0fvc4br6pkd0w4va8";
+      })
+      (xsaPatch {
+        name = "206-4.5/0022-oxenstored-don-t-wake-to-issue-no-conflict-credit";
+        sha256 = "1shbrn0w68rlywcc633zcgykfccck1a77igmg8ydzwjsbwxsmsjy";
+      })
+      (xsaPatch {
+        name = "206-4.5/0023-oxenstored-transaction-conflicts-improve-logging";
+        sha256 = "1086y268yh8047k1vxnxs2nhp6izp7lfmq01f1gq5n7jiy1sxcq7";
+      })
+      (xsaPatch {
+        name = "206-4.5/0024-oxenstored-trim-history-in-the-frequent_ops-function";
+        sha256 = "014zs6i4gzrimn814k5i7gz66vbb0adkzr2qyai7i4fxc9h9r7w8";
+      })
+      (xsaPatch {
         name = "207";
         sha256 = "0wdlhijmw9mdj6a82pyw1rwwiz605dwzjc392zr3fpb2jklrvibc";
       })
+      (xsaPatch {
+        name = "212";
+        sha256 = "1ggjbbym5irq534a3zc86md9jg8imlpc9wx8xsadb9akgjrr1r8d";
+      })
+      (xsaPatch {
+        name = "213-4.5";
+        sha256 = "1vnqf89ydacr5bq3d6z2r33xb2sn5vsd934rncyc28ybc9rvj6wm";
+      })
+      (xsaPatch {
+        name = "214";
+        sha256 = "0qapzx63z0yl84phnpnglpkxp6b9sy1y7cilhwjhxyigpfnm2rrk";
+      })
+      (xsaPatch {
+        name = "215";
+        sha256 = "0sv8ccc5xp09f1w1gj5a9n3mlsdsh96sdb1n560vh31f4kkd61xs";
+      })
     ];
 
   # Fix build on Glibc 2.24.