Commit Graph

18 Commits

Author SHA1 Message Date
volth
87f5930c3f [bot]: remove unreferenced code 2018-07-20 18:48:37 +00:00
Herwig Hochleitner
d81f3ecb83 xen-4.8: fix qemu-xen build error in memfd.c
Apply 75e5b70e6b
see also https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg08648.html

cc @eelco @tstrobel @oxij
2018-04-13 22:06:52 +02:00
xeji
2b14491a77 xen 4.8.3: fix qemu-xen hash 2018-03-06 22:40:27 +01:00
xeji
1c357efdfc xen: 4.8.2 -> 4.8.3 2018-03-06 19:59:33 +01:00
xeji
73dbc73196 xen 4.8: add xsa security patches 252-256 2018-03-06 16:17:30 +01:00
xeji
c84cf5f642 xen 4.8: fix gcc7-related build errors 2018-03-05 20:54:55 +00:00
Jan Tojnar
a31d98f312
tree-wide: autorename gnome packages to use dashes 2018-02-25 17:41:16 +01:00
Jan Malakhovski
b1047f34f7 xenPackages.xen_4_8-vanilla: fix build of qemu-xen
They merged that XSA and moved the tag.
2018-02-18 13:46:44 +00:00
Jan Malakhovski
06adc17455 xen, qemu: passthru the path to qemu-system-i386 2018-02-09 19:51:07 +00:00
Graham Christensen
b5a61f2c59
Revert "nixos: doc: implement related packages in the manual" 2017-12-23 07:19:45 -05:00
Arseniy Seroka
36e02645eb
Merge pull request #32424 from oxij/nixos/related-packages
nixos: doc: implement related packages in the manual
2017-12-23 03:34:58 +03:00
Andreas Rammhold
276683071b
xen: Added patches for XSA-248, XSA-249, XSA-250, XSA-251 2017-12-12 13:34:35 +01:00
Andreas Rammhold
834bdd25a3 xen: apply patches for XSA-246 & XSA-247 (CVE-2017-{17044,17045}) 2017-12-12 13:20:03 +01:00
Jan Malakhovski
7a92c2074d xen, qemu: passthru the path to qemu-system-i386 2017-12-07 21:27:32 +00:00
Tim Steinbach
54f8dfda53
xen: Create XSA patch directory 2017-10-28 10:19:12 -04:00
Robert Hensing
57506bbb28 xen-4.8: update changed patch hash 2017-08-08 17:40:50 +00:00
Michał Pałka
7b5d72ce04 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
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
2017-06-27 12:02:59 +00:00
Michał Pałka
9e6bfbb2f9 xen_4_8: init at 4.8.1
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
2017-06-27 12:01:53 +00:00