=> 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 xen411/xen-4.11.3.tar.gz => Checksum RMD160 OK for xen411/xen-4.11.3.tar.gz => Checksum SHA512 OK for xen411/xen-4.11.3.tar.gz ===> Installing dependencies for xenkernel411-4.11.3nb1 ========================================================================== The following variables will affect the build process of this package, xenkernel411-4.11.3nb1. 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.17nb2 => Build dependency cwrappers>=20150314: found cwrappers-20180325 ===> Overriding tools for xenkernel411-4.11.3nb1 ===> Extracting for xenkernel411-4.11.3nb1 ===> Patching for xenkernel411-4.11.3nb1 => Applying pkgsrc patches for xenkernel411-4.11.3nb1 => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-Config.mk => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/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 2018/07/24 13:40:11 bouyer Exp $ | |--- Config.mk.orig 2018-04-17 19:21:31.000000000 +0200 |+++ Config.mk 2018-04-23 13:29:47.000000000 +0200 -------------------------- Patching file Config.mk using Plan A... Hunk #1 succeeded at 32. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA307 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA307 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA307,v 1.1 2019/12/13 13:44:21 bouyer Exp $ | |From: Jan Beulich |Subject: x86+Arm32: make find_next_{,zero_}bit() have well defined behavior | |These functions getting used with the 2nd and 3rd arguments being equal |wasn't well defined: Arm64 reliably returns the value of the 2nd |argument in this case, while on x86 for bitmaps up to 64 bits wide the |return value was undefined (due to the undefined behavior of a shift of |a value by the number of bits it's wide) when the incoming value was 64. |On Arm32 an actual out of bounds access would happen when the |size/offset value is a multiple of 32; if this access doesn't fault, the |return value would have been sufficiently correct afaict. | |Make the functions consistently tolerate the last two arguments being |equal (and in fact the 3rd argument being greater or equal to the 2nd), |in favor of finding and fixing all the use sites that violate the |original more strict assumption. | |This is XSA-307. | |Signed-off-by: Jan Beulich |Acked-by: Julien Grall |--- |The most obvious (albeit still indirect) exposure to guests is |evtchn_check_pollers(), which imo makes this a security issue at least |for Arm32. | |This was originally already discussed between (at least) Andrew and me, |and I don't really recall who brought up the issue first. | |Note that Arm's Linux origin of the code may call for syncing |publication with them. Then again I don't want to tell them just to see |them go public ahead of us. | |--- xen/arch/arm/arm32/lib/findbit.S.orig |+++ xen/arch/arm/arm32/lib/findbit.S -------------------------- Patching file xen/arch/arm/arm32/lib/findbit.S using Plan A... Hunk #1 succeeded at 42. Hunk #2 succeeded at 83. Hunk #3 succeeded at 117. Hunk #4 succeeded at 151. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/include/asm-x86/bitops.h.orig |+++ xen/include/asm-x86/bitops.h -------------------------- Patching file xen/include/asm-x86/bitops.h using Plan A... Hunk #1 succeeded at 358. Hunk #2 succeeded at 390. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA308 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA308 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA308,v 1.1 2019/12/13 13:44:21 bouyer Exp $ | |From: Andrew Cooper |Subject: x86/vtx: Work around SingleStep + STI/MovSS VMEntry failures | |See patch comment for technical details. | |Concerning the timeline, this was first discovered in the aftermath of |XSA-156 which caused #DB to be intercepted unconditionally, but only in |its SingleStep + STI form which is restricted to privileged software. | |After working with Intel and identifying the problematic vmentry check, |this workaround was suggested, and the patch was posted in an RFC |series. Outstanding work for that series (not breaking Introspection) |is still pending, and this fix from it (which wouldn't have been good |enough in its original form) wasn't committed. | |A vmentry failure was reported to xen-devel, and debugging identified |this bug in its SingleStep + MovSS form by way of INT1, which does not |involve the use of any privileged instructions, and proving this to be a |security issue. | |This is XSA-308 | |Reported-by: Håkon Alstadheim |Signed-off-by: Andrew Cooper |Reviewed-by: Jan Beulich |Acked-by: Kevin Tian | |diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c |index 6a5eeb5c13..59b836f43f 100644 |--- 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 3907 (offset 91 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA309 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA309 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA309,v 1.1 2019/12/13 13:44:21 bouyer Exp $ | |From 523e3974ed2213719a19218f5b246e382ceef18a Mon Sep 17 00:00:00 2001 |From: George Dunlap |Date: Wed, 30 Oct 2019 17:05:28 +0000 |Subject: [PATCH] x86/mm: Don't reset linear_pt_count on partial validation | |"Linear pagetables" is a technique which involves either pointing a |pagetable at itself, or to another pagetable the same or higher level. |Xen has limited support for linear pagetables: A page may either point |to itself, or point to another page of the same level (i.e., L2 to L2, |L3 to L3, and so on). | |XSA-240 introduced an additional restriction that limited the "depth" |of such chains by allowing pages to either *point to* other pages of |the same level, or *be pointed to* by other pages of the same level, |but not both. To implement this, we keep track of the number of |outstanding times a page points to or is pointed to another page |table, to prevent both from happening at the same time. | |Unfortunately, the original commit introducing this reset this count |when resuming validation of a partially-validated pagetable, dropping |some "linear_pt_entry" counts. | |On debug builds on systems where guests used this feature, this might |lead to crashes that look like this: | | Assertion 'oc > 0' failed at mm.c:874 | |Worse, if an attacker could engineer such a situation to occur, they |might be able to make loops or other abitrary chains of linear |pagetables, leading to the denial-of-service situation outlined in |XSA-240. | |This is XSA-309. | |Reported-by: Manuel Bouyer |Signed-off-by: George Dunlap |Reviewed-by: Jan Beulich |--- | xen/arch/x86/mm.c | 2 +- | 1 file changed, 1 insertion(+), 1 deletion(-) | |diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c |index 7d4dd80a85..01393fb0da 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 3044 (offset -15 lines). Hmm... Ignoring the trailing garbage. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA310 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA310 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA310,v 1.1 2019/12/13 13:44:21 bouyer Exp $ | |From 7c537dc8d28a03064a14171ed5c6fc329531816a Mon Sep 17 00:00:00 2001 |From: George Dunlap |Date: Tue, 19 Nov 2019 11:40:34 +0000 |Subject: [PATCH 1/3] x86/mm: Set old_guest_table when destroying vcpu | pagetables | |Changeset 6c4efc1eba ("x86/mm: Don't drop a type ref unless you held a |ref to begin with"), part of XSA-299, changed the calling discipline |of put_page_type() such that if put_page_type() returned -ERESTART |(indicating a partially de-validated page), subsequent calls to |put_page_type() must be called with PTF_partial_set. If called on a |partially de-validated page but without PTF_partial_set, Xen will |BUG(), because to do otherwise would risk opening up the kind of |privilege escalation bug described in XSA-299. | |One place this was missed was in vcpu_destroy_pagetables(). |put_page_and_type_preemptible() is called, but on -ERESTART, the |entire operation is simply restarted, causing put_page_type() to be |called on a partially de-validated page without PTF_partial_set. The |result was that if such an operation were interrupted, Xen would hit a |BUG(). | |Fix this by having vcpu_destroy_pagetables() consistently pass off |interrupted de-validations to put_old_page_type(): |- Unconditionally clear references to the page, even if | put_page_and_type failed |- Set old_guest_table and old_guest_table_partial appropriately | |While here, do some refactoring: | | - Move clearing of arch.cr3 to the top of the function | | - Now that clearing is unconditional, move the unmap to the same | conditional as the l4tab mapping. This also allows us to reduce | the scope of the l4tab variable. | | - Avoid code duplication by looping to drop references on | guest_table_user | |This is part of XSA-310. | |Reported-by: Sarah Newman |Signed-off-by: George Dunlap |Reviewed-by: Jan Beulich |--- |Added in v2. | |Changes in v3: |- Minor comment / whitespace fixes |--- | xen/arch/x86/mm.c | 75 +++++++++++++++++++++++++++++------------------ | 1 file changed, 47 insertions(+), 28 deletions(-) | |diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c |index 01393fb0da..a759afc9e3 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 3127 (offset -15 lines). Hunk #2 succeeded at 3164 (offset -15 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |-- |2.24.0 | |From 128cb126aee9b4a2855ab898fdfbfe7009fbf1f5 Mon Sep 17 00:00:00 2001 |From: George Dunlap |Date: Thu, 31 Oct 2019 11:17:38 +0000 |Subject: [PATCH 2/3] x86/mm: alloc/free_lN_table: Retain partial_flags on | -EINTR | |When validating or de-validating pages (in alloc_lN_table and |free_lN_table respectively), the `partial_flags` local variable is |used to keep track of whether the "current" PTE started the entire |operation in a "may be partial" state. | |One of the patches in XSA-299 addressed the fact that it is possible |for a previously-partially-validated entry to subsequently be found to |have invalid entries (indicated by returning -EINVAL); in which case |page->partial_flags needs to be set to indicate that the current PTE |may have the partial bit set (and thus _put_page_type() should be |called with PTF_partial_set). | |Unfortunately, the patches in XSA-299 assumed that once |put_page_from_lNe() returned -ERESTART on a page, it was not possible |for it to return -EINTR. This turns out to be true for |alloc_lN_table() and free_lN_table, but not for _get_page_type() and |_put_page_type(): both can return -EINTR when called on pages with |PGT_partial set. In these cases, the pages PGT_partial will still be |set; failing to set partial_flags appropriately may allow an attacker |to do a privilege escalation similar to those described in XSA-299. | |Fix this by always copying the local partial_flags variable into |page->partial_flags when exiting early. | |NB that on the "get" side, no adjustment to nr_validated_entries is |needed: whether pte[i] is partially validated or entirely |un-validated, we want nr_validated_entries = i. On the "put" side, |however, we need to adjust nr_validated_entries appropriately: if |pte[i] is entirely validated, we want nr_validated_entries = i + 1; if |pte[i] is partially validated, we want nr_validated_entries = i. | |This is part of XSA-310. | |Reported-by: Sarah Newman |Signed-off-by: George Dunlap |Reviewed-by: Jan Beulich |--- | xen/arch/x86/mm.c | 16 ++++++++-------- | 1 file changed, 8 insertions(+), 8 deletions(-) | |diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c |index a759afc9e3..97c8d73b7b 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 1569 (offset 12 lines). Hunk #2 succeeded at 1651 (offset -9 lines). Hunk #3 succeeded at 1984 (offset 2 lines). Hunk #4 succeeded at 2021 (offset -9 lines). Hunk #5 succeeded at 2063 (offset 2 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |-- |2.24.0 | |From e9f835982a726ae16997c566b5eafab74f8b4cb7 Mon Sep 17 00:00:00 2001 |From: George Dunlap |Date: Mon, 28 Oct 2019 14:33:51 +0000 |Subject: [PATCH 3/3] x86/mm: relinquish_memory: Grab an extra type ref when | setting PGT_partial | |The PGT_partial bit in page->type_info holds both a type count and a |general ref count. During domain tear-down, when free_page_type() |returns -ERESTART, relinquish_memory() correctly handles the general |ref count, but fails to grab an extra type count when setting |PGT_partial. When this bit is eventually cleared, type_count underflows |and triggers the following BUG in page_alloc.c:free_domheap_pages(): | | BUG_ON((pg[i].u.inuse.type_info & PGT_count_mask) != 0); | |As far as we can tell, this page underflow cannot be exploited any any |other way: The page can't be used as a pagetable by the dying domain |because it's dying; it can't be used as a pagetable by any other |domain since it belongs to the dying domain; and ownership can't |transfer to any other domain without hitting the BUG_ON() in |free_domheap_pages(). | |(steal_page() won't work on a page in this state, since it requires |PGC_allocated to be set, and PGC_allocated will already have been |cleared.) | |Fix this by grabbing an extra type ref if setting PGT_partial in |relinquish_memory. | |This is part of XSA-310. | |Reported-by: Sarah Newman |Signed-off-by: George Dunlap |Acked-by: Jan Beulich |--- |v2: |- Move discussion of potential exploits into the commit message |- Keep PGT_partial and put_page() ordering |--- | xen/arch/x86/domain.c | 19 +++++++++++++++++++ | 1 file changed, 19 insertions(+) | |diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c |index f1dd86e12e..51880fc50d 100644 |--- 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 1919 (offset -130 lines). Hmm... Ignoring the trailing garbage. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA311 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA311 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA311,v 1.1 2019/12/13 13:44:21 bouyer Exp $ | |From: Andrew Cooper |Subject: AMD/IOMMU: Cease using a dynamic height for the IOMMU pagetables | |update_paging_mode() has multiple bugs: | | 1) Booting with iommu=debug will cause it to inform you that that it called | without the pdev_list lock held. | 2) When growing by more than a single level, it leaks the newly allocated | table(s) in the case of a further error. | |Furthermore, the choice of default level for a domain has issues: | | 1) All HVM guests grow from 2 to 3 levels during construction because of the | position of the VRAM just below the 4G boundary, so defaulting to 2 is a | waste of effort. | 2) The limit for PV guests doesn't take memory hotplug into account, and | isn't dynamic at runtime like HVM guests. This means that a PV guest may | get RAM which it can't map in the IOMMU. | |The dynamic height is a property unique to AMD, and adds a substantial |quantity of complexity for what is a marginal performance improvement. Remove |the complexity by removing the dynamic height. | |PV guests now get 3 or 4 levels based on any hotplug regions in the host. |This only makes a difference for hardware which previously had all RAM below |the 512G boundary, and a hotplug region above. | |HVM guests now get 4 levels (which will be sufficient until 256TB guests |become a thing), because we don't currently have the information to know when |3 would be safe to use. | |The overhead of this extra level is not expected to be noticeable. It costs |one page (4k) per domain, and one extra IO-TLB paging structure cache entry |which is very hot and less likely to be evicted. | |This is XSA-311. | |Reported-by: XXX PERSON 3 |Signed-off-by: Andrew Cooper |Signed-off-by: Andrew Cooper |Acked-by: Jan Beulich | |--- xen/drivers/passthrough/amd/iommu_map.c.orig |+++ xen/drivers/passthrough/amd/iommu_map.c -------------------------- Patching file xen/drivers/passthrough/amd/iommu_map.c using Plan A... Hunk #1 succeeded at 569. Hunk #2 succeeded at 594. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/drivers/passthrough/amd/pci_amd_iommu.c.orig |+++ xen/drivers/passthrough/amd/pci_amd_iommu.c -------------------------- Patching file xen/drivers/passthrough/amd/pci_amd_iommu.c using Plan A... Hunk #1 succeeded at 242. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-xen_Makefile => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/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 2018/07/24 13:40:11 bouyer Exp $ | |--- xen/Makefile.orig 2018-04-17 19:21:31.000000000 +0200 |+++ xen/Makefile 2018-04-23 13:29:47.000000000 +0200 -------------------------- Patching file xen/Makefile using Plan A... Hunk #1 succeeded at 167. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-xen_Rules.mk => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-xen_Rules.mk Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_Rules.mk,v 1.1 2018/07/24 13:40:11 bouyer Exp $ | |--- xen/Rules.mk.orig 2018-04-23 14:50:02.000000000 +0200 |+++ xen/Rules.mk 2018-04-23 14:50:32.000000000 +0200 -------------------------- Patching file xen/Rules.mk using Plan A... Hunk #1 succeeded at 1. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-xen_arch_x86_Rules.mk => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/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 2018/07/24 13:40:11 bouyer Exp $ | |--- xen/arch/x86/Rules.mk.orig 2018-04-17 19:21:31.000000000 +0200 |+++ xen/arch/x86/Rules.mk 2018-04-23 13:31:24.000000000 +0200 -------------------------- Patching file xen/arch/x86/Rules.mk using Plan A... Hunk #1 succeeded at 8. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-xen_arch_x86_boot_build32.mk => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-xen_arch_x86_boot_build32.mk Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_arch_x86_boot_build32.mk,v 1.1 2018/07/24 13:40:11 bouyer Exp $ |linux's toolchain doesn't generate a .eh_frame section but NetBSD does. |remove it. | |--- xen/arch/x86/boot/build32.mk.orig 2018-04-17 19:21:31.000000000 +0200 |+++ xen/arch/x86/boot/build32.mk 2018-04-23 13:29:47.000000000 +0200 -------------------------- Patching file xen/arch/x86/boot/build32.mk using Plan A... Hunk #1 succeeded at 25. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-xen_tools_symbols.c => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-xen_tools_symbols.c Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_tools_symbols.c,v 1.1 2018/07/24 13:40:11 bouyer Exp $ |fix "error: array subscript has type 'char'" | |--- xen/tools/symbols.c.orig 2018-04-17 19:21:31.000000000 +0200 |+++ xen/tools/symbols.c 2018-04-23 13:29:47.000000000 +0200 -------------------------- Patching file xen/tools/symbols.c using Plan A... Hunk #1 succeeded at 173. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-zz-bouyer => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-zz-bouyer Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-zz-bouyer,v 1.3 2019/03/25 15:28:13 bouyer Exp $ |Dirty hack to avoid assert failure. This has been discussed on xen-devel |but no solution has been found so far. |The box producing http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/ |is running with this patch; the printk has fired but the |hypervisor keeps running. | |--- xen/arch/x86/mm.c.orig 2018-07-19 10:32:07.000000000 +0200 |+++ xen/arch/x86/mm.c 2018-07-21 20:47:47.000000000 +0200 -------------------------- Patching file xen/arch/x86/mm.c using Plan A... Hunk #1 succeeded at 724 (offset 50 lines). done ===> Creating toolchain wrappers for xenkernel411-4.11.3nb1