=> Bootstrap dependency digest>=20010302: found digest-20190127 ===> Skipping vulnerability checks. WARNING: No /var/db/pkg/pkg-vulnerabilities file found. WARNING: To fix run: `/usr/sbin/pkg_admin -K /var/db/pkg fetch-pkg-vulnerabilities'. => Checksum SHA1 OK for xen-4.2.5.tar.gz => Checksum RMD160 OK for xen-4.2.5.tar.gz => Checksum SHA512 OK for xen-4.2.5.tar.gz ===> Installing dependencies for xenkernel42-4.2.5nb16 ========================================================================== The following variables will affect the build process of this package, xenkernel42-4.2.5nb16. Their current value is shown below: * PYTHON_VERSION_DEFAULT = 37 Based on these variables, the following variables have been set: * PYPACKAGE = python27 You may want to abort the process now with CTRL-C and change their value before continuing. Be sure to run `/usr/bin/make clean' after the changes. ========================================================================== => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 => Tool dependency checkperms>=1.1: found checkperms-1.12 => Build dependency python27>=2.7.1nb2: found python27-2.7.16 => Build dependency cwrappers>=20150314: found cwrappers-20180325 ===> Overriding tools for xenkernel42-4.2.5nb16 ===> Extracting for xenkernel42-4.2.5nb16 ===> Patching for xenkernel42-4.2.5nb16 => Applying pkgsrc patches for xenkernel42-4.2.5nb16 => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2014-8594 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2014-8594 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-CVE-2014-8594,v 1.1 2014/11/27 15:20:31 bouyer Exp $ | |x86: don't allow page table updates on non-PV page tables in do_mmu_update() | |paging_write_guest_entry() and paging_cmpxchg_guest_entry() aren't |consistently supported for non-PV guests (they'd deref NULL for PVH or |non-HAP HVM ones). Don't allow respective MMU_* operations on the |page tables of such domains. | |This is XSA-109. | |Signed-off-by: Jan Beulich |Acked-by: Tim Deegan | |--- xen/arch/x86/mm.c.orig |+++ xen/arch/x86/mm.c -------------------------- Patching file xen/arch/x86/mm.c using Plan A... Hunk #1 succeeded at 3794 (offset -6 lines). done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2014-8595 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2014-8595 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-CVE-2014-8595,v 1.1 2014/11/27 15:20:31 bouyer Exp $ | |x86emul: enforce privilege level restrictions when loading CS | |Privilege level checks were basically missing for the CS case, the |only check that was done (RPL == DPL for nonconforming segments) |was solely covering a single special case (return to non-conforming |segment). | |Additionally in long mode the L bit set requires the D bit to be clear, |as was recently pointed out for KVM by Nadav Amit |. | |Finally we also need to force the loaded selector's RPL to CPL (at |least as long as lret/retf emulation doesn't support privilege level |changes). | |This is XSA-110. | |Signed-off-by: Jan Beulich |Reviewed-by: Tim Deegan | |--- xen/arch/x86/x86_emulate/x86_emulate.c.orig |+++ xen/arch/x86/x86_emulate/x86_emulate.c -------------------------- Patching file xen/arch/x86/x86_emulate/x86_emulate.c using Plan A... Hunk #1 succeeded at 1107. Hunk #2 succeeded at 1179. Hunk #3 succeeded at 1260. Hunk #4 succeeded at 1269. Hunk #5 succeeded at 1866. Hunk #6 succeeded at 2239 (offset 3 lines). Hunk #7 succeeded at 2320 (offset 3 lines). Hunk #8 succeeded at 2543 (offset 3 lines). Hunk #9 succeeded at 2617 (offset 3 lines). Hunk #10 succeeded at 2660 (offset -1 lines). Hunk #11 succeeded at 3294 (offset 3 lines). Hunk #12 succeeded at 3602 (offset -2 lines). Hunk #13 succeeded at 3688 (offset 3 lines). done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2014-8866 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2014-8866 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-CVE-2014-8866,v 1.1 2014/11/27 15:20:31 bouyer Exp $ | |x86: limit checks in hypercall_xlat_continuation() to actual arguments | |HVM/PVH guests can otherwise trigger the final BUG_ON() in that |function by entering 64-bit mode, setting the high halves of affected |registers to non-zero values, leaving 64-bit mode, and issuing a |hypercall that might get preempted and hence become subject to |continuation argument translation (HYPERVISOR_memory_op being the only |one possible for HVM, PVH also having the option of using |HYPERVISOR_mmuext_op). This issue got introduced when HVM code was |switched to use compat_memory_op() - neither that nor |hypercall_xlat_continuation() were originally intended to be used by |other than PV guests (which can't enter 64-bit mode and hence have no |way to alter the high halves of 64-bit registers). | |This is XSA-111. | |Signed-off-by: Jan Beulich |Reviewed-by: Tim Deegan | |--- xen/arch/x86/domain.c.orig |+++ xen/arch/x86/domain.c -------------------------- Patching file xen/arch/x86/domain.c using Plan A... Hunk #1 succeeded at 1921. Hunk #2 succeeded at 1931. Hunk #3 succeeded at 1943. Hunk #4 succeeded at 1971. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/arch/x86/x86_64/compat/mm.c.orig |+++ xen/arch/x86/x86_64/compat/mm.c -------------------------- Patching file xen/arch/x86/x86_64/compat/mm.c using Plan A... Hunk #1 succeeded at 78. Hunk #2 succeeded at 144. Hunk #3 succeeded at 379. Hunk #4 succeeded at 387. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/common/compat/memory.c.orig |+++ xen/common/compat/memory.c -------------------------- Patching file xen/common/compat/memory.c using Plan A... Hunk #1 succeeded at 208. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/include/xen/compat.h.orig |+++ xen/include/xen/compat.h -------------------------- Patching file xen/include/xen/compat.h using Plan A... Hunk #1 succeeded at 192. Hunk #2 succeeded at 213. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2014-8867 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2014-8867 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-CVE-2014-8867,v 1.1 2014/11/27 15:20:31 bouyer Exp $ | |x86/HVM: confine internally handled MMIO to solitary regions | |While it is generally wrong to cross region boundaries when dealing |with MMIO accesses of repeated string instructions (currently only |MOVS) as that would do things a guest doesn't expect (leaving aside |that none of these regions would normally be accessed with repeated |string instructions in the first place), this is even more of a problem |for all virtual MSI-X page accesses (both msixtbl_{read,write}() can be |made dereference NULL "entry" pointers this way) as well as undersized |(1- or 2-byte) LAPIC writes (causing vlapic_read_aligned() to access |space beyond the one memory page set up for holding LAPIC register |values). | |Since those functions validly assume to be called only with addresses |their respective checking functions indicated to be okay, it is generic |code that needs to be fixed to clip the repetition count. | |To be on the safe side (and consistent), also do the same for buffered |I/O intercepts, even if their only client (stdvga) doesn't put the |hypervisor at risk (i.e. "only" guest misbehavior would result). | |This is CVE-2014-8867 / XSA-112. | |Signed-off-by: Jan Beulich |Reviewed-by: Tim Deegan | |--- xen/arch/x86/hvm/intercept.c.orig |+++ xen/arch/x86/hvm/intercept.c -------------------------- Patching file xen/arch/x86/hvm/intercept.c using Plan A... Hunk #1 succeeded at 131. Hunk #2 succeeded at 256. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/arch/x86/hvm/vmsi.c.orig |+++ xen/arch/x86/hvm/vmsi.c -------------------------- Patching file xen/arch/x86/hvm/vmsi.c using Plan A... Hunk #1 succeeded at 236. Hunk #2 succeeded at 280. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2014-9030 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2014-9030 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-CVE-2014-9030,v 1.1 2014/11/27 15:20:31 bouyer Exp $ | |x86/mm: fix a reference counting error in MMU_MACHPHYS_UPDATE | |Any domain which can pass the XSM check against a translated guest can cause a |page reference to be leaked. | |While shuffling the order of checks, drop the quite-pointless MEM_LOG(). This |brings the check in line with similar checks in the vicinity. | |Discovered while reviewing the XSA-109/110 followup series. | |This is XSA-113. | |Signed-off-by: Andrew Cooper |Reviewed-by: Jan Beulich |Reviewed-by: Tim Deegan | |--- xen/arch/x86/mm.c.orig |+++ xen/arch/x86/mm.c -------------------------- Patching file xen/arch/x86/mm.c using Plan A... Hunk #1 succeeded at 3911 (offset 292 lines). Hunk #2 succeeded at 3639 (offset -5 lines). done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-2044 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-2044 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-CVE-2015-2044,v 1.1 2015/03/05 13:44:57 spz Exp $ | |x86/HVM: return all ones on wrong-sized reads of system device I/O ports | |So far the value presented to the guest remained uninitialized. | |This is CVE-2015-2044 / XSA-121. | |Signed-off-by: Jan Beulich |Acked-by: Ian Campbell | |--- xen/arch/x86/hvm/rtc.c.orig 2014-09-02 06:22:57.000000000 +0000 |+++ xen/arch/x86/hvm/rtc.c -------------------------- Patching file xen/arch/x86/hvm/rtc.c using Plan A... Hunk #1 succeeded at 619. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/arch/x86/hvm/i8254.c.orig 2014-09-02 06:22:57.000000000 +0000 |+++ xen/arch/x86/hvm/i8254.c -------------------------- Patching file xen/arch/x86/hvm/i8254.c using Plan A... Hunk #1 succeeded at 478. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/arch/x86/hvm/pmtimer.c.orig 2014-09-02 06:22:57.000000000 +0000 |+++ xen/arch/x86/hvm/pmtimer.c -------------------------- Patching file xen/arch/x86/hvm/pmtimer.c using Plan A... Hunk #1 succeeded at 213. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/arch/x86/hvm/vpic.c.orig 2014-09-02 06:22:57.000000000 +0000 |+++ xen/arch/x86/hvm/vpic.c -------------------------- Patching file xen/arch/x86/hvm/vpic.c using Plan A... Hunk #1 succeeded at 324. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-2045 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-2045 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-CVE-2015-2045,v 1.1 2015/03/05 13:44:57 spz Exp $ | |pre-fill structures for certain HYPERVISOR_xen_version sub-ops | |... avoiding to pass hypervisor stack contents back to the caller |through space unused by the respective strings. | |This is CVE-2015-2045 / XSA-122. | |Signed-off-by: Aaron Adams |Acked-by: Jan Beulich |Acked-by: Ian Campbell | |--- xen/common/kernel.c.orig 2014-09-02 06:22:57.000000000 +0000 |+++ xen/common/kernel.c -------------------------- Patching file xen/common/kernel.c using Plan A... Hunk #1 succeeded at 216. Hunk #2 succeeded at 227. Hunk #3 succeeded at 264. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-2151 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-2151 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-CVE-2015-2151,v 1.1 2015/03/10 19:50:16 spz Exp $ | |xsa123-4.3-4.2.patch from upstream: | |x86emul: fully ignore segment override for register-only operations | |For ModRM encoded instructions with register operands we must not |overwrite ea.mem.seg (if a - bogus in that case - segment override was |present) as it aliases with ea.reg. | |This is CVE-2015-2151 / XSA-123. | |--- xen/arch/x86/x86_emulate/x86_emulate.c.orig 2015-03-10 19:18:09.000000000 +0000 |+++ xen/arch/x86/x86_emulate/x86_emulate.c -------------------------- Patching file xen/arch/x86/x86_emulate/x86_emulate.c using Plan A... Hunk #1 succeeded at 1640. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-2752 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-2752 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-CVE-2015-2752,v 1.1 2015/04/19 13:13:20 spz Exp $ | |Patch for CVE-2015-2752 aka XSA-125 from |http://xenbits.xenproject.org/xsa/xsa125-4.2.patch | |--- tools/libxc/xc_domain.c.orig 2014-09-02 06:22:57.000000000 +0000 |+++ tools/libxc/xc_domain.c -------------------------- Patching file tools/libxc/xc_domain.c using Plan A... Hunk #1 succeeded at 1352. Hunk #2 succeeded at 1368. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- | |--- xen/arch/x86/domctl.c.orig 2014-09-02 06:22:57.000000000 +0000 |+++ xen/arch/x86/domctl.c -------------------------- Patching file xen/arch/x86/domctl.c using Plan A... Hunk #1 succeeded at 865. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- | |--- xen/include/public/domctl.h.orig 2014-09-02 06:22:57.000000000 +0000 |+++ xen/include/public/domctl.h -------------------------- Patching file xen/include/public/domctl.h using Plan A... Hunk #1 succeeded at 507. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-2756 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-2756 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-CVE-2015-2756,v 1.1 2015/04/19 13:13:21 spz Exp $ | |patch for CVE-2015-2756 aka XSA-126 from |http://xenbits.xenproject.org/xsa/xsa126-qemut.patch | |--- tools/qemu-xen-traditional/hw/pass-through.c.orig 2014-01-09 12:44:42.000000000 +0000 |+++ tools/qemu-xen-traditional/hw/pass-through.c -------------------------- Patching file tools/qemu-xen-traditional/hw/pass-through.c using Plan A... Hunk #1 succeeded at 172. Hunk #2 succeeded at 283. Hunk #3 succeeded at 1902. Hunk #4 succeeded at 1922. Hunk #5 succeeded at 3269. Hunk #6 succeeded at 3403. Hunk #7 succeeded at 4184. Hunk #8 succeeded at 4274. Hunk #9 succeeded at 4352. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-3340 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-3340 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-CVE-2015-3340,v 1.1 2015/08/23 16:17:12 spz Exp $ | |patch for CVE-2015-3340 aka XSA-132 from |http://xenbits.xen.org/xsa/xsa132-4.2.patch | |--- xen/arch/x86/domctl.c.orig 2014-09-02 06:22:57.000000000 +0000 |+++ xen/arch/x86/domctl.c -------------------------- Patching file xen/arch/x86/domctl.c using Plan A... Hunk #1 succeeded at 1203 (offset 5 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-CVE-2015-3340,v 1.1 2015/08/23 16:17:12 spz Exp $ | |--- xen/common/sysctl.c.orig 2014-09-02 06:22:57.000000000 +0000 |+++ xen/common/sysctl.c -------------------------- Patching file xen/common/sysctl.c using Plan A... Hunk #1 succeeded at 95. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-3456 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-3456 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-CVE-2015-3456,v 1.1 2015/06/05 18:18:41 khorben Exp $ | |fdc: force the fifo access to be in bounds of the allocated buffer | |During processing of certain commands such as FD_CMD_READ_ID and |FD_CMD_DRIVE_SPECIFICATION_COMMAND the fifo memory access could |get out of bounds leading to memory corruption with values coming |from the guest. | |Fix this by making sure that the index is always bounded by the |allocated memory. | |This is CVE-2015-3456. | |Signed-off-by: Petr Matousek |Reviewed-by: John Snow | |--- tools/qemu-xen/hw/fdc.c.orig |+++ tools/qemu-xen/hw/fdc.c -------------------------- Patching file tools/qemu-xen/hw/fdc.c using Plan A... Hunk #1 succeeded at 1239 (offset -258 lines). Hunk #2 succeeded at 1248 (offset -258 lines). Hunk #3 succeeded at 1594 (offset -258 lines). Hunk #4 succeeded at 1953 (offset -5 lines). Hunk #5 succeeded at 1746 (offset -261 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- tools/qemu-xen-traditional/hw/fdc.c.orig |+++ tools/qemu-xen-traditional/hw/fdc.c -------------------------- Patching file tools/qemu-xen-traditional/hw/fdc.c using Plan A... Hunk #1 succeeded at 1318. Hunk #2 succeeded at 1327. Hunk #3 succeeded at 1673. Hunk #4 succeeded at 1774. Hunk #5 succeeded at 1820. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-4163 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-4163 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-CVE-2015-4163,v 1.1 2015/08/23 16:17:12 spz Exp $ | |patch for CVE-2015-4163 aka XSA-134 from |http://xenbits.xen.org/xsa/xsa134.patch | |--- xen/common/grant_table.c.orig 2014-09-02 06:22:57.000000000 +0000 |+++ xen/common/grant_table.c -------------------------- Patching file xen/common/grant_table.c using Plan A... Hunk #1 succeeded at 2372. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-4164 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-4164 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-CVE-2015-4164,v 1.1 2015/08/23 16:17:12 spz Exp $ | |patch for CVE-2015-4164 aka XSA-136 from |http://xenbits.xen.org/xsa/xsa136.patch | |--- xen/arch/x86/x86_64/compat/traps.c.orig 2014-09-02 06:22:57.000000000 +0000 |+++ xen/arch/x86/x86_64/compat/traps.c -------------------------- Patching file xen/arch/x86/x86_64/compat/traps.c using Plan A... Hunk #1 succeeded at 114. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-5307 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-5307 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-CVE-2015-5307,v 1.1 2016/01/07 17:53:58 bouyer Exp $ | |Patch for CVE-2015-5307 and CVE-2015-8104 aka XSA-156, based on |http://xenbits.xenproject.org/xsa/xsa156-4.3.patch | |--- xen/arch/x86/hvm/svm/svm.c.orig 2014-09-02 08:22:57.000000000 +0200 |+++ xen/arch/x86/hvm/svm/svm.c 2016-01-07 14:30:34.000000000 +0100 -------------------------- Patching file xen/arch/x86/hvm/svm/svm.c using Plan A... Hunk #1 succeeded at 942. Hunk #2 succeeded at 2233. Hunk #3 succeeded at 2283. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/arch/x86/hvm/vmx/vmx.c.orig |+++ xen/arch/x86/hvm/vmx/vmx.c -------------------------- Patching file xen/arch/x86/hvm/vmx/vmx.c using Plan A... Hunk #1 succeeded at 1184 (offset 62 lines). Hunk #2 succeeded at 2446 (offset -164 lines). Hunk #3 succeeded at 2736 (offset 62 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/include/asm-x86/hvm/hvm.h.orig |+++ xen/include/asm-x86/hvm/hvm.h -------------------------- Patching file xen/include/asm-x86/hvm/hvm.h using Plan A... Hunk #1 succeeded at 385 (offset -4 lines). done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-7835 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-7835 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-CVE-2015-7835,v 1.1 2015/10/29 21:59:16 bouyer Exp $ | |Patch for CVE-2015-7835 aka XSA-148 based on |http://xenbits.xenproject.org/xsa/xsa148-4.4.patch | |--- xen/arch/x86/mm.c.orig 2014-09-02 08:22:57.000000000 +0200 |+++ xen/arch/x86/mm.c 2015-10-29 22:27:31.000000000 +0100 -------------------------- Patching file xen/arch/x86/mm.c using Plan A... Hunk #1 succeeded at 169. Hunk #2 succeeded at 1983. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-7969 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-7969 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-CVE-2015-7969,v 1.1 2015/10/29 21:59:16 bouyer Exp $ | |Patch for CVE-2015-7869 aka XSA-149 + XSA-151 based on |http://xenbits.xenproject.org/xsa/xsa149.patch |http://xenbits.xenproject.org/xsa/xsa151.patch | |--- xen/common/domain.c.orig 2014-09-02 08:22:57.000000000 +0200 |+++ xen/common/domain.c 2015-10-29 22:29:21.000000000 +0100 -------------------------- Patching file xen/common/domain.c using Plan A... Hunk #1 succeeded at 685. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/common/xenoprof.c.orig 2014-09-02 08:22:57.000000000 +0200 |+++ xen/common/xenoprof.c 2015-10-29 22:29:35.000000000 +0100 -------------------------- Patching file xen/common/xenoprof.c using Plan A... Hunk #1 succeeded at 239. Hunk #2 succeeded at 287. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-7971 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-7971 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-CVE-2015-7971,v 1.1 2015/10/29 21:59:16 bouyer Exp $ | |Patch for CVE-2015-7971 aka XSA-152, based on |http://xenbits.xenproject.org/xsa/xsa152.patch | |--- xen/common/xenoprof.c.orig |+++ xen/common/xenoprof.c -------------------------- Patching file xen/common/xenoprof.c using Plan A... Hunk #1 succeeded at 673 (offset -3 lines). Hunk #2 succeeded at 902 (offset -3 lines). done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-8339 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-8339 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-CVE-2015-8339,v 1.1 2016/01/07 17:53:58 bouyer Exp $ | |Patch for CVE-2015-8339 and CVE-2015-8340 aka XSA-159, based on |http://xenbits.xenproject.org/xsa/xsa159.patch | |--- xen/common/memory.c.orig |+++ xen/common/memory.c -------------------------- Patching file xen/common/memory.c using Plan A... Hunk #1 succeeded at 286 (offset -48 lines). Hunk #2 succeeded at 558 (offset -14 lines). done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-8555 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-8555 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-CVE-2015-8555,v 1.1 2016/01/07 17:53:58 bouyer Exp $ | |Patch for CVE-2015-8555 aka XSA-165, based on |http://xenbits.xenproject.org/xsa/xsa165-4.3.patch | |--- xen/arch/x86/domain.c.orig |+++ xen/arch/x86/domain.c -------------------------- Patching file xen/arch/x86/domain.c using Plan A... Hunk #1 succeeded at 836 (offset 106 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/arch/x86/i387.c.orig |+++ xen/arch/x86/i387.c -------------------------- Patching file xen/arch/x86/i387.c using Plan A... Hunk #1 succeeded at 17. Hunk #2 succeeded at 245 (offset 4 lines). Hunk #3 succeeded at 307 (offset 4 lines). done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-Config.mk => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-Config.mk Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-Config.mk,v 1.1 2013/06/13 21:49:59 joerg Exp $ | |--- Config.mk.orig 2012-12-18 12:54:16.000000000 +0000 |+++ Config.mk -------------------------- Patching file Config.mk using Plan A... Hunk #1 succeeded at 26 (offset 10 lines). done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-166 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-166 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA-166,v 1.1 2016/01/07 17:53:58 bouyer Exp $ | |Patch for XSA-166, based on |http://xenbits.xenproject.org/xsa/xsa166-4.3.patch | |--- xen/arch/x86/hvm/hvm.c.orig |+++ xen/arch/x86/hvm/hvm.c -------------------------- Patching file xen/arch/x86/hvm/hvm.c using Plan A... Hunk #1 succeeded at 320 (offset -22 lines). Hunk #2 succeeded at 328 (offset -22 lines). Hunk #3 succeeded at 339 (offset -22 lines). done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-182 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-182 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA-182,v 1.1 2016/07/26 15:38:00 bouyer Exp $ | |backported from: | |From 798c1498f764bfaa7b0b955bab40b01b0610d372 Mon Sep 17 00:00:00 2001 |From: Andrew Cooper |Date: Mon, 11 Jul 2016 14:32:03 +0100 |Subject: [PATCH] x86/pv: Remove unsafe bits from the mod_l?_entry() fastpath | |All changes in writeability and cacheability must go through full |re-validation. | |Rework the logic as a whitelist, to make it clearer to follow. | |This is XSA-182 | |--- xen/arch/x86/mm.c.orig 2016-07-26 16:33:46.000000000 +0200 |+++ xen/arch/x86/mm.c 2016-07-26 16:37:14.000000000 +0200 -------------------------- Patching file xen/arch/x86/mm.c using Plan A... Hunk #1 succeeded at 1860. Hunk #2 succeeded at 1908. Hunk #3 succeeded at 1990. Hunk #4 succeeded at 2056. Hunk #5 succeeded at 2126. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- | |--- xen/include/asm-x86/page.h.orig 2014-09-02 08:22:57.000000000 +0200 |+++ xen/include/asm-x86/page.h 2016-07-26 16:39:51.000000000 +0200 -------------------------- Patching file xen/include/asm-x86/page.h using Plan A... Hunk #1 succeeded at 332. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-185 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-185 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA-185,v 1.1 2016/09/08 15:41:01 bouyer Exp $ | |From 30aba4992b18245c436f16df7326a16c01a51570 Mon Sep 17 00:00:00 2001 |From: Jan Beulich |Date: Mon, 8 Aug 2016 10:58:12 +0100 |Subject: x86/32on64: don't allow recursive page tables from L3 | |L3 entries are special in PAE mode, and hence can't reasonably be used |for setting up recursive (and hence linear) page table mappings. Since |abuse is possible when the guest in fact gets run on 4-level page |tables, this needs to be excluded explicitly. | |This is XSA-185. | |Reported-by: Jérémie Boutoille |Reported-by: 栾尚聪(好风) |Signed-off-by: Jan Beulich |Reviewed-by: Andrew Cooper |--- | xen/arch/x86/mm.c | 4 +++- | 1 file changed, 3 insertions(+), 1 deletion(-) | |diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c |index 109b8be..69b8b8d 100644 |--- xen/arch/x86/mm.c.orig |+++ xen/arch/x86/mm.c -------------------------- Patching file xen/arch/x86/mm.c using Plan A... Hunk #1 succeeded at 1048 (offset -74 lines). done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-187-1 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-187-1 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA-187-1,v 1.1 2016/09/08 15:41:01 bouyer Exp $ | |From: Andrew Cooper |Subject: x86/shadow: Avoid overflowing sh_ctxt->seg_reg[] | |hvm_get_seg_reg() does not perform a range check on its input segment, calls |hvm_get_segment_register() and writes straight into sh_ctxt->seg_reg[]. | |x86_seg_none is outside the bounds of sh_ctxt->seg_reg[], and will hit a BUG() |in {vmx,svm}_get_segment_register(). | |HVM guests running with shadow paging can end up performing a virtual to |linear translation with x86_seg_none. This is used for addresses which are |already linear. However, none of this is a legitimate pagetable update, so |fail the emulation in such a case. | |This is XSA-187 | |Reported-by: Andrew Cooper |Signed-off-by: Andrew Cooper |Reviewed-by: Tim Deegan | |--- xen/arch/x86/mm/shadow/common.c.orig |+++ xen/arch/x86/mm/shadow/common.c -------------------------- Patching file xen/arch/x86/mm/shadow/common.c using Plan A... Hunk #1 succeeded at 127 (offset -13 lines). done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-187-2 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-187-2 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA-187-2,v 1.1 2016/09/08 15:41:01 bouyer Exp $ | |From: Andrew Cooper |Subject: x86/segment: Bounds check accesses to emulation ctxt->seg_reg[] | |HVM HAP codepaths have space for all segment registers in the seg_reg[] |cache (with x86_seg_none still risking an array overrun), while the shadow |codepaths only have space for the user segments. | |Range check the input segment of *_get_seg_reg() against the size of the array |used to cache the results, to avoid overruns in the case that the callers |don't filter their input suitably. | |Subsume the is_x86_user_segment(seg) checks from the shadow code, which were |an incomplete attempt at range checking, and are now superceeded. Make |hvm_get_seg_reg() static, as it is not used outside of shadow/common.c | |No functional change, but far easier to reason that no overflow is possible. | |Reported-by: Andrew Cooper |Signed-off-by: Andrew Cooper |Acked-by: Tim Deegan |Acked-by: Jan Beulich | |--- xen/arch/x86/mm/shadow/common.c.orig |+++ xen/arch/x86/mm/shadow/common.c -------------------------- Patching file xen/arch/x86/mm/shadow/common.c using Plan A... Hunk #1 succeeded at 110 (offset -15 lines). Hunk #2 succeeded at 139 (offset -15 lines). Hunk #3 succeeded at 243 (offset -15 lines). Hunk #4 succeeded at 270 (offset -15 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/include/asm-x86/hvm/emulate.h.orig 2014-09-02 08:22:57.000000000 +0200 |+++ xen/include/asm-x86/hvm/emulate.h 2016-09-08 15:57:32.000000000 +0200 -------------------------- Patching file xen/include/asm-x86/hvm/emulate.h using Plan A... Hunk #1 succeeded at 13. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/arch/x86/hvm/emulate.c.orig 2014-09-02 08:22:57.000000000 +0200 |+++ xen/arch/x86/hvm/emulate.c 2016-09-08 16:01:31.000000000 +0200 -------------------------- Patching file xen/arch/x86/hvm/emulate.c using Plan A... Hunk #1 succeeded at 390. Hunk #2 succeeded at 779. Hunk #3 succeeded at 796. Hunk #4 succeeded at 1139. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-191 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-191 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA-191,v 1.1 2016/11/22 20:55:29 bouyer Exp $ | |backported from: | |From: Andrew Cooper |Subject: x86/hvm: Fix the handling of non-present segments | |In 32bit, the data segments may be NULL to indicate that the segment is |ineligible for use. In both 32bit and 64bit, the LDT selector may be NULL to |indicate that the entire LDT is ineligible for use. However, nothing in Xen |actually checks for this condition when performing other segmentation |checks. (Note however that limit and writeability checks are correctly |performed). | |Neither Intel nor AMD specify the exact behaviour of loading a NULL segment. |Experimentally, AMD zeroes all attributes but leaves the base and limit |unmodified. Intel zeroes the base, sets the limit to 0xfffffff and resets the |attributes to just .G and .D/B. | |The use of the segment information in the VMCB/VMCS is equivalent to a native |pipeline interacting with the segment cache. The present bit can therefore |have a subtly different meaning, and it is now cooked to uniformly indicate |whether the segment is usable or not. | |GDTR and IDTR don't have access rights like the other segments, but for |consistency, they are treated as being present so no special casing is needed |elsewhere in the segmentation logic. | |AMD hardware does not consider the present bit for %cs and %tr, and will |function as if they were present. They are therefore unconditionally set to |present when reading information from the VMCB, to maintain the new meaning of |usability. | |Intel hardware has a separate unusable bit in the VMCS segment attributes. |This bit is inverted and stored in the present field, so the hvm code can work |with architecturally-common state. | |This is XSA-191. | |Signed-off-by: Andrew Cooper |Reviewed-by: Jan Beulich | |--- xen/arch/x86/hvm/hvm.c.orig 2016-11-22 15:03:34.000000000 +0100 |+++ xen/arch/x86/hvm/hvm.c 2016-11-22 15:15:51.000000000 +0100 -------------------------- Patching file xen/arch/x86/hvm/hvm.c using Plan A... Hunk #1 succeeded at 1921. Hunk #2 succeeded at 2109. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/arch/x86/hvm/svm/svm.c.orig 2016-11-22 15:03:33.000000000 +0100 |+++ xen/arch/x86/hvm/svm/svm.c 2016-11-22 15:15:51.000000000 +0100 -------------------------- Patching file xen/arch/x86/hvm/svm/svm.c using Plan A... Hunk #1 succeeded at 517. Hunk #2 succeeded at 551. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/arch/x86/hvm/vmx/vmx.c.orig 2016-11-22 15:03:33.000000000 +0100 |+++ xen/arch/x86/hvm/vmx/vmx.c 2016-11-22 15:15:51.000000000 +0100 -------------------------- Patching file xen/arch/x86/hvm/vmx/vmx.c using Plan A... Hunk #1 succeeded at 809. Hunk #2 succeeded at 894. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/arch/x86/x86_emulate/x86_emulate.c.orig 2016-11-22 15:03:34.000000000 +0100 |+++ xen/arch/x86/x86_emulate/x86_emulate.c 2016-11-22 15:15:51.000000000 +0100 -------------------------- Patching file xen/arch/x86/x86_emulate/x86_emulate.c using Plan A... Hunk #1 succeeded at 1136. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-192 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-192 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA-192,v 1.1 2016/11/22 20:55:29 bouyer Exp $ | |From: Jan Beulich |Subject: x86/HVM: don't load LDTR with VM86 mode attrs during task switch | |Just like TR, LDTR is purely a protected mode facility and hence needs |to be loaded accordingly. Also move its loading to where it |architecurally belongs. | |This is XSA-192. | |Signed-off-by: Jan Beulich |Reviewed-by: Andrew Cooper |Tested-by: Andrew Cooper | |--- xen/arch/x86/hvm/hvm.c.orig 2016-11-22 15:15:51.000000000 +0100 |+++ xen/arch/x86/hvm/hvm.c 2016-11-22 15:29:02.000000000 +0100 -------------------------- Patching file xen/arch/x86/hvm/hvm.c using Plan A... Hunk #1 succeeded at 2072. Hunk #2 succeeded at 2331. Hunk #3 succeeded at 2355. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-195 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-195 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA-195,v 1.1 2016/11/22 20:55:29 bouyer Exp $ | |backported from: | |From: Jan Beulich |Subject: x86emul: fix huge bit offset handling | |We must never chop off the high 32 bits. | |This is XSA-195. | |Reported-by: George Dunlap |Signed-off-by: Jan Beulich |Reviewed-by: Andrew Cooper | |--- xen/arch/x86/x86_emulate/x86_emulate.c.orig 2016-11-22 15:15:51.000000000 +0100 |+++ xen/arch/x86/x86_emulate/x86_emulate.c 2016-11-22 16:02:09.000000000 +0100 -------------------------- Patching file xen/arch/x86/x86_emulate/x86_emulate.c using Plan A... Hunk #1 succeeded at 1756. Hunk #2 succeeded at 1773. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-200 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-200 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA-200,v 1.1 2016/12/20 10:22:28 bouyer Exp $ | |From: Jan Beulich |Subject: x86emul: CMPXCHG8B ignores operand size prefix | |Otherwise besides mis-handling the instruction, the comparison failure |case would result in uninitialized stack data being handed back to the |guest in rDX:rAX (32 bits leaked for 32-bit guests, 96 bits for 64-bit |ones). | |This is XSA-200. | |Signed-off-by: Jan Beulich | |--- tools/tests/x86_emulator/test_x86_emulator.c.orig |+++ tools/tests/x86_emulator/test_x86_emulator.c -------------------------- Patching file tools/tests/x86_emulator/test_x86_emulator.c using Plan A... Hunk #1 succeeded at 396 (offset -33 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/arch/x86/x86_emulate/x86_emulate.c.orig |+++ xen/arch/x86/x86_emulate/x86_emulate.c -------------------------- Patching file xen/arch/x86/x86_emulate/x86_emulate.c using Plan A... Hunk #1 succeeded at 4498. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-202 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-202 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA-202,v 1.1 2016/12/21 15:35:44 bouyer Exp $ | |From: Jan Beulich |Subject: x86: force EFLAGS.IF on when exiting to PV guests | |Guest kernels modifying instructions in the process of being emulated |for another of their vCPU-s may effect EFLAGS.IF to be cleared upon |next exiting to guest context, by converting the being emulated |instruction to CLI (at the right point in time). Prevent any such bad |effects by always forcing EFLAGS.IF on. And to cover hypothetical other |similar issues, also force EFLAGS.{IOPL,NT,VM} to zero. | |This is XSA-202. | |Signed-off-by: Jan Beulich | | |--- xen/arch/x86/x86_64/entry.S.orig |+++ xen/arch/x86/x86_64/entry.S -------------------------- Patching file xen/arch/x86/x86_64/entry.S using Plan A... Hunk #1 succeeded at 41. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/arch/x86/x86_64/compat/entry.S.orig 2014-09-02 08:22:57.000000000 +0200 |+++ xen/arch/x86/x86_64/compat/entry.S 2016-12-21 13:23:21.000000000 +0100 -------------------------- Patching file xen/arch/x86/x86_64/compat/entry.S using Plan A... Hunk #1 succeeded at 173. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-204 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-204 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA-204,v 1.1 2016/12/20 10:22:28 bouyer Exp $ | |From: Andrew Cooper |Date: Sun, 18 Dec 2016 15:42:59 +0000 |Subject: [PATCH] x86/emul: Correct the handling of eflags with SYSCALL | |A singlestep #DB is determined by the resulting eflags value from the |execution of SYSCALL, not the original eflags value. | |By using the original eflags value, we negate the guest kernels attempt to |protect itself from a privilege escalation by masking TF. | |Introduce a tf boolean and have the SYSCALL emulation recalculate it |after the instruction is complete. | |This is XSA-204 | |Signed-off-by: Andrew Cooper |Reviewed-by: Jan Beulich |--- | xen/arch/x86/x86_emulate/x86_emulate.c | 23 ++++++++++++++++++++--- | 1 file changed, 20 insertions(+), 3 deletions(-) | |diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c |index 0c43fe1..f675dc9 100644 |--- xen/arch/x86/x86_emulate/x86_emulate.c.orig 2016-12-19 23:22:20.000000000 +0100 |+++ xen/arch/x86/x86_emulate/x86_emulate.c 2016-12-19 23:22:38.000000000 +0100 -------------------------- Patching file xen/arch/x86/x86_emulate/x86_emulate.c using Plan A... Hunk #1 succeeded at 1348. Hunk #2 succeeded at 3678 (offset -2 lines). Hunk #3 succeeded at 3864 (offset -2 lines). done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_Makefile => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_Makefile Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_Makefile,v 1.1 2013/06/13 21:49:59 joerg Exp $ | |--- xen/Makefile.orig 2013-04-23 16:42:55.000000000 +0000 |+++ xen/Makefile -------------------------- Patching file xen/Makefile using Plan A... Hunk #1 succeeded at 118. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_arch_x86_Rules.mk => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_arch_x86_Rules.mk Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_arch_x86_Rules.mk,v 1.1 2013/06/13 21:49:59 joerg Exp $ | |--- xen/arch/x86/Rules.mk.orig 2013-03-25 13:28:19.000000000 +0000 |+++ xen/arch/x86/Rules.mk -------------------------- Patching file xen/arch/x86/Rules.mk using Plan A... Hunk #1 succeeded at 28 (offset 7 lines). done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_arch_x86_hvm_hvm.c => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_arch_x86_hvm_hvm.c Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_arch_x86_hvm_hvm.c,v 1.1 2014/10/01 17:34:54 bouyer Exp $ | |x86/HVM: properly bound x2APIC MSR range | |While the write path change appears to be purely cosmetic (but still |gets done here for consistency), the read side mistake permitted |accesses beyond the virtual APIC page. | |Note that while this isn't fully in line with the specification |(digesting MSRs 0x800-0xBFF for the x2APIC), this is the minimal |possible fix addressing the security issue and getting x2APIC related |code into a consistent shape (elsewhere a 256 rather than 1024 wide |window is being used too). This will be dealt with subsequently. | |This is XSA-108. | |Signed-off-by: Jan Beulich | |--- xen/arch/x86/hvm/hvm.c.orig |+++ xen/arch/x86/hvm/hvm.c -------------------------- Patching file xen/arch/x86/hvm/hvm.c using Plan A... Hunk #1 succeeded at 2887 (offset -1493 lines). Hunk #2 succeeded at 4500 (offset -6 lines). done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_arch_x86_mm_shadow_common.c => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_arch_x86_mm_shadow_common.c Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_arch_x86_mm_shadow_common.c,v 1.1 2014/09/26 10:39:31 bouyer Exp $ | |patch for XSA-104/CVE-2014-7154, from Xen Security Advisory | |--- xen/arch/x86/mm/shadow/common.c.orig 2014-09-02 08:22:57.000000000 +0200 |+++ xen/arch/x86/mm/shadow/common.c 2014-09-26 11:18:02.000000000 +0200 -------------------------- Patching file xen/arch/x86/mm/shadow/common.c using Plan A... Hunk #1 succeeded at 3608 (offset 7 lines). Hunk #2 succeeded at 3618 (offset 7 lines). done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_arch_x86_x86_emulate_x86_emulate.c => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_arch_x86_x86_emulate_x86_emulate.c Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_arch_x86_x86_emulate_x86_emulate.c,v 1.1 2014/09/26 10:39:31 bouyer Exp $ | |patch for XSA-105/CVE-2014-7155 and XSA-106/CVE-2014-7156, |from Xen Security Advisory | |--- xen/arch/x86/x86_emulate/x86_emulate.c.orig 2014-09-26 11:53:50.000000000 +0200 |+++ xen/arch/x86/x86_emulate/x86_emulate.c 2014-09-26 11:53:43.000000000 +0200 -------------------------- Patching file xen/arch/x86/x86_emulate/x86_emulate.c using Plan A... Hunk #1 succeeded at 2642 (offset 26 lines). Hunk #2 succeeded at 3323 (offset 26 lines). Hunk #3 succeeded at 3722 (offset -1 lines). Hunk #4 succeeded at 3778 (offset 26 lines). done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_common_spinlock.c => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_common_spinlock.c Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_common_spinlock.c,v 1.1 2014/12/30 08:15:01 spz Exp $ | |from XSA-114: |switch to write-biased r/w locks | |This is to improve fairness: A permanent flow of read acquires can |otherwise lock out eventual writers indefinitely. | |This is XSA-114 / CVE-2014-9065. | |--- xen/common/spinlock.c.orig 2014-09-02 06:22:57.000000000 +0000 |+++ xen/common/spinlock.c -------------------------- Patching file xen/common/spinlock.c using Plan A... Hunk #1 succeeded at 271. Hunk #2 succeeded at 423. Hunk #3 succeeded at 437. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_common_symbols.c => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_common_symbols.c Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_common_symbols.c,v 1.1 2016/09/12 13:22:39 maya Exp $ | |upstream build fix for GCC5 |https://lists.xenproject.org/archives/html/xen-devel/2015-03/msg01687.html | |--- xen/common/symbols.c.orig 2014-09-02 06:22:57.000000000 +0000 |+++ xen/common/symbols.c -------------------------- Patching file xen/common/symbols.c using Plan A... Hunk #1 succeeded at 19. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_drivers_passthrough_vtd_x86_ats.c => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_drivers_passthrough_vtd_x86_ats.c Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_drivers_passthrough_vtd_x86_ats.c,v 1.1 2015/09/14 13:36:29 joerg Exp $ | |--- xen/drivers/passthrough/vtd/x86/ats.c.orig 2014-09-02 06:22:57.000000000 +0000 |+++ xen/drivers/passthrough/vtd/x86/ats.c -------------------------- Patching file xen/drivers/passthrough/vtd/x86/ats.c using Plan A... Hunk #1 succeeded at 134. Hunk #2 succeeded at 146. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_include_asm-arm_spinlock.h => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_include_asm-arm_spinlock.h Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_include_asm-arm_spinlock.h,v 1.1 2014/12/30 08:15:01 spz Exp $ | |from XSA-114: |switch to write-biased r/w locks | |This is to improve fairness: A permanent flow of read acquires can |otherwise lock out eventual writers indefinitely. | |This is XSA-114 / CVE-2014-9065. | |--- xen/include/asm-arm/spinlock.h.orig 2014-09-02 06:22:57.000000000 +0000 |+++ xen/include/asm-arm/spinlock.h -------------------------- Patching file xen/include/asm-arm/spinlock.h using Plan A... Hunk #1 succeeded at 55. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_include_asm-x86_atomic.h => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_include_asm-x86_atomic.h Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_include_asm-x86_atomic.h,v 1.1 2015/03/18 15:05:51 joerg Exp $ | |read_atomic() is used in the condition part of while() loops, so don't |use break here. | |--- xen/include/asm-x86/atomic.h.orig 2015-03-17 23:41:49.000000000 +0000 |+++ xen/include/asm-x86/atomic.h -------------------------- Patching file xen/include/asm-x86/atomic.h using Plan A... Hunk #1 succeeded at 46. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_include_asm-x86_spinlock.h => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_include_asm-x86_spinlock.h Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_include_asm-x86_spinlock.h,v 1.1 2014/12/30 08:15:01 spz Exp $ | |from XSA-114: |switch to write-biased r/w locks | |This is to improve fairness: A permanent flow of read acquires can |otherwise lock out eventual writers indefinitely. | |This is XSA-114 / CVE-2014-9065. | |--- xen/include/asm-x86/spinlock.h.orig 2014-09-02 06:22:57.000000000 +0000 |+++ xen/include/asm-x86/spinlock.h -------------------------- Patching file xen/include/asm-x86/spinlock.h using Plan A... Hunk #1 succeeded at 31. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_include_xen_lib.h => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_include_xen_lib.h Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_include_xen_lib.h,v 1.1 2013/06/13 21:49:59 joerg Exp $ | |--- xen/include/xen/lib.h.orig 2013-06-13 19:59:04.000000000 +0000 |+++ xen/include/xen/lib.h -------------------------- Patching file xen/include/xen/lib.h using Plan A... Hunk #1 succeeded at 42. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_include_xen_spinlock.h => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel42/patches/patch-xen_include_xen_spinlock.h Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_include_xen_spinlock.h,v 1.1 2014/12/30 08:15:01 spz Exp $ | |from XSA-114: |switch to write-biased r/w locks | |This is to improve fairness: A permanent flow of read acquires can |otherwise lock out eventual writers indefinitely. | |This is XSA-114 / CVE-2014-9065. | |--- xen/include/xen/spinlock.h.orig 2014-09-02 06:22:57.000000000 +0000 |+++ xen/include/xen/spinlock.h -------------------------- Patching file xen/include/xen/spinlock.h using Plan A... Hunk #1 succeeded at 141. done ===> Creating toolchain wrappers for xenkernel42-4.2.5nb16