This updates to the new runc as was also done upstream:
f3ef17e47d
In particular, it fixes an issue where output of interactive docker containers
would not reset correctly to the beginning of a line.
* pkgs: refactor needless quoting of homepage meta attribute
A lot of packages are needlessly quoting the homepage meta attribute
(about 1400, 22%), this commit refactors all of those instances.
* pkgs: Fixing some links that were wrongfully unquoted in the previous
commit
* Fixed some instances
Compiling the kernel modules on Linux 4.12 fails, so I've included an
upstream patch from:
https://www.virtualbox.org/changeset/66927/vbox
The patch is applied against the guest additions as well, where we need
to transform the patch a bit so that we get CR LF line endings (DOS
format), which is what is the case for the guest additions ISO.
I've tested this with all the subtests of the "virtualbox" NixOS VM
tests and they all succeed on x86_64-linux.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
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
80e0cda7ff.
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
This commit adds the xen_4_8 package to be used instead of
xen (currently at 4.5.5):
* Add packages xen_4_8, xen_4_8-slim and xen_4_8-light
* Add packages qemu_xen_4_8 and qemu_xen_4_8-light to be used
with xen_4_8-slim and xen_4_8-light respectively.
* Add systemd to buildInputs of xen (it is required by oxenstored)
* Adapt xen service to work with the new version of xen
* Use xen-init-dom0 to initlilise dom0 in xen-store
* Currently, the virtualisation.xen.stored option is ignored
if xen 4.8 is used
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
The merge of the version bump in
6fb9f89238 didn't take care of our patch
for the hardening mode and thus enabling VirtualBox without also
force-disabling hardening mode will result in a build error.
While the patch is largely identical with the old version, I've removed
one particular change around the following code:
if (pFsObjState->Stat.st_mode & S_IWOTH)
return supR3HardenedSetError3(VERR_SUPLIB_WORLD_WRITABLE, pErrInfo,
"World writable: '", pszPath, "'");
In the old version of the patch we have checked whether the path is
within the Nix store and suppressed the error return if that's the case.
The reason why I did that in the first place was because we had a bunch
of symlinks which were writable.
In VirtualBox 5.1.22 the code specifically checks whether the file is a
symlink, so we can safely drop our change.
Tested via all of the "virtualbox" NixOS VM subtests and they now all
succeed.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
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
Recent commit #c10af9e744c91dff1ccc07a52a0b57d1e4d339f3 changed the
behaviour of wrapPythonPrograms, which caused pygrub to no longer
being wrapped. This commit fixes this.
- Moves to a more recent kernel (4.10, I think ...)
- API break re the previous version
- cptofs: fix root directory copy
- add support for disks with custom ops
- add LKL_HIJACK_NET_QDISC to configure qdisc policy
- add LKL_HIJACK_SYSCTL to configure sysctl values
OVMF{,CODE,VARS}.fd are now available in a dedicated fd output, greatly
reducing the closure in the common case where only those files are used (a
few MBs versus several hundred MBs for the full OVMF).
Note: it's unclear why `dontPatchELF` is now necessary for the build to
pass (on my end, at any rate) but it doesn't make much sense to run this
fixup anyway,
Note: my reading of xen's INSTALL suggests that --with-system-ovmf should
point directly to the OVMF binary. As such, the previous invocation was
incorrect (it pointed to the root of the OVMF tree). In any case, I have
only built xen with `--with-system-ovmf`, I have not tested it.
Fixes https://github.com/NixOS/nixpkgs/issues/25854
Closes https://github.com/NixOS/nixpkgs/pull/25855
OVMF is built from edk2 sources so that's where its version number comes
from (logically). The edk2 version number is 2014-12-10, so this change
only ensures the version numbers won't drift apart in the future. (There
is no hash change.)
