=> 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.3nb2
==========================================================================
The following variables will affect the build process of this package,
xenkernel411-4.11.3nb2.  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.18
=> Build dependency cwrappers>=20150314: found cwrappers-20180325
===> 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'.
===> Overriding tools for xenkernel411-4.11.3nb2
===> Extracting for xenkernel411-4.11.3nb2
===> Patching for xenkernel411-4.11.3nb2
=> Applying pkgsrc patches for xenkernel411-4.11.3nb2
=> 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 <jbeulich@suse.com>
|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 <jbeulich@suse.com>
|Acked-by: Julien Grall <julien@xen.org>
|---
|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 <andrew.cooper3@citrix.com>
|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 <hakon@alstadheim.priv.no>
|Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
|Reviewed-by: Jan Beulich <jbeulich@suse.com>
|Acked-by: Kevin Tian <kevin.tian@intel.com>
|
|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 <george.dunlap@citrix.com>
|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 <bouyer@antioche.eu.org>
|Signed-off-by: George Dunlap <george.dunlap@citrix.com>
|Reviewed-by: Jan Beulich <jbeulich@suse.com>
|---
| 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 <george.dunlap@citrix.com>
|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 <srn@prgmr.com>
|Signed-off-by: George Dunlap <george.dunlap@citrix.com>
|Reviewed-by: Jan Beulich <jbeulich@suse.com>
|---
|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 <george.dunlap@citrix.com>
|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 <srn@prgmr.com>
|Signed-off-by: George Dunlap <george.dunlap@citrix.com>
|Reviewed-by: Jan Beulich <jbeulich@suse.com>
|---
| 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 <george.dunlap@citrix.com>
|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 <srn@prgmr.com>
|Signed-off-by: George Dunlap <george.dunlap@citrix.com>
|Acked-by: Jan Beulich <jbeulich@suse.com>
|---
|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 <andrew.cooper3@citrix.com>
|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 <XXX EMAIL>3
|Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
|Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
|Acked-by: Jan Beulich <jbeulich@suse.com>
|
|--- 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-XSA313
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA313
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-XSA313,v 1.1 2020/04/15 15:37:19 bouyer Exp $
|
|From: Jan Beulich <jbeulich@suse.com>
|Subject: xenoprof: clear buffer intended to be shared with guests
|
|alloc_xenheap_pages() making use of MEMF_no_scrub is fine for Xen
|internally used allocations, but buffers allocated to be shared with
|(unpriviliged) guests need to be zapped of their prior content.
|
|This is part of XSA-313.
|
|Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
|Reviewed-by: Wei Liu <wl@xen.org>
|
|--- xen/common/xenoprof.c.orig
|+++ xen/common/xenoprof.c
--------------------------
Patching file xen/common/xenoprof.c using Plan A...
Hunk #1 succeeded at 254 (offset 1 line).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|From: Jan Beulich <jbeulich@suse.com>
|Subject: xenoprof: limit consumption of shared buffer data
|
|Since a shared buffer can be written to by the guest, we may only read
|the head and tail pointers from there (all other fields should only ever
|be written to). Furthermore, for any particular operation the two values
|must be read exactly once, with both checks and consumption happening
|with the thus read values. (The backtrace related xenoprof_buf_space()
|use in xenoprof_log_event() is an exception: The values used there get
|re-checked by every subsequent xenoprof_add_sample().)
|
|Since that code needed touching, also fix the double increment of the
|lost samples count in case the backtrace related xenoprof_add_sample()
|invocation in xenoprof_log_event() fails.
|
|Where code is being touched anyway, add const as appropriate, but take
|the opportunity to entirely drop the now unused domain parameter of
|xenoprof_buf_space().
|
|This is part of XSA-313.
|
|Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Reviewed-by: George Dunlap <george.dunlap@citrix.com>
|Reviewed-by: Wei Liu <wl@xen.org>
|
|--- xen/common/xenoprof.c.orig
|+++ xen/common/xenoprof.c
--------------------------
Patching file xen/common/xenoprof.c using Plan A...
Hunk #1 succeeded at 480 (offset 1 line).
Hunk #2 succeeded at 504 (offset 1 line).
Hunk #3 succeeded at 528 (offset 1 line).
Hunk #4 succeeded at 536 (offset 1 line).
Hunk #5 succeeded at 568 (offset 1 line).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/include/xen/xenoprof.h.orig
|+++ xen/include/xen/xenoprof.h
--------------------------
Patching file xen/include/xen/xenoprof.h using Plan A...
Hunk #1 succeeded at 61.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA316
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA316
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-XSA316,v 1.1 2020/04/15 15:45:04 bouyer Exp $
|
|From: Ross Lagerwall <ross.lagerwall@citrix.com>
|Subject: xen/gnttab: Fix error path in map_grant_ref()
|
|Part of XSA-295 (c/s 863e74eb2cffb) inadvertently re-positioned the brackets,
|changing the logic.  If the _set_status() call fails, the grant_map hypercall
|would fail with a status of 1 (rc != GNTST_okay) instead of the expected
|negative GNTST_* error.
|
|This error path can be taken due to bad guest state, and causes net/blk-back
|in Linux to crash.
|
|This is XSA-316.
|
|Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
|Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
|Reviewed-by: Julien Grall <jgrall@amazon.com>
|
|diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
|index 9fd6e60416..4b5344dc21 100644
|--- xen/common/grant_table.c.orig
|+++ xen/common/grant_table.c
--------------------------
Patching file xen/common/grant_table.c using Plan A...
Hunk #1 succeeded at 1000 (offset -31 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA318
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA318
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-XSA318,v 1.1 2020/04/15 15:37:19 bouyer Exp $
|
|From: Jan Beulich <jbeulich@suse.com>
|Subject: gnttab: fix GNTTABOP_copy continuation handling
|
|The XSA-226 fix was flawed - the backwards transformation on rc was done
|too early, causing a continuation to not get invoked when the need for
|preemption was determined at the very first iteration of the request.
|This in particular means that all of the status fields of the individual
|operations would be left untouched, i.e. set to whatever the caller may
|or may not have initialized them to.
|
|This is part of XSA-318.
|
|Reported-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
|Tested-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Reviewed-by: Juergen Gross <jgross@suse.com>
|
|--- xen/common/grant_table.c.orig
|+++ xen/common/grant_table.c
--------------------------
Patching file xen/common/grant_table.c using Plan A...
Hunk #1 succeeded at 3518 (offset -58 lines).
Hunk #2 succeeded at 3585 (offset -58 lines).
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.3nb2