2016-12-08 01:16:05 +00:00
|
|
|
{ callPackage, fetchurl, fetchpatch, fetchgit, ... } @ args:
|
2015-07-02 15:37:03 +01:00
|
|
|
|
|
|
|
let
|
2016-10-14 13:15:57 +01:00
|
|
|
# Xen 4.5.5
|
2016-12-21 13:56:03 +00:00
|
|
|
#
|
|
|
|
# Patching XEN? Check the XSAs and try applying all the ones we
|
|
|
|
# don't have yet.
|
|
|
|
#
|
|
|
|
# XSAs at: https://xenbits.xen.org/xsa/
|
2015-11-20 15:44:43 +00:00
|
|
|
xenConfig = rec {
|
2016-10-14 13:15:57 +01:00
|
|
|
version = "4.5.5";
|
2016-12-21 13:56:03 +00:00
|
|
|
|
|
|
|
xsaPatch = { name , sha256 }: (fetchpatch {
|
|
|
|
url = "https://xenbits.xen.org/xsa/xsa${name}.patch";
|
|
|
|
inherit sha256;
|
|
|
|
});
|
|
|
|
|
2015-11-20 15:44:43 +00:00
|
|
|
name = "xen-${version}";
|
2015-07-02 15:37:03 +01:00
|
|
|
|
|
|
|
src = fetchurl {
|
2015-11-20 15:44:43 +00:00
|
|
|
url = "http://bits.xensource.com/oss-xen/release/${version}/${name}.tar.gz";
|
2016-10-14 13:15:57 +01:00
|
|
|
sha256 = "1y74ms4yc3znf8jc3fgyq94va2y0pf7jh8m9pfqnpgklywqnw8g2";
|
2015-07-02 15:37:03 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
# Sources needed to build the xen tools and tools/firmware.
|
|
|
|
firmwareGits =
|
2016-10-14 13:15:57 +01:00
|
|
|
[
|
2015-07-02 15:37:03 +01:00
|
|
|
{ git = { name = "seabios";
|
2016-08-13 22:47:27 +01:00
|
|
|
url = https://xenbits.xen.org/git-http/seabios.git;
|
2016-10-14 13:15:57 +01:00
|
|
|
rev = "rel-1.7.5";
|
2016-08-13 22:47:27 +01:00
|
|
|
sha256 = "0jk54ybhmw97pzyhpm6jr2x99f702kbn0ipxv5qxcbynflgdazyb";
|
2015-07-02 15:37:03 +01:00
|
|
|
};
|
|
|
|
patches = [ ./0000-qemu-seabios-enable-ATA_DMA.patch ];
|
|
|
|
}
|
|
|
|
];
|
|
|
|
|
|
|
|
toolsGits =
|
2016-10-14 13:15:57 +01:00
|
|
|
[
|
2015-07-02 15:37:03 +01:00
|
|
|
{ git = { name = "qemu-xen";
|
2016-08-13 22:47:27 +01:00
|
|
|
url = https://xenbits.xen.org/git-http/qemu-xen.git;
|
2016-10-14 13:15:57 +01:00
|
|
|
rev = "refs/tags/qemu-xen-${version}";
|
|
|
|
sha256 = "014s755slmsc7xzy7qhk9i3kbjr2grxb5yznjp71dl6xxfvnday2";
|
2015-07-02 15:37:03 +01:00
|
|
|
};
|
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 12:59:26 +00:00
|
|
|
patches = [
|
|
|
|
(xsaPatch {
|
|
|
|
name = "197-4.5-qemuu";
|
|
|
|
sha256 = "09gp980qdlfpfmxy0nk7ncyaa024jnrpzx9gpq2kah21xygy5myx";
|
|
|
|
})
|
|
|
|
(xsaPatch {
|
|
|
|
name = "208-qemuu-4.7";
|
|
|
|
sha256 = "0z9b1whr8rp2riwq7wndzcnd7vw1ckwx0vbk098k2pcflrzppgrb";
|
|
|
|
})
|
|
|
|
(xsaPatch {
|
|
|
|
name = "209-qemuu";
|
|
|
|
sha256 = "05df4165by6pzxrnizkw86n2f77k9i1g4fqqpws81ycb9ng4jzin";
|
|
|
|
})
|
|
|
|
];
|
2015-07-02 15:37:03 +01:00
|
|
|
}
|
|
|
|
{ git = { name = "qemu-xen-traditional";
|
2016-08-13 22:47:27 +01:00
|
|
|
url = https://xenbits.xen.org/git-http/qemu-xen-traditional.git;
|
2016-10-14 13:15:57 +01:00
|
|
|
# rev = "28c21388c2a32259cff37fc578684f994dca8c9f";
|
|
|
|
rev = "refs/tags/xen-${version}";
|
|
|
|
sha256 = "0n0ycxlf1wgdjkdl8l2w1i0zzssk55dfv67x8i6b2ima01r0k93r";
|
2015-07-02 15:37:03 +01:00
|
|
|
};
|
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 12:59:26 +00:00
|
|
|
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";
|
|
|
|
})
|
|
|
|
];
|
2015-07-02 15:37:03 +01:00
|
|
|
}
|
|
|
|
{ git = { name = "xen-libhvm";
|
2016-08-13 22:47:27 +01:00
|
|
|
url = https://github.com/ts468/xen-libhvm;
|
2015-07-02 15:37:03 +01:00
|
|
|
rev = "442dcc4f6f4e374a51e4613532468bd6b48bdf63";
|
|
|
|
sha256 = "9ba97c39a00a54c154785716aa06691d312c99be498ebbc00dc3769968178ba8";
|
|
|
|
};
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
];
|
|
|
|
|
2016-12-21 13:56:03 +00:00
|
|
|
xenPatches = [ ./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: 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 12:59:26 +00:00
|
|
|
(xsaPatch {
|
|
|
|
name = "207";
|
|
|
|
sha256 = "0wdlhijmw9mdj6a82pyw1rwwiz605dwzjc392zr3fpb2jklrvibc";
|
|
|
|
})
|
2016-12-21 13:56:03 +00:00
|
|
|
];
|
2015-07-02 15:37:03 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
in callPackage ./generic.nix (args // { xenConfig=xenConfig; })
|