From dd3dcceb239915f6929e09fcaf27e0b119f021c7 Mon Sep 17 00:00:00 2001 From: Michał Pałka Date: Fri, 9 Jun 2017 13:08:07 +0000 Subject: 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 --- pkgs/applications/virtualization/xen/4.5.nix | 120 +++++++++++++++++++++++++++ 1 file changed, 120 insertions(+) (limited to 'pkgs') diff --git a/pkgs/applications/virtualization/xen/4.5.nix b/pkgs/applications/virtualization/xen/4.5.nix index 3fbdee981c45..c6aa15221604 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 \ @@ -218,10 +226,122 @@ callPackage (import ./generic.nix (rec { name = "204-4.5"; 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. -- cgit 1.4.1