[prev in list] [next in list] [prev in thread] [next in thread]
List: nix-commits
Subject: [Nix-commits] [NixOS/nixpkgs] 9e6bfb: xen_4_8: init at 4.8.1
From: Joachim F <joachifm () users ! noreply ! github ! com>
Date: 2017-06-30 19:27:06
Message-ID: 5956a60a3679f_5a5e3f7f6afc3c341136c1 () hookshot-fe5-cp1-prd ! iad ! github ! net ! mail
[Download RAW message or body]
Branch: refs/heads/master
Home: https://github.com/NixOS/nixpkgs
Commit: 9e6bfbb2f92d8e1995365775bee63809631b132c
https://github.com/NixOS/nixpkgs/commit/9e6bfbb2f92d8e1995365775bee=
63809631b132c
Author: Micha=C5=82 Pa=C5=82ka <michal.palka@chalmers.se>
Date: 2017-06-27 (Tue, 27 Jun 2017)
Changed paths:
M nixos/modules/virtualisation/xen-dom0.nix
A pkgs/applications/virtualization/xen/4.8.nix
M pkgs/applications/virtualization/xen/generic.nix
M pkgs/applications/virtualization/xen/packages.nix
M pkgs/top-level/all-packages.nix
Log Message:
-----------
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
Commit: 7b5d72ce048ffc48ba437560247bf069a87b1c73
https://github.com/NixOS/nixpkgs/commit/7b5d72ce048ffc48ba437560247=
bf069a87b1c73
Author: Micha=C5=82 Pa=C5=82ka <michal.palka@chalmers.se>
Date: 2017-06-27 (Tue, 27 Jun 2017)
Changed paths:
M pkgs/applications/virtualization/xen/4.8.nix
Log Message:
-----------
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 rat=
her
> 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 an=
d
> 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 t=
o be
> inserted into a PV guest's pagetables. At that point, the emulated wri=
te 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 feature=
s 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
Commit: a8ba50db3ed2fa3c60159921e11182216f7c07a3
https://github.com/NixOS/nixpkgs/commit/a8ba50db3ed2fa3c60159921e11=
182216f7c07a3
Author: Joachim F <joachifm@users.noreply.github.com>
Date: 2017-06-30 (Fri, 30 Jun 2017)
Changed paths:
M nixos/modules/virtualisation/xen-dom0.nix
A pkgs/applications/virtualization/xen/4.8.nix
M pkgs/applications/virtualization/xen/generic.nix
M pkgs/applications/virtualization/xen/packages.nix
M pkgs/top-level/all-packages.nix
Log Message:
-----------
Merge pull request #26492 from michalpalka/new-xen
xen_4_8: init at 4.8.1
Compare: https://github.com/NixOS/nixpkgs/compare/5fd4ae36e2b1...a8ba50db=
3ed2=
_______________________________________________
nix-commits mailing list
nix-commits@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-commits
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic