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

180 lines
5.3 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.
let
xsaPatch = { name , sha256 }: (fetchpatch {
url = "https://xenbits.xen.org/xsa/xsa${name}.patch";
inherit sha256;
});
2017-10-27 21:57:03 +00:00
xsa = import ./xsa-patches.nix { inherit fetchpatch; };
qemuDeps = [
udev pciutils xorg.libX11 SDL pixman acl glusterfs spice_protocol usbredir
alsaLib
];
in
callPackage (import ./generic.nix (rec {
2017-10-27 21:57:03 +00:00
version = "4.8.2";
src = fetchurl {
2017-10-27 21:57:03 +00:00
url = "https://downloads.xenproject.org/release/xen/${version}/xen-${version}.tar.gz";
sha256 = "1ydgwbn8ab0s16jrbi3wzaa6j0y3zk0j8pay458qcgayk3qc476b";
};
# 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 = "1v19pp86kcgwvsbkrdrn4rlaj02i4054avw8k70w1m0rnwgcsdbs";
};
buildInputs = qemuDeps;
patches = [
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 80e0cda7ff92233edc94161eae5838a1c423e5e4. 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 12:12:33 +00:00
(xsaPatch {
name = "216-qemuu";
2017-08-08 17:40:50 +00:00
sha256 = "06w2iw1r5gip2bpbg19cziws965h9in0f6np74cr31f76yy30yxn";
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 80e0cda7ff92233edc94161eae5838a1c423e5e4. 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 12:12:33 +00:00
})
];
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 = "0mryap5y53r09m7qc0b821f717ghwm654r8c3ik1w7adzxr0l5qk";
};
buildInputs = qemuDeps;
patches = [
];
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 = "f0cdc36d2f2424f6b40438f7ee7cc502c0eff4df";
sha256 = "1wq5pjkjrfzqnq3wyr15mcn1l4c563m65gdyf8jm97kgb13pwwfm";
};
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 = "173bf5c847e3ca8b42c11796ce048d8e2e916ff8";
sha256 = "07zmdj90zjrzip74fvd4ss8n8njk6cim85s58mc6snxmqqv7gmcr";
};
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 = "356f6c1b64d7a97746d1816cef8ca22bdd8d0b5d";
sha256 = "15n400vm3id5r8y3k6lrp9ab2911a9vh9856f5gvphkazfnmns09";
};
meta.description = "Xen's fork of iPXE";
};
} // optionalAttrs withLibHVM {
"xen-libhvm-dir-remote" = {
src = fetchgit {
name = "xen-libhvm";
url = https://github.com/michalpalka/xen-libhvm;
rev = "83065d36b36d6d527c2a4e0f5aaf0a09ee83122c";
sha256 = "1jzv479wvgjkazprqdzcdjy199azmx2xl3pnxli39kc5mvjz3lzd";
};
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";
2017-10-27 21:57:03 +00:00
patches = with xsa; flatten [
XSA_231
XSA_232
XSA_233
XSA_234_48
XSA_236
XSA_237_48
XSA_238
XSA_239
XSA_240_48
XSA_241
XSA_242
XSA_243_48
XSA_244
XSA_245
XSA_246
XSA_247_48
XSA_248_48
XSA_249
XSA_250
XSA_251_48
2017-10-27 21:57:03 +00:00
];
# 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