main/xen: update security fix for xsa243

UPDATES IN VERSION 5
====================

New final patch, addressing a hypervisor crash the original fix caused,
which by itself represents another security issue (DoS).

http://openwall.com/lists/oss-security/2017/11/15/4

3 files changed, 59 insertions, 3 deletions

diff --git a/main/xen/APKBUILD b/main/xen/APKBUILD
index 158d755dba..19d4fbd78e 100644
--- a/main/xen/APKBUILD
+++ b/main/xen/APKBUILD
@@ -3,7 +3,7 @@
 # Maintainer: William Pitcock <nenolod@dereferenced.org>
 pkgname=xen
 pkgver=4.9.0
-pkgrel=7
+pkgrel=8
 pkgdesc="Xen hypervisor"
 url="http://www.xen.org/"
 arch="x86_64 armhf aarch64"
@@ -167,7 +167,8 @@ source="https://downloads.xenproject.org/release/$pkgname/$pkgver/$pkgname-$pkgv
 	xsa240-2.patch
 	xsa241-4.9.patch
 	xsa242-4.9.patch
-	xsa243.patch
+	xsa243-1.patch
+	xsa243-2.patch
 	xsa244.patch
 	xsa245-1.patch
 	xsa245-2.patch
@@ -453,7 +454,8 @@ e209e629757b3471eae415913c34c662882172daad634083ee29823c2cb3f00e98886352085c1afc
 344519cd83ad13245de0e183b7afe564597b30d20756e44f98c0a00df55020d7ef85b92e71701c9791842a48cec93e0fcb9bfba2443313b3aafd8d21ea36abf4  xsa240-2.patch
 560d8062b5683b6533a67eebafdd81e6a9d2c9194cc9f9b1404544503238d4f1d98bccb1afac477f6a55ffbc67cf9629a43fd67a745ca9093e2adc0478dd0ddb  xsa241-4.9.patch
 86aa763949ca36a36120a40eafbdf3a8e8bc04acd32ee6bc1e3ae90b189b86b9b166b81a9e0a4f86a7eb1fcc8723ae8ba6bd0f84fa9732e7e4e1ccea45d0b7c1  xsa242-4.9.patch
-9f269e262aa67ff9a304ed6fc64ee9c5c9f6fd606d520fc2614cd173cddc9735ad42f91a97b91f1b9c5368d54d514820937edd0ce302dc3839b426398dc6b700  xsa243.patch
+9f269e262aa67ff9a304ed6fc64ee9c5c9f6fd606d520fc2614cd173cddc9735ad42f91a97b91f1b9c5368d54d514820937edd0ce302dc3839b426398dc6b700  xsa243-1.patch
+8aaf0599259b1ff34171684467089da4a26af8fe67eedf22066955b34b2460c45abdf0f19a5a5e3dd3231b944674c62b9d3112ad7d765afc4bdbcdcfbad226e1  xsa243-2.patch
 0fd35e74be6f049f1f376aa8295b14f57b92f5e45e7487e5b485c2b8f6faa2950d0fe7d8a863692b3dab8a3a7ef1d9dd94be2c6b55d01802b0d86c84d2fa9e29  xsa244.patch
 b19197934e8685fc2af73f404b5c8cbed66d9241e5ff902d1a77fdc227e001a13b775a53d6e303d5f27419f5590561c84ec69409152d9773a5e6050c16e92f1b  xsa245-1.patch
 75369673232b2107b59dc0242d6fc224c016b9dcbf3299eab90a1d7c365d617fbc91f7b25075b394fee92782db37ce83c416387fa5ad4c4fcd51d0775a8a754f  xsa245-2.patch
diff --git a/main/xen/xsa243.patch b/main/xen/xsa243-1.patch
index aaff277514..aaff277514 100644
--- a/main/xen/xsa243.patch
+++ b/main/xen/xsa243-1.patch
diff --git a/main/xen/xsa243-2.patch b/main/xen/xsa243-2.patch
new file mode 100644
index 0000000000..1aca5d3dbd
--- /dev/null
+++ b/main/xen/xsa243-2.patch
@@ -0,0 +1,54 @@
+From: Andrew Cooper <andrew.cooper3@citrix.com>
+Subject: x86/shadow: correct SH_LINEAR mapping detection in sh_guess_wrmap()
+
+The fix for XSA-243 / CVE-2017-15592 (c/s bf2b4eadcf379) introduced a change
+in behaviour for sh_guest_wrmap(), where it had to cope with no shadow linear
+mapping being present.
+
+As the name suggests, guest_vtable is a mapping of the guests pagetable, not
+Xen's pagetable, meaning that it isn't the pagetable we need to check for the
+shadow linear slot in.
+
+The practical upshot is that a shadow HVM vcpu which switches into 4-level
+paging mode, with an L4 pagetable that contains a mapping which aliases Xen's
+SH_LINEAR_PT_VIRT_START will fool the safety check for whether a SHADOW_LINEAR
+mapping is present.  As the check passes (when it should have failed), Xen
+subsequently falls over the missing mapping with a pagefault such as:
+
+    (XEN) Pagetable walk from ffff8140a0503880:
+    (XEN)  L4[0x102] = 000000046c218063 ffffffffffffffff
+    (XEN)  L3[0x102] = 000000046c218063 ffffffffffffffff
+    (XEN)  L2[0x102] = 000000046c218063 ffffffffffffffff
+    (XEN)  L1[0x103] = 0000000000000000 ffffffffffffffff
+
+This is part of XSA-243.
+
+Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
+Reviewed-by: Tim Deegan <tim@xen.org>
+
+--- a/xen/arch/x86/mm/shadow/multi.c
++++ b/xen/arch/x86/mm/shadow/multi.c
+@@ -4350,11 +4350,18 @@ static int sh_guess_wrmap(struct vcpu *v
+ 
+     /* Carefully look in the shadow linear map for the l1e we expect */
+ #if SHADOW_PAGING_LEVELS >= 4
+-    /* Is a shadow linear map is installed in the first place? */
+-    sl4p  = v->arch.paging.shadow.guest_vtable;
+-    sl4p += shadow_l4_table_offset(SH_LINEAR_PT_VIRT_START);
+-    if ( !(shadow_l4e_get_flags(*sl4p) & _PAGE_PRESENT) )
+-        return 0;
++    /*
++     * Non-external guests (i.e. PV) have a SHADOW_LINEAR mapping from the
++     * moment their shadows are created.  External guests (i.e. HVM) may not,
++     * but always have a regular linear mapping, which we can use to observe
++     * whether a SHADOW_LINEAR mapping is present.
++     */
++    if ( paging_mode_external(d) )
++    {
++        sl4p =  __linear_l4_table + l4_linear_offset(SH_LINEAR_PT_VIRT_START);
++        if ( !(shadow_l4e_get_flags(*sl4p) & _PAGE_PRESENT) )
++            return 0;
++    }
+     sl4p = sh_linear_l4_table(v) + shadow_l4_linear_offset(vaddr);
+     if ( !(shadow_l4e_get_flags(*sl4p) & _PAGE_PRESENT) )
+         return 0;