Commit Graph

777 Commits

Author SHA1 Message Date
Tim Steinbach
4cc729644e Merge pull request #26867 from michalpalka/xen-security-2017.06-new
xen: patch for XSAs: 216, 217, 218, 219, 220, 221, 222, and 224
2017-06-28 22:43:46 -04:00
Tim Steinbach
fb8a66dcc9 Merge pull request #26945 from NeQuissimus/virtualbox_32bit
virtualbox: Add ability to disable 32-bit guest support
2017-06-28 22:32:12 -04:00
Tim Steinbach
312c2f7961
virtualbox: Add ability to disable 32-bit guest support 2017-06-28 22:24:19 -04:00
Joachim Fasting
0bc3429e77
lkl: 2017-03-24 -> 2017-06-27
Now based on Linux 4.11
2017-06-28 20:14:00 +02:00
Tim Steinbach
add90948bc
docker: 17.03.1-ce -> 17.03.2-ce 2017-06-28 12:49:59 -04:00
Michał Pałka
80e0cda7ff 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 07:01:24 +00:00
Tim Steinbach
328617accd
rkt: 1.26.0 -> 1.27.0 2017-06-23 19:24:19 -04:00
aszlig
63fb845fcf
virtualbox: Rebase hardened.patch on top of 5.1.22
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>
2017-06-23 05:48:54 +02:00
Tim Steinbach
6fb9f89238 Merge pull request #25368 from bachp/virtualbox-5.1.22
virtualbox: 5.1.18 -> 5.1.22
2017-06-22 21:23:47 -04:00
Peter Hoeg
63011015b9 virtmanager-qt: 0.43.70.2 -> 0.43.72 2017-06-19 19:26:19 +08:00
Thomas Tuegel
c816bbc8a8
qt5: remove makeQtWrapper 2017-06-18 08:44:42 -05:00
Jörg Thalheim
f2e1e7f3cd Merge pull request #26503 from vdemeester/update-runc
Update runc to 1.0.0-rc3
2017-06-10 22:48:03 +01:00
Vincent Demeester
46b00e0b15
Update runc to 1.0.0-rc3
- Fix compilation problems
- Remove patches as those are included in the sources now

Signed-off-by: Vincent Demeester <vincent@sbr.pm>
2017-06-10 18:05:57 +02:00
Graham Christensen
7d8218a351 Merge pull request #26489 from michalpalka/xen-security
xen: patch for XSAs: 206, 211, 212, 213, 214 and 215
2017-06-09 09:31:42 -04:00
Michał Pałka
dd3dcceb23 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 13:09:01 +00:00
Vladimír Čunát
cc9a72a286
virtualboxGuestAdditions: don't install setuid/setgid 2017-06-09 13:09:21 +02:00
Michał Pałka
965668903a xen: fix pygrub by making sure it is wrapped
Recent commit #c10af9e744c91dff1ccc07a52a0b57d1e4d339f3 changed the
behaviour of wrapPythonPrograms, which caused pygrub to no longer
being wrapped. This commit fixes this.
2017-06-09 06:22:03 +00:00
midchildan
7060a692c5
virtmanager: Fix python import error 2017-06-05 23:42:25 +09:00
Robin Gloster
13f2f8673b
OVMF: fix build
$fd for the output was overwritten during the build
2017-05-29 12:21:17 +02:00
Tim Steinbach
9237459d60
rkt: 1.25.0 -> 1.26.0 2017-05-25 18:13:54 -04:00
Joachim Fasting
49ecd62c08
lkl: split outputs
Breaking out lib allows users to link against lkl without pulling the
kitchen sink into their closure.
2017-05-24 01:07:26 +02:00
Joachim Fasting
e0b623a56d
lkl: break description into longDescription and a briefer descr 2017-05-24 01:07:24 +02:00
Joachim Fasting
8c8f40a128
lkl: d747073 -> 2017-03-24
- 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
2017-05-24 01:07:23 +02:00
Joachim Fasting
e983d4306e
lkl: bc & python are native build inputs 2017-05-24 01:07:22 +02:00
Joachim Fasting
e845495edb
lkl: add meta.homepage 2017-05-24 01:07:14 +02:00
Peter Hoeg
5b45342832 virtmanager-qt: 0.43.70 -> 0.43.70.2 2017-05-23 17:54:20 +08:00
Joachim F
07ceaa2ec8 Merge pull request #25896 from joachifm/ovmf
ovmf: split firmware image files
2017-05-21 14:48:29 +01:00
Joachim Fasting
874b81b31f
treewide: s,enableParallelBuild(s),enableParallelBuilding,g 2017-05-20 17:16:17 +02:00
Joachim Fasting
252dcd62f3
OVMF: separate output for ovmf binaries
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
2017-05-20 12:33:48 +02:00
Jörg Thalheim
618f9aa52c
docker-proxy: remove go references
related to #25861
2017-05-17 22:14:34 +01:00
Peter Hoeg
68f335c6cd virtmanager-qt: 0.42.67 -> 0.43.70 2017-05-14 11:21:51 +08:00
Vincent Demeester
398f6ed7d3
docker-edge: 17.04 to 17.05
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
2017-05-09 10:11:05 +02:00
Frederik Rietdijk
ef4442e827 Python: replace requests2 with requests tree-wide
See f63eb58573

The `requests2` attribute now throws an error informing that `requests`
should be used instead.
2017-05-07 12:56:09 +02:00
Olegs Jeremejevs
670afd010c virt-manager: add requests as dependency 2017-05-07 12:15:19 +03:00
Frederik Rietdijk
95534bc4ee virtinst: do not depend on glanceclient
because its not a dependency and because its broken.
2017-05-07 10:02:33 +02:00
Frederik Rietdijk
e184e02e7a virt-manager: do not depend on glanceclient
because its not a dependency and because its broken.
2017-05-07 10:01:47 +02:00
Pascal Bach
c4a48600bf virtualbox: 5.1.18 -> 5.1.22 2017-04-30 22:55:23 +02:00
Michał Pałka
7c918ff7d4 virtualisation-xen: Fix xendomains startup
* Revert to using bash, not sh for the xendomains script to avoid syntax error
* Rewrite /bin/ls to ls in the xendomains script
2017-04-27 07:55:34 +00:00
Bjørn Forsman
ddb788b671 OVMF: get version number from edk2
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.)
2017-04-23 19:28:34 +02:00
Volth
1931ad0e2c qemu: 2.8.1 -> 2.9.0 2017-04-23 14:20:48 +02:00
Michael Raskin
f45f2fb67a Merge pull request #24549 from volth/qemu-2.8.1
qemu: 2.8.0 -> 2.8.1
2017-04-23 11:07:44 +02:00
Tim Steinbach
d95fb5f2ac Merge pull request #24632 from NeQuissimus/docker_17_04
docker-edge: init at 17.04
2017-04-05 20:51:14 -04:00
Tim Steinbach
1e589239b3
docker-edge: init at 17.04 2017-04-05 20:49:26 -04:00
Tim Steinbach
89188e2972
docker-distribution: 2.5.1 -> 2.6.0 2017-04-04 21:01:27 -04:00
Tim Steinbach
aefb9671bf
docker: 17.03.0 -> 17.03.1 2017-04-04 13:43:57 -04:00
Volth
160a84013e qemu: 2.8.0 -> 2.8.1 2017-04-02 00:21:56 +00:00
Franz Pletz
0018cd5a2d
libvirt packages: fix & clean up dependencies 2017-03-28 19:45:01 +02:00
Kosyrev Serge
0c3138e602 virtualbox: a more maintenance-free way of patching refs to dlopen()-affected dependencies 2017-03-28 01:32:11 +03:00
Nikolay Amiantov
52451067c7 virtualbox: wrap with Qt dependencies
Fixes GTK file open dialogs. Also make sure that linked applications really
exist, and update their list.
2017-03-28 00:29:40 +03:00
Franz Pletz
160fd7231e
virt-manager: needs file for building translations 2017-03-25 14:57:45 +01:00