2016-09-01 03:51:09 +02:00
|
|
|
{ stdenv, callPackage, fetchurl, fetchpatch, fetchgit
|
2018-07-17 22:11:16 +02:00
|
|
|
, ocaml-ng
|
2016-09-01 03:51:09 +02:00
|
|
|
, withInternalQemu ? true
|
|
|
|
|
, withInternalTraditionalQemu ? true
|
|
|
|
|
, withInternalSeabios ? true
|
|
|
|
|
, withSeabios ? !withInternalSeabios, seabios ? null
|
|
|
|
|
, withInternalOVMF ? false # FIXME: tricky to build
|
|
|
|
|
, withOVMF ? false, OVMF
|
|
|
|
|
, withLibHVM ? true
|
|
|
|
|
|
|
|
|
|
# qemu
|
2018-02-25 03:23:58 +01:00
|
|
|
, udev, pciutils, xorg, SDL, pixman, acl, glusterfs, spice-protocol, usbredir
|
2016-09-01 03:51:09 +02:00
|
|
|
, 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 16:37:03 +02:00
|
|
|
|
|
|
|
|
let
|
2016-09-01 03:51:09 +02:00
|
|
|
xsaPatch = { name , sha256 }: (fetchpatch {
|
|
|
|
|
url = "https://xenbits.xen.org/xsa/xsa${name}.patch";
|
|
|
|
|
inherit sha256;
|
|
|
|
|
});
|
2015-07-02 16:37:03 +02:00
|
|
|
|
2016-09-01 03:51:09 +02:00
|
|
|
qemuDeps = [
|
2018-02-25 03:23:58 +01:00
|
|
|
udev pciutils xorg.libX11 SDL pixman acl glusterfs spice-protocol usbredir
|
2016-09-01 03:51:09 +02:00
|
|
|
alsaLib
|
|
|
|
|
];
|
2017-10-27 23:57:03 +02:00
|
|
|
|
|
|
|
|
xsa = import ./xsa-patches.nix { inherit fetchpatch; };
|
2016-09-01 03:51:09 +02:00
|
|
|
in
|
2015-07-02 16:37:03 +02:00
|
|
|
|
2016-09-01 03:51:09 +02:00
|
|
|
callPackage (import ./generic.nix (rec {
|
|
|
|
|
version = "4.5.5";
|
2015-07-02 16:37:03 +02:00
|
|
|
|
2018-03-10 21:16:02 +01:00
|
|
|
meta = {
|
|
|
|
|
knownVulnerabilities = [ "Security support ended in January 2018" ];
|
|
|
|
|
};
|
|
|
|
|
|
2016-09-01 03:51:09 +02:00
|
|
|
src = fetchurl {
|
2017-10-27 23:57:03 +02:00
|
|
|
url = "https://downloads.xenproject.org/release/xen/${version}/xen-${version}.tar.gz";
|
2016-09-01 03:51:09 +02:00
|
|
|
sha256 = "1y74ms4yc3znf8jc3fgyq94va2y0pf7jh8m9pfqnpgklywqnw8g2";
|
2015-07-02 16:37:03 +02:00
|
|
|
};
|
|
|
|
|
|
2016-09-01 03:51:09 +02:00
|
|
|
# Sources needed to build tools and firmwares.
|
|
|
|
|
xenfiles = optionalAttrs withInternalQemu {
|
2019-08-13 23:52:01 +02:00
|
|
|
qemu-xen = {
|
2016-09-01 03:51:09 +02:00
|
|
|
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 15:08:07 +02:00
|
|
|
(xsaPatch {
|
|
|
|
|
name = "211-qemuu-4.6";
|
|
|
|
|
sha256 = "1g090xs8ca8676vyi78b99z5yjdliw6mxkr521b8kimhf8crx4yg";
|
|
|
|
|
})
|
xen: patch for XSAs: 216, 217, 218, 219, 220, 221, 222, and 224
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 09:00:00 +02:00
|
|
|
(xsaPatch {
|
|
|
|
|
name = "216-qemuu-4.5";
|
|
|
|
|
sha256 = "0nh5akbal93czia1gh1pzvwq7gc4zwiyr1hbyk1m6wwdmqv6ph61";
|
|
|
|
|
})
|
2016-09-01 03:51:09 +02:00
|
|
|
];
|
|
|
|
|
meta.description = "Xen's fork of upstream Qemu";
|
|
|
|
|
};
|
|
|
|
|
} // optionalAttrs withInternalTraditionalQemu {
|
2019-08-13 23:52:01 +02:00
|
|
|
qemu-xen-traditional = {
|
2016-09-01 03:51:09 +02:00
|
|
|
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 15:08:07 +02:00
|
|
|
(xsaPatch {
|
|
|
|
|
name = "211-qemut-4.5";
|
|
|
|
|
sha256 = "1z3phabvqmxv4b5923fx63hwdg4v1fnl15zbl88873ybqn0hp50f";
|
|
|
|
|
})
|
2016-09-01 03:51:09 +02:00
|
|
|
];
|
|
|
|
|
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 {
|
2019-08-13 23:52:01 +02:00
|
|
|
xen-libhvm-dir-remote = {
|
2016-09-01 03:51:09 +02:00
|
|
|
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"
|
|
|
|
|
|
2017-05-18 12:46:14 +02:00
|
|
|
++ optional (withOVMF) "--with-system-ovmf=${OVMF.fd}/FV/OVMF.fd"
|
2016-09-01 03:51:09 +02:00
|
|
|
++ optional (withInternalOVMF) "--enable-ovmf";
|
|
|
|
|
|
2017-10-27 23:57:03 +02:00
|
|
|
patches = with xsa; flatten [
|
|
|
|
|
./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
|
|
|
|
|
XSA_190
|
|
|
|
|
XSA_191
|
|
|
|
|
XSA_192
|
|
|
|
|
XSA_193
|
|
|
|
|
XSA_195
|
|
|
|
|
XSA_196
|
|
|
|
|
XSA_198
|
|
|
|
|
XSA_200
|
|
|
|
|
XSA_202_45
|
|
|
|
|
XSA_204_45
|
|
|
|
|
XSA_206_45
|
|
|
|
|
XSA_207
|
|
|
|
|
XSA_212
|
|
|
|
|
XSA_213_45
|
|
|
|
|
XSA_214
|
|
|
|
|
XSA_215
|
|
|
|
|
XSA_217_45
|
|
|
|
|
XSA_218_45
|
|
|
|
|
XSA_219_45
|
|
|
|
|
XSA_220_45
|
|
|
|
|
XSA_221
|
|
|
|
|
XSA_222_45
|
|
|
|
|
XSA_223
|
|
|
|
|
XSA_224_45
|
|
|
|
|
XSA_227_45
|
|
|
|
|
XSA_230
|
|
|
|
|
XSA_231_45
|
|
|
|
|
XSA_232
|
|
|
|
|
XSA_233
|
|
|
|
|
XSA_234_45
|
|
|
|
|
XSA_235_45
|
|
|
|
|
XSA_236_45
|
|
|
|
|
XSA_237_45
|
|
|
|
|
XSA_238_45
|
|
|
|
|
XSA_239_45
|
|
|
|
|
XSA_240_45
|
|
|
|
|
XSA_241
|
|
|
|
|
XSA_242
|
|
|
|
|
XSA_243_45
|
|
|
|
|
XSA_244_45
|
|
|
|
|
XSA_245
|
2017-12-04 20:05:52 +01:00
|
|
|
XSA_246_45
|
|
|
|
|
XSA_247_45
|
2017-12-12 13:34:35 +01:00
|
|
|
XSA_248_45
|
|
|
|
|
XSA_249
|
|
|
|
|
XSA_250_45
|
|
|
|
|
XSA_251_45
|
2017-10-27 23:57:03 +02:00
|
|
|
];
|
2016-09-01 03:51:09 +02: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
|
|
|
|
|
'';
|
|
|
|
|
|
2017-12-07 22:26:42 +01:00
|
|
|
passthru = {
|
|
|
|
|
qemu-system-i386 = if withInternalQemu
|
|
|
|
|
then "lib/xen/bin/qemu-system-i386"
|
|
|
|
|
else throw "this xen has no qemu builtin";
|
|
|
|
|
};
|
|
|
|
|
|
2018-07-17 22:11:16 +02:00
|
|
|
})) ({ ocamlPackages = ocaml-ng.ocamlPackages_4_02; } // args)
|
