This makes make-disk-image.nix slightly more consistent with other image
builders we have. Unfortunately I duplicated some code in doing so, but
this is temporary duplication on the path to consolidating everything.
See https://github.com/NixOS/nixpkgs/issues/23052 for more details on that.
I'm also exposing the option in the amazon-image.nix maintainer module.
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
