nixpkgs/pkgs/applications/virtualization/xen/4.5.nix

358 lines
13 KiB
Nix
Raw Normal View History

{ stdenv, callPackage, fetchurl, fetchpatch, fetchgit
, withInternalQemu ? true
, withInternalTraditionalQemu ? true
, withInternalSeabios ? true
, withSeabios ? !withInternalSeabios, seabios ? null
, withInternalOVMF ? false # FIXME: tricky to build
, withOVMF ? false, OVMF
, withLibHVM ? true
# qemu
, udev, pciutils, xorg, SDL, pixman, acl, glusterfs, spice_protocol, usbredir
, alsaLib
, ... } @ args:
assert withInternalSeabios -> !withSeabios;
assert withInternalOVMF -> !withOVMF;
with stdenv.lib;
# Patching XEN? Check the XSAs at
# https://xenbits.xen.org/xsa/
# and try applying all the ones we don't have yet.
2015-07-02 14:37:03 +00:00
let
xsaPatch = { name , sha256 }: (fetchpatch {
url = "https://xenbits.xen.org/xsa/xsa${name}.patch";
inherit sha256;
});
2015-07-02 14:37:03 +00:00
qemuDeps = [
udev pciutils xorg.libX11 SDL pixman acl glusterfs spice_protocol usbredir
alsaLib
];
in
2015-07-02 14:37:03 +00:00
callPackage (import ./generic.nix (rec {
version = "4.5.5";
2015-07-02 14:37:03 +00:00
src = fetchurl {
url = "http://bits.xensource.com/oss-xen/release/${version}/xen-${version}.tar.gz";
sha256 = "1y74ms4yc3znf8jc3fgyq94va2y0pf7jh8m9pfqnpgklywqnw8g2";
2015-07-02 14:37:03 +00:00
};
# Sources needed to build tools and firmwares.
xenfiles = optionalAttrs withInternalQemu {
"qemu-xen" = {
src = fetchgit {
url = https://xenbits.xen.org/git-http/qemu-xen.git;
rev = "refs/tags/qemu-xen-${version}";
sha256 = "014s755slmsc7xzy7qhk9i3kbjr2grxb5yznjp71dl6xxfvnday2";
};
buildInputs = qemuDeps;
patches = [
(xsaPatch {
name = "197-4.5-qemuu";
sha256 = "09gp980qdlfpfmxy0nk7ncyaa024jnrpzx9gpq2kah21xygy5myx";
})
(xsaPatch {
name = "208-qemuu-4.7";
sha256 = "0z9b1whr8rp2riwq7wndzcnd7vw1ckwx0vbk098k2pcflrzppgrb";
})
(xsaPatch {
name = "209-qemuu/0001-display-cirrus-ignore-source-pitch-value-as-needed-i";
sha256 = "1xvxzsrsq05fj6szjlpbgg4ia3cw54dn5g7xzq1n1dymbhv606m0";
})
(xsaPatch {
name = "209-qemuu/0002-cirrus-add-blit_is_unsafe-call-to-cirrus_bitblt_cput";
sha256 = "0avxqs9922qjfsxxlk7bh10432a526j2yyykhags8dk1bzxkpxwv";
})
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:08:07 +00:00
(xsaPatch {
name = "211-qemuu-4.6";
sha256 = "1g090xs8ca8676vyi78b99z5yjdliw6mxkr521b8kimhf8crx4yg";
})
];
meta.description = "Xen's fork of upstream Qemu";
};
} // optionalAttrs withInternalTraditionalQemu {
"qemu-xen-traditional" = {
src = fetchgit {
url = https://xenbits.xen.org/git-http/qemu-xen-traditional.git;
rev = "refs/tags/xen-${version}";
sha256 = "0n0ycxlf1wgdjkdl8l2w1i0zzssk55dfv67x8i6b2ima01r0k93r";
};
buildInputs = qemuDeps;
patches = [
(xsaPatch {
name = "197-4.5-qemut";
sha256 = "17l7npw00gyhqzzaqamwm9cawfvzm90zh6jjyy95dmqbh7smvy79";
})
(xsaPatch {
name = "199-trad";
sha256 = "0dfw6ciycw9a9s97sbnilnzhipnzmdm9f7xcfngdjfic8cqdcv42";
})
(xsaPatch {
name = "208-qemut";
sha256 = "0960vhchixp60j9h2lawgbgzf6mpcdk440kblk25a37bd6172l54";
})
(xsaPatch {
name = "209-qemut";
sha256 = "1hq8ghfzw6c47pb5vf9ngxwgs8slhbbw6cq7gk0nam44rwvz743r";
})
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:08:07 +00:00
(xsaPatch {
name = "211-qemut-4.5";
sha256 = "1z3phabvqmxv4b5923fx63hwdg4v1fnl15zbl88873ybqn0hp50f";
})
];
postPatch = ''
substituteInPlace xen-hooks.mak \
--replace /usr/include/pci ${pciutils}/include/pci
'';
meta.description = "Xen's fork of upstream Qemu that uses old device model";
};
} // optionalAttrs withInternalSeabios {
"firmware/seabios-dir-remote" = {
src = fetchgit {
url = https://xenbits.xen.org/git-http/seabios.git;
rev = "e51488c5f8800a52ac5c8da7a31b85cca5cc95d2";
#rev = "rel-1.7.5";
sha256 = "0jk54ybhmw97pzyhpm6jr2x99f702kbn0ipxv5qxcbynflgdazyb";
};
patches = [ ./0000-qemu-seabios-enable-ATA_DMA.patch ];
meta.description = "Xen's fork of Seabios";
};
} // optionalAttrs withInternalOVMF {
"firmware/ovmf-dir-remote" = {
src = fetchgit {
url = https://xenbits.xen.org/git-http/ovmf.git;
rev = "cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd";
sha256 = "07zmdj90zjrzip74fvd4ss8n8njk6cim85s58mc6snxmqqv7gmcq";
};
meta.description = "Xen's fork of OVMF";
};
} // {
# TODO: patch Xen to make this optional?
"firmware/etherboot/ipxe.git" = {
src = fetchgit {
url = https://git.ipxe.org/ipxe.git;
rev = "9a93db3f0947484e30e753bbd61a10b17336e20e";
sha256 = "1ga3h1b34q0cl9azj7j9nswn7mfcs3cgfjdihrm5zkp2xw2hpvr6";
};
meta.description = "Xen's fork of iPXE";
};
} // optionalAttrs withLibHVM {
"xen-libhvm-dir-remote" = {
src = fetchgit {
name = "xen-libhvm";
url = https://github.com/ts468/xen-libhvm;
rev = "442dcc4f6f4e374a51e4613532468bd6b48bdf63";
sha256 = "9ba97c39a00a54c154785716aa06691d312c99be498ebbc00dc3769968178ba8";
};
buildPhase = ''
make
cd biospt
cc -Wall -g -D_LINUX -Wstrict-prototypes biospt.c -o biospt -I../libhvm -L../libhvm -lxenhvm
'';
installPhase = ''
make install
cp biospt/biospt $out/bin/
'';
meta = {
description = ''
Helper library for reading ACPI and SMBIOS firmware values
from the host system for use with the HVM guest firmware
pass-through feature in Xen'';
license = licenses.bsd2;
};
};
};
configureFlags = []
++ optional (!withInternalQemu) "--with-system-qemu" # use qemu from PATH
++ optional (withInternalTraditionalQemu) "--enable-qemu-traditional"
++ optional (!withInternalTraditionalQemu) "--disable-qemu-traditional"
++ optional (withSeabios) "--with-system-seabios=${seabios}"
++ optional (!withInternalSeabios && !withSeabios) "--disable-seabios"
++ optional (withOVMF) "--with-system-ovmf=${OVMF.fd}/FV/OVMF.fd"
++ optional (withInternalOVMF) "--enable-ovmf";
patches =
[ ./0001-libxl-Spice-image-compression-setting-support-for-up.patch
./0002-libxl-Spice-streaming-video-setting-support-for-upst.patch
./0003-Add-qxl-vga-interface-support-for-upstream-qem.patch
(xsaPatch {
name = "190-4.5";
sha256 = "0f8pw38kkxky89ny3ic5h26v9zsjj9id89lygx896zc3w1klafqm";
})
(xsaPatch {
name = "191-4.6";
sha256 = "1wl1ndli8rflmc44pkp8cw4642gi8z7j7gipac8mmlavmn3wdqhg";
})
(xsaPatch {
name = "192-4.5";
sha256 = "0m8cv0xqvx5pdk7fcmaw2vv43xhl62plyx33xqj48y66x5z9lxpm";
})
(xsaPatch {
name = "193-4.5";
sha256 = "0k9mykhrpm4rbjkhv067f6s05lqmgnldcyb3vi8cl0ndlyh66lvr";
})
(xsaPatch {
name = "195";
sha256 = "0m0g953qnjy2knd9qnkdagpvkkgjbk3ydgajia6kzs499dyqpdl7";
})
(xsaPatch {
name = "196-0001-x86-emul-Correct-the-IDT-entry-calculation-in-inject";
sha256 = "0z53nzrjvc745y26z1qc8jlg3blxp7brawvji1hx3s74n346ssl6";
})
(xsaPatch {
name = "196-0002-x86-svm-Fix-injection-of-software-interrupts";
sha256 = "11cqvr5jn2s92wsshpilx9qnfczrd9hnyb5aim6qwmz3fq3hrrkz";
})
(xsaPatch {
name = "198";
sha256 = "0d1nndn4p520c9xa87ixnyks3mrvzcri7c702d6mm22m8ansx6d9";
})
(xsaPatch {
name = "200-4.6";
sha256 = "0k918ja83470iz5k4vqi15293zjvz2dipdhgc9sy9rrhg4mqncl7";
})
(xsaPatch {
name = "202-4.6";
sha256 = "0nnznkrvfbbc8z64dr9wvbdijd4qbpc0wz2j5vpmx6b32sm7932f";
})
(xsaPatch {
name = "204-4.5";
sha256 = "083z9pbdz3f532fnzg7n2d5wzv6rmqc0f4mvc3mnmkd0rzqw8vcp";
})
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:08:07 +00:00
(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";
})
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:08:07 +00:00
(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.
NIX_CFLAGS_COMPILE = "-Wno-error=deprecated-declarations";
postPatch = ''
# Avoid a glibc >= 2.25 deprecation warnings that get fatal via -Werror.
sed 1i'#include <sys/sysmacros.h>' \
-i tools/blktap2/control/tap-ctl-allocate.c \
-i tools/libxl/libxl_device.c
'';
})) args