=> Bootstrap dependency digest>=20010302: found digest-20160304 ===> 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.6.3.tar.gz => Checksum RMD160 OK for xen-4.6.3.tar.gz => Checksum SHA512 OK for xen-4.6.3.tar.gz ===> Installing dependencies for xenkernel46-4.6.3nb4 ========================================================================== The following variables will affect the build process of this package, xenkernel46-4.6.3nb4. Their current value is shown below: * PYTHON_VERSION_DEFAULT = 27 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.1nb3 => Tool dependency checkperms>=1.1: found checkperms-1.11nb1 => Build dependency python27>=2.7.1nb2: found python27-2.7.13 => Build dependency cwrappers>=20150314: found cwrappers-20161125 ===> Overriding tools for xenkernel46-4.6.3nb4 ===> Extracting for xenkernel46-4.6.3nb4 ===> Patching for xenkernel46-4.6.3nb4 => Applying pkgsrc patches for xenkernel46-4.6.3nb4 => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-Config.mk => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/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.1.1 2016/07/04 07:25:13 jnemeth Exp $ | |--- Config.mk.orig 2015-01-12 17:53:24.000000000 +0100 |+++ Config.mk 2015-01-19 12:29:14.000000000 +0100 -------------------------- Patching file Config.mk using Plan A... Hunk #1 succeeded at 39. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA-185 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/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:44:07 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 1051 (offset -71 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA-186-1 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA-186-1 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA-186-1,v 1.1 2016/09/08 15:44:07 bouyer Exp $ | |From: Andrew Cooper |Subject: hvm/fep: Allow testing of instructions crossing the -1 -> 0 virtual boundary | |The Force Emulation Prefix is named to follow its PV counterpart for cpuid or |rdtsc, but isn't really an instruction prefix. It behaves as a break-out into |Xen, with the purpose of emulating the next instruction in the current state. | |It is important to be able to test legal situations which occur in real |hardware, including instruction which cross certain boundaries, and |instructions starting at 0. | |Reported-by: Brian Marcotte |Signed-off-by: Andrew Cooper |Reviewed-by: Jan Beulich | |--- xen/arch/x86/hvm/svm/svm.c.orig |+++ xen/arch/x86/hvm/svm/svm.c -------------------------- Patching file xen/arch/x86/hvm/svm/svm.c using Plan A... Hunk #1 succeeded at 2139. 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 2757. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA-186-2 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA-186-2 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |From e938be013ba73ff08fa4f1d8670501aacefde7fb Mon Sep 17 00:00:00 2001 |From: Andrew Cooper |Date: Fri, 22 Jul 2016 16:02:54 +0000 |Subject: [PATCH 1/2] x86/emulate: Correct boundary interactions of emulated | instructions | |This reverts most of c/s 0640ffb6 "x86emul: fix rIP handling". | |Experimentally, in long mode processors will execute an instruction stream |which crosses the 64bit -1 -> 0 virtual boundary, whether the instruction |boundary is aligned on the virtual boundary, or is misaligned. | |In compatibility mode, Intel processors will execute an instruction stream |which crosses the 32bit -1 -> 0 virtual boundary, while AMD processors raise a |segmentation fault. Xen's segmentation behaviour matches AMD. | |For 16bit code, hardware does not ever truncated %ip. %eip is always used and |behaves normally as a 32bit register, including in 16bit protected mode |segments, as well as in Real and Unreal mode. | |This is XSA-186 | |Reported-by: Brian Marcotte |Signed-off-by: Andrew Cooper |Reviewed-by: Jan Beulich |--- | xen/arch/x86/x86_emulate/x86_emulate.c | 22 ++++------------------ | 1 file changed, 4 insertions(+), 18 deletions(-) | |diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c |index d5a56cf..bf3529a 100644 |--- 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 1515 (offset -55 lines). Hunk #2 succeeded at 3896 (offset -6 lines). Hmm... Ignoring the trailing garbage. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA-187-1 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/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:44:07 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 142 (offset 2 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA-187-2 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/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:44:07 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/hvm/emulate.c.orig |+++ xen/arch/x86/hvm/emulate.c -------------------------- Patching file xen/arch/x86/hvm/emulate.c using Plan A... Hunk #1 succeeded at 526. Hunk #2 succeeded at 1362. Hunk #3 succeeded at 1379. Hunk #4 succeeded at 1920. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- 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 125. Hunk #2 succeeded at 154. Hunk #3 succeeded at 258. Hunk #4 succeeded at 285. 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 |+++ xen/include/asm-x86/hvm/emulate.h -------------------------- Patching file xen/include/asm-x86/hvm/emulate.h using Plan A... Hunk #1 succeeded at 13. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA-191 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/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:59:01 bouyer Exp $ | |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 |+++ xen/arch/x86/hvm/hvm.c -------------------------- Patching file xen/arch/x86/hvm/hvm.c using Plan A... Hunk #1 succeeded at 3642 (offset -24 lines). Hunk #2 succeeded at 3851 (offset -24 lines). 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 |+++ xen/arch/x86/hvm/svm/svm.c -------------------------- Patching file xen/arch/x86/hvm/svm/svm.c using Plan A... Hunk #1 succeeded at 620. Hunk #2 succeeded at 654. 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 865 (offset -2 lines). Hunk #2 succeeded at 950 (offset -2 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 1157 (offset -52 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA-192 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/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:59:01 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 |+++ xen/arch/x86/hvm/hvm.c -------------------------- Patching file xen/arch/x86/hvm/hvm.c using Plan A... Hunk #1 succeeded at 3813 (offset 1085 lines). Hunk #2 succeeded at 2987 (offset 2 lines). Hunk #3 succeeded at 4094 (offset 1085 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA-193 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA-193 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA-193,v 1.1 2016/11/22 20:59:01 bouyer Exp $ | |From: Jan Beulich |Subject: x86/PV: writes of %fs and %gs base MSRs require canonical addresses | |Commit c42494acb2 ("x86: fix FS/GS base handling when using the |fsgsbase feature") replaced the use of wrmsr_safe() on these paths |without recognizing that wr{f,g}sbase() use just wrmsrl() and that the |WR{F,G}SBASE instructions also raise #GP for non-canonical input. | |Similarly arch_set_info_guest() needs to prevent non-canonical |addresses from getting stored into state later to be loaded by context |switch code. For consistency also check stack pointers and LDT base. |DR0..3, otoh, already get properly checked in set_debugreg() (albeit |we discard the error there). | |The SHADOW_GS_BASE check isn't strictly necessary, but I think we |better avoid trying the WRMSR if we know it's going to fail. | |This is XSA-193. | |Reported-by: Andrew Cooper |Signed-off-by: Jan Beulich |Reviewed-by: Andrew Cooper | |--- 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 796 (offset -94 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/arch/x86/traps.c.orig |+++ xen/arch/x86/traps.c -------------------------- Patching file xen/arch/x86/traps.c using Plan A... Hunk #1 succeeded at 2515 (offset -208 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA-195 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/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:59:01 bouyer Exp $ | |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 |+++ 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 1941 (offset -608 lines). Hunk #2 succeeded at 1958 (offset -608 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA-196-1 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA-196-1 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA-196-1,v 1.1 2016/11/22 20:59:01 bouyer Exp $ | |From: Andrew Cooper |Subject: x86/emul: Correct the IDT entry calculation in inject_swint() | |The logic, as introduced in c/s 36ebf14ebe "x86/emulate: support for emulating |software event injection" is buggy. The size of an IDT entry depends on long |mode being active, not the width of the code segment currently in use. | |In particular, this means that a compatibility code segment which hits |emulation for software event injection will end up using an incorrect offset |in the IDT for DPL/Presence checking. In practice, this only occurs on old |AMD hardware lacking NRip support; all newer AMD hardware, and all Intel |hardware bypass this path in the emulator. | |While here, fix a minor issue with reading the IDT entry. The return value |from ops->read() wasn't checked, but in reality the only failure case is if a |pagefault occurs. This is not a realistic problem as the kernel will almost |certainly crash with a double fault if this setup actually occured. | |This is part of XSA-196. | |Signed-off-by: Andrew Cooper |Reviewed-by: Jan Beulich |--- | xen/arch/x86/x86_emulate/x86_emulate.c | 15 +++++++++++---- | 1 file changed, 11 insertions(+), 4 deletions(-) | |diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c |index 7a707dc..f74aa8f 100644 |--- 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 1406 (offset -224 lines). Hunk #2 succeeded at 1443 (offset -224 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA-196-2 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA-196-2 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA-196-2,v 1.1 2016/11/22 20:59:01 bouyer Exp $ | |From: Andrew Cooper |Subject: x86/svm: Fix injection of software interrupts | |The non-NextRip logic in c/s 36ebf14eb "x86/emulate: support for emulating |software event injection" was based on an older version of the AMD software |manual. The manual was later corrected, following findings from that series. | |I took the original wording of "not supported without NextRIP" to mean that |X86_EVENTTYPE_SW_INTERRUPT was not eligible for use. It turns out that this |is not the case, and the new wording is clearer on the matter. | |Despite testing the original patch series on non-NRip hardware, the |swint-emulation XTF test case focuses on the debug vectors; it never ended up |executing an `int $n` instruction for a vector which wasn't also an exception. | |During a vmentry, the use of X86_EVENTTYPE_HW_EXCEPTION comes with a vector |check to ensure that it is only used with exception vectors. Xen's use of |X86_EVENTTYPE_HW_EXCEPTION for `int $n` injection has always been buggy on AMD |hardware. | |Fix this by always using X86_EVENTTYPE_SW_INTERRUPT. | |Print and decode the eventinj information in svm_vmcb_dump(), as it has |several invalid combinations which cause vmentry failures. | |This is part of XSA-196. | |Signed-off-by: Andrew Cooper |Reviewed-by: Jan Beulich |--- | xen/arch/x86/hvm/svm/svm.c | 13 +++++-------- | xen/arch/x86/hvm/svm/svmdebug.c | 4 ++++ | 2 files changed, 9 insertions(+), 8 deletions(-) | |diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c |index 4391744..76efc3e 100644 |--- xen/arch/x86/hvm/svm/svm.c.orig |+++ xen/arch/x86/hvm/svm/svm.c -------------------------- Patching file xen/arch/x86/hvm/svm/svm.c using Plan A... Hunk #1 succeeded at 1229 (offset -2 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/xen/arch/x86/hvm/svm/svmdebug.c b/xen/arch/x86/hvm/svm/svmdebug.c |index ded5d19..f93dfed 100644 |--- xen/arch/x86/hvm/svm/svmdebug.c.orig |+++ xen/arch/x86/hvm/svm/svmdebug.c -------------------------- Patching file xen/arch/x86/hvm/svm/svmdebug.c using Plan A... Hunk #1 succeeded at 48. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA-200 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/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:29 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 412 (offset -17 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 4679 (offset -60 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA-202 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/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:36:39 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/compat/entry.S.orig |+++ xen/arch/x86/x86_64/compat/entry.S -------------------------- Patching file xen/arch/x86/x86_64/compat/entry.S using Plan A... Hunk #1 succeeded at 174. Hunk #2 succeeded at 211. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- 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 40. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA-203 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA-203 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA-203,v 1.1 2016/12/21 15:36:39 bouyer Exp $ | |From: Jan Beulich |Subject: x86/HVM: add missing NULL check before using VMFUNC hook | |This is XSA-203. | |Signed-off-by: Jan Beulich |Reviewed-by: Andrew Cooper | |--- xen/arch/x86/hvm/emulate.c.orig |+++ xen/arch/x86/hvm/emulate.c -------------------------- Patching file xen/arch/x86/hvm/emulate.c using Plan A... Hunk #1 succeeded at 1620 (offset -23 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA-204 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/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:29 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 bca7045..abe442e 100644 |--- 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 1502 (offset -80 lines). Hunk #2 succeeded at 3933 (offset 22 lines). Hunk #3 succeeded at 4025 (offset -118 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_Makefile => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/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.1.1 2016/07/04 07:25:13 jnemeth Exp $ | |--- xen/Makefile.orig 2016-02-09 14:44:19.000000000 +0000 |+++ xen/Makefile -------------------------- Patching file xen/Makefile using Plan A... Hunk #1 succeeded at 135. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_arch_x86_Rules.mk => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/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.1.1 2016/07/04 07:25:14 jnemeth Exp $ | |--- xen/arch/x86/Rules.mk.orig 2015-01-12 17:53:24.000000000 +0100 |+++ xen/arch/x86/Rules.mk 2015-01-19 12:29:14.000000000 +0100 -------------------------- Patching file xen/arch/x86/Rules.mk using Plan A... Hunk #1 succeeded at 18 (offset -6 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_common_page__alloc.c => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_common_page__alloc.c Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_common_page__alloc.c,v 1.1.1.1 2016/07/04 07:25:13 jnemeth Exp $ | |--- xen/common/page_alloc.c.orig 2015-09-13 17:37:09.000000000 +0000 |+++ xen/common/page_alloc.c -------------------------- Patching file xen/common/page_alloc.c using Plan A... Hunk #1 succeeded at 1575 (offset 14 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_drivers_passthrough_vtd_x86_ats.c => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/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.1.1 2016/07/04 07:25:14 jnemeth Exp $ | |--- xen/drivers/passthrough/vtd/x86/ats.c.orig 2015-06-22 13:41:35.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 133 (offset -1 lines). Hunk #2 succeeded at 145 (offset -1 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_include_asm-x86_current.h => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_include_asm-x86_current.h Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_include_asm-x86_current.h,v 1.1.1.1 2016/07/04 07:25:13 jnemeth Exp $ | |--- xen/include/asm-x86/current.h.orig 2015-01-30 12:45:05.000000000 +0000 |+++ xen/include/asm-x86/current.h -------------------------- Patching file xen/include/asm-x86/current.h using Plan A... Hunk #1 succeeded at 47 (offset 22 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_include_xen_lib.h => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/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.1.1 2016/07/04 07:25:13 jnemeth Exp $ | |--- xen/include/xen/lib.h.orig 2015-06-22 15:41:35.000000000 +0200 |+++ xen/include/xen/lib.h 2015-06-23 18:32:26.000000000 +0200 -------------------------- Patching file xen/include/xen/lib.h using Plan A... Hunk #1 succeeded at 32 (offset -12 lines). done ===> Creating toolchain wrappers for xenkernel46-4.6.3nb4