pkgsrc-Changes-HG archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

[pkgsrc/trunk]: pkgsrc/sysutils/xenkernel411 Add patches for relevant Xen sec...



details:   https://anonhg.NetBSD.org/pkgsrc/rev/7a1172cd2d22
branches:  trunk
changeset: 343906:7a1172cd2d22
user:      bouyer <bouyer%pkgsrc.org@localhost>
date:      Wed Nov 13 13:36:11 2019 +0000

description:
Add patches for relevant Xen security advisory up to XSA305 (everything
up to XSA297 is already fixed upstream).
Bump PKGREVISION

diffstat:

 sysutils/xenkernel411/Makefile             |    4 +-
 sysutils/xenkernel411/distinfo             |    6 +-
 sysutils/xenkernel411/patches/patch-XSA298 |   89 ++++
 sysutils/xenkernel411/patches/patch-XSA302 |  537 +++++++++++++++++++++++++++++
 sysutils/xenkernel411/patches/patch-XSA304 |  481 +++++++++++++++++++++++++
 sysutils/xenkernel411/patches/patch-XSA305 |  482 ++++++++++++++++++++++++++
 6 files changed, 1596 insertions(+), 3 deletions(-)

diffs (truncated from 1637 to 300 lines):

diff -r 296d3f4a60f9 -r 7a1172cd2d22 sysutils/xenkernel411/Makefile
--- a/sysutils/xenkernel411/Makefile    Wed Nov 13 13:20:11 2019 +0000
+++ b/sysutils/xenkernel411/Makefile    Wed Nov 13 13:36:11 2019 +0000
@@ -1,7 +1,7 @@
-# $NetBSD: Makefile,v 1.8 2019/08/30 13:16:27 bouyer Exp $
+# $NetBSD: Makefile,v 1.9 2019/11/13 13:36:11 bouyer Exp $
 
 VERSION=       4.11.2
-#PKGREVISION=  0
+PKGREVISION=   1
 DISTNAME=      xen-${VERSION}
 PKGNAME=       xenkernel411-${VERSION}
 CATEGORIES=    sysutils
diff -r 296d3f4a60f9 -r 7a1172cd2d22 sysutils/xenkernel411/distinfo
--- a/sysutils/xenkernel411/distinfo    Wed Nov 13 13:20:11 2019 +0000
+++ b/sysutils/xenkernel411/distinfo    Wed Nov 13 13:36:11 2019 +0000
@@ -1,10 +1,14 @@
-$NetBSD: distinfo,v 1.5 2019/08/30 13:16:27 bouyer Exp $
+$NetBSD: distinfo,v 1.6 2019/11/13 13:36:11 bouyer Exp $
 
 SHA1 (xen411/xen-4.11.2.tar.gz) = 82766db0eca7ce65962732af8a31bb5cce1eb7ce
 RMD160 (xen411/xen-4.11.2.tar.gz) = 6dcb1ac3e72381474912607b30b59fa55d87d38b
 SHA512 (xen411/xen-4.11.2.tar.gz) = 48d3d926d35eb56c79c06d0abc6e6be2564fadb43367cc7f46881c669a75016707672179c2cca1c4cfb14af2cefd46e2e7f99470cddf7df2886d8435a2de814e
 Size (xen411/xen-4.11.2.tar.gz) = 25164925 bytes
 SHA1 (patch-Config.mk) = 9372a09efd05c9fbdbc06f8121e411fcb7c7ba65
+SHA1 (patch-XSA298) = 63e0f96ce3b945b16b98b51b423bafec14cf2be6
+SHA1 (patch-XSA302) = 12fbb7dfea27f53c70c8115487a2e30595549c2b
+SHA1 (patch-XSA304) = f2c22732227e11a3e77c630f0264a689eed53399
+SHA1 (patch-XSA305) = eb5e0096cbf501fcbd7a5c5f9d1f932b557636b6
 SHA1 (patch-xen_Makefile) = 465388d80de414ca3bb84faefa0f52d817e423a6
 SHA1 (patch-xen_Rules.mk) = c743dc63f51fc280d529a7d9e08650292c171dac
 SHA1 (patch-xen_arch_x86_Rules.mk) = 0bedfc53a128a87b6a249ae04fbdf6a053bfb70b
diff -r 296d3f4a60f9 -r 7a1172cd2d22 sysutils/xenkernel411/patches/patch-XSA298
--- /dev/null   Thu Jan 01 00:00:00 1970 +0000
+++ b/sysutils/xenkernel411/patches/patch-XSA298        Wed Nov 13 13:36:11 2019 +0000
@@ -0,0 +1,89 @@
+$NetBSD: patch-XSA298,v 1.1 2019/11/13 13:36:11 bouyer Exp $
+
+From: Jan Beulich <jbeulich%suse.com@localhost>
+Subject: x86/PV: check GDT/LDT limits during emulation
+
+Accesses beyond the LDT limit originating from emulation would trigger
+the ASSERT() in pv_map_ldt_shadow_page(). On production builds such
+accesses would cause an attempt to promote the touched page (offset from
+the present LDT base address) to a segment descriptor one. If this
+happens to succeed, guest user mode would be able to elevate its
+privileges to that of the guest kernel. This is particularly easy when
+there's no LDT at all, in which case the LDT base stored internally to
+Xen is simply zero.
+
+Also adjust the ASSERT() that was triggering: It was off by one to
+begin with, and for production builds we also better use
+ASSERT_UNREACHABLE() instead with suitable recovery code afterwards.
+
+This is XSA-298.
+
+Reported-by: Andrew Cooper <andrew.cooper3%citrix.com@localhost>
+Signed-off-by: Jan Beulich <jbeulich%suse.com@localhost>
+Reviewed-by: Andrew Cooper <andrew.cooper3%citrix.com@localhost>
+
+--- xen/arch/x86/pv/emul-gate-op.c.orig
++++ xen/arch/x86/pv/emul-gate-op.c
+@@ -51,7 +51,13 @@ static int read_gate_descriptor(unsigned
+     const struct desc_struct *pdesc = gdt_ldt_desc_ptr(gate_sel);
+ 
+     if ( (gate_sel < 4) ||
+-         ((gate_sel >= FIRST_RESERVED_GDT_BYTE) && !(gate_sel & 4)) ||
++         /*
++          * We're interested in call gates only, which occupy a single
++          * seg_desc_t for 32-bit and a consecutive pair of them for 64-bit.
++          */
++         ((gate_sel >> 3) + !is_pv_32bit_vcpu(v) >=
++          (gate_sel & 4 ? v->arch.pv_vcpu.ldt_ents
++                        : v->arch.pv_vcpu.gdt_ents)) ||
+          __get_user(desc, pdesc) )
+         return 0;
+ 
+@@ -70,7 +76,7 @@ static int read_gate_descriptor(unsigned
+     if ( !is_pv_32bit_vcpu(v) )
+     {
+         if ( (*ar & 0x1f00) != 0x0c00 ||
+-             (gate_sel >= FIRST_RESERVED_GDT_BYTE - 8 && !(gate_sel & 4)) ||
++             /* Limit check done above already. */
+              __get_user(desc, pdesc + 1) ||
+              (desc.b & 0x1f00) )
+             return 0;
+--- xen/arch/x86/pv/emulate.c.orig
++++ xen/arch/x86/pv/emulate.c
+@@ -31,7 +31,14 @@ int pv_emul_read_descriptor(unsigned int
+ {
+     struct desc_struct desc;
+ 
+-    if ( sel < 4)
++    if ( sel < 4 ||
++         /*
++          * Don't apply the GDT limit here, as the selector may be a Xen
++          * provided one. __get_user() will fail (without taking further
++          * action) for ones falling in the gap between guest populated
++          * and Xen ones.
++          */
++         ((sel & 4) && (sel >> 3) >= v->arch.pv_vcpu.ldt_ents) )
+         desc.b = desc.a = 0;
+     else if ( __get_user(desc, gdt_ldt_desc_ptr(sel)) )
+         return 0;
+--- xen/arch/x86/pv/mm.c.orig
++++ xen/arch/x86/pv/mm.c
+@@ -92,12 +92,16 @@ bool pv_map_ldt_shadow_page(unsigned int
+     BUG_ON(unlikely(in_irq()));
+ 
+     /*
+-     * Hardware limit checking should guarantee this property.  NB. This is
++     * Prior limit checking should guarantee this property.  NB. This is
+      * safe as updates to the LDT can only be made by MMUEXT_SET_LDT to the
+      * current vcpu, and vcpu_reset() will block until this vcpu has been
+      * descheduled before continuing.
+      */
+-    ASSERT((offset >> 3) <= curr->arch.pv_vcpu.ldt_ents);
++    if ( unlikely((offset >> 3) >= curr->arch.pv_vcpu.ldt_ents) )
++    {
++        ASSERT_UNREACHABLE();
++        return false;
++    }
+ 
+     if ( is_pv_32bit_domain(currd) )
+         linear = (uint32_t)linear;
diff -r 296d3f4a60f9 -r 7a1172cd2d22 sysutils/xenkernel411/patches/patch-XSA302
--- /dev/null   Thu Jan 01 00:00:00 1970 +0000
+++ b/sysutils/xenkernel411/patches/patch-XSA302        Wed Nov 13 13:36:11 2019 +0000
@@ -0,0 +1,537 @@
+$NetBSD: patch-XSA302,v 1.1 2019/11/13 13:36:11 bouyer Exp $
+
+From bbca29f88d9ad9c7e91125a3b5d5f13a23e5801f Mon Sep 17 00:00:00 2001
+From: Jan Beulich <jbeulich%suse.com@localhost>
+Date: Wed, 2 Oct 2019 13:36:59 +0200
+Subject: [PATCH 1/2] IOMMU: add missing HVM check
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Fix an unguarded d->arch.hvm access in assign_device().
+
+Signed-off-by: Jan Beulich <jbeulich%suse.com@localhost>
+Reviewed-by: Roger Pau Monné <roger.pau%citrix.com@localhost>
+Acked-by: Andrew Cooper <andrew.cooper3%citrix.com@localhost>
+
+(cherry picked from commit 41fd1009cd7416b73d745a77c24b4e8d1a296fe6)
+Signed-off-by: Ian Jackson <ian.jackson%eu.citrix.com@localhost>
+---
+ xen/drivers/passthrough/pci.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
+index f51cae7f4e..037aba7c94 100644
+--- xen/drivers/passthrough/pci.c.orig
++++ xen/drivers/passthrough/pci.c
+@@ -1416,7 +1416,8 @@ static int assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn, u32 flag)
+     /* Prevent device assign if mem paging or mem sharing have been 
+      * enabled for this domain */
+     if ( unlikely(!need_iommu(d) &&
+-            (d->arch.hvm_domain.mem_sharing_enabled ||
++            ((is_hvm_domain(d) &&
++              d->arch.hvm_domain.mem_sharing_enabled) ||
+              vm_event_check_ring(d->vm_event_paging) ||
+              p2m_get_hostp2m(d)->global_logdirty)) )
+         return -EXDEV;
+-- 
+2.11.0
+
+From ec99857f59f7f06236f11ca8b0b2303e5e745cc4 Mon Sep 17 00:00:00 2001
+From: Paul Durrant <paul.durrant%citrix.com@localhost>
+Date: Mon, 14 Oct 2019 17:52:59 +0100
+Subject: [PATCH 2/2] passthrough: quarantine PCI devices
+
+When a PCI device is assigned to an untrusted domain, it is possible for
+that domain to program the device to DMA to an arbitrary address. The
+IOMMU is used to protect the host from malicious DMA by making sure that
+the device addresses can only target memory assigned to the guest. However,
+when the guest domain is torn down the device is assigned back to dom0,
+thus allowing any in-flight DMA to potentially target critical host data.
+
+This patch introduces a 'quarantine' for PCI devices using dom_io. When
+the toolstack makes a device assignable (by binding it to pciback), it
+will now also assign it to DOMID_IO and the device will only be assigned
+back to dom0 when the device is made unassignable again. Whilst device is
+assignable it will only ever transfer between dom_io and guest domains.
+dom_io is actually only used as a sentinel domain for quarantining purposes;
+it is not configured with any IOMMU mappings. Assignment to dom_io simply
+means that the device's initiator (requestor) identifier is not present in
+the IOMMU's device table and thus any DMA transactions issued will be
+terminated with a fault condition.
+
+In addition, a fix to assignment handling is made for VT-d.  Failure
+during the assignment step should not lead to a device still being
+associated with its prior owner. Hand the device to DomIO temporarily,
+until the assignment step has completed successfully.  Remove the PI
+hooks from the source domain then earlier as well.
+
+Failure of the recovery reassign_device_ownership() may not go silent:
+There e.g. may still be left over RMRR mappings in the domain assignment
+to which has failed, and hence we can't allow that domain to continue
+executing.
+
+NOTE: This patch also includes one printk() cleanup; the
+      "XEN_DOMCTL_assign_device: " tag is dropped in iommu_do_pci_domctl(),
+      since similar printk()-s elsewhere also don't log such a tag.
+
+This is XSA-302.
+
+Signed-off-by: Paul Durrant <paul.durrant%citrix.com@localhost>
+Signed-off-by: Jan Beulich <jbeulich%suse.com@localhost>
+Signed-off-by: Ian Jackson <ian.jackson%eu.citrix.com@localhost>
+---
+ tools/libxl/libxl_pci.c                     | 25 +++++++++++-
+ xen/arch/x86/mm.c                           |  2 +
+ xen/common/domctl.c                         | 14 ++++++-
+ xen/drivers/passthrough/amd/pci_amd_iommu.c | 10 ++++-
+ xen/drivers/passthrough/iommu.c             |  9 +++++
+ xen/drivers/passthrough/pci.c               | 59 ++++++++++++++++++++++-------
+ xen/drivers/passthrough/vtd/iommu.c         | 40 ++++++++++++++++---
+ xen/include/xen/pci.h                       |  3 ++
+ 8 files changed, 138 insertions(+), 24 deletions(-)
+
+diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
+index 4755a0c93c..81890a91ac 100644
+--- tools/libxl/libxl_pci.c.orig
++++ tools/libxl/libxl_pci.c
+@@ -754,6 +754,7 @@ static int libxl__device_pci_assignable_add(libxl__gc *gc,
+                                             libxl_device_pci *pcidev,
+                                             int rebind)
+ {
++    libxl_ctx *ctx = libxl__gc_owner(gc);
+     unsigned dom, bus, dev, func;
+     char *spath, *driver_path = NULL;
+     int rc;
+@@ -779,7 +780,7 @@ static int libxl__device_pci_assignable_add(libxl__gc *gc,
+     }
+     if ( rc ) {
+         LOG(WARN, PCI_BDF" already assigned to pciback", dom, bus, dev, func);
+-        return 0;
++        goto quarantine;
+     }
+ 
+     /* Check to see if there's already a driver that we need to unbind from */
+@@ -810,6 +811,19 @@ static int libxl__device_pci_assignable_add(libxl__gc *gc,
+         return ERROR_FAIL;
+     }
+ 
++quarantine:
++    /*
++     * DOMID_IO is just a sentinel domain, without any actual mappings,
++     * so always pass XEN_DOMCTL_DEV_RDM_RELAXED to avoid assignment being
++     * unnecessarily denied.
++     */
++    rc = xc_assign_device(ctx->xch, DOMID_IO, pcidev_encode_bdf(pcidev),
++                          XEN_DOMCTL_DEV_RDM_RELAXED);
++    if ( rc < 0 ) {
++        LOG(ERROR, "failed to quarantine "PCI_BDF, dom, bus, dev, func);
++        return ERROR_FAIL;
++    }
++
+     return 0;
+ }
+ 
+@@ -817,9 +831,18 @@ static int libxl__device_pci_assignable_remove(libxl__gc *gc,
+                                                libxl_device_pci *pcidev,
+                                                int rebind)
+ {
++    libxl_ctx *ctx = libxl__gc_owner(gc);
+     int rc;
+     char *driver_path;
+ 
++    /* De-quarantine */
++    rc = xc_deassign_device(ctx->xch, DOMID_IO, pcidev_encode_bdf(pcidev));
++    if ( rc < 0 ) {
++        LOG(ERROR, "failed to de-quarantine "PCI_BDF, pcidev->domain, pcidev->bus,
++            pcidev->dev, pcidev->func);
++        return ERROR_FAIL;
++    }
++
+     /* Unbind from pciback */
+     if ( (rc=pciback_dev_is_assigned(gc, pcidev)) < 0 ) {
+         return ERROR_FAIL;
+diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
+index e6a4cb28f8..c1ab57f9a5 100644
+--- xen/arch/x86/mm.c.orig
++++ xen/arch/x86/mm.c
+@@ -295,9 +295,11 @@ void __init arch_init_memory(void)
+      * Initialise our DOMID_IO domain.
+      * This domain owns I/O pages that are within the range of the page_info
+      * array. Mappings occur at the priv of the caller.
++     * Quarantined PCI devices will be associated with this domain.
+      */
+     dom_io = domain_create(DOMID_IO, NULL);
+     BUG_ON(IS_ERR(dom_io));
++    INIT_LIST_HEAD(&dom_io->arch.pdev_list);
+ 
+     /*
+      * Initialise our COW domain.
+diff --git a/xen/common/domctl.c b/xen/common/domctl.c
+index 9b7bc083ee..741d774cd1 100644



Home | Main Index | Thread Index | Old Index