Xen Security Advisory 245 (CVE-2017-17046)

* Xen Security Advisory 245 (CVE-2017-17046) - ARM: Some memory not scrubbed at boot
@ 2017-11-30 11:59 Xen.org security team
  0 siblings, 0 replies; 3+ messages in thread
From: Xen.org security team @ 2017-11-30 11:59 UTC (permalink / raw)
  To: xen-announce, xen-devel, xen-users, oss-security; +Cc: Xen.org security team

[-- Attachment #1: Type: text/plain, Size: 2263 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

            Xen Security Advisory CVE-2017-17046 / XSA-245
                              version 2

                 ARM: Some memory not scrubbed at boot

UPDATES IN VERSION 2
====================

CVE assigned.

NOTE REGARDING LACK OF EMBARGO
==============================

This bug was discussed publicly before it was realised that it was a
security vulnerability.

ISSUE DESCRIPTION
=================

Data can remain readable in DRAM across soft and even hard reboots.
To ensure that sensitive data is not leaked from one domain to another
after a reboot, Xen must "scrub" all memory on boot (write it with
zeroes).

Unfortunately, it was discovered that when memory was in disjoint blocks,
or when the first block didn't begin at physical address 0, arithmetic
errors meant that some memory was not scrubbed.

IMPACT
======

Sensitive information from one domain before a reboot might be visible
to another domain after a reboot.

VULNERABLE SYSTEMS
==================

Only ARM systems are vulnerable.

All versions of Xen since 4.5 are vulnerable.

Only hardware with disjoint blocks, or physical addresses not starting at 0
are vulnerable; this includes the majority of ARM systems.

MITIGATION
==========

None.

RESOLUTION
==========

Applying the appropriate attached patches resolves this issue.

xsa245/*.patch         All versions of Xen

$ sha256sum xsa245* xsa245*/*
121829263b85fcb5eac8e38fb44e77d3aab1dd7ae6ef665bf84bb49e5e161d24  xsa245.meta
526f9e1b127fbb316762ce8e8f4563bc9de0c55a1db581456a3017d570d35bdd  xsa245/0001-xen-page_alloc-Cover-memory-unreserved-after-boot-in.patch
7164010112fcccd9cd88e72ace2eeabdb364dd6f4d05c434686267d18067f420  xsa245/0002-xen-arm-Correctly-report-the-memory-region-in-the-du.patch
$

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJaH/KMAAoJEIP+FMlX6CvZMfgH/j86RZD7z55Lt7ITlLWZwucP
uTDw8gjJRtB/8mgrJq97Q37rWBHvvfITUYHW7wxA+LJQAje2X7y+3kV4EWpF0hFI
BMU3QfeyTCgYbmTb0NOaULGzhDtN/QKjFq48fccnRYfg7MisIEy5dVqDWnbUQfIn
STP/w63rpjx2mpZVSBuWC+yA0mjcaCyezR6xJoN1rQjVe/FrnzoJwCYBmpR3JY9+
AIeRvLLpK/vbREZZxOpBioL9KQxH+zahIwQJkS56Jbt8uC1Fq0UFe809Xt+8I4d+
yOJiflkHKgFBW1KUL1Pirq+koad1p66Ciz9c8j88Wop0fhDTQdn10mbteizOM64=
=PRKQ
-----END PGP SIGNATURE-----

[-- Attachment #2: xsa245.meta --]
[-- Type: application/octet-stream, Size: 2549 bytes --]

{
  "XSA": 245,
  "SupportedVersions": [
    "master",
    "4.9",
    "4.8",
    "4.7",
    "4.6",
    "4.5"
  ],
  "Trees": [
    "xen"
  ],
  "Recipes": {
    "4.5": {
      "XenVersion": "4.5",
      "Recipes": {
        "xen": {
          "StableRef": "83724d9f3ae21a3b96362742e2f052b19d9f559a",
          "Prereqs": [
            237,
            238,
            239,
            240,
            241,
            242,
            243,
            244
          ],
          "Patches": [
            "xsa245/*"
          ]
        }
      }
    },
    "4.6": {
      "XenVersion": "4.6",
      "Recipes": {
        "xen": {
          "StableRef": "1658a87690ac839e85db12bbf409be62bb938640",
          "Prereqs": [
            237,
            238,
            239,
            240,
            241,
            242,
            243,
            244
          ],
          "Patches": [
            "xsa245/*"
          ]
        }
      }
    },
    "4.7": {
      "XenVersion": "4.7",
      "Recipes": {
        "xen": {
          "StableRef": "c7783d9c26fc191862d9883da22387340b1fab18",
          "Prereqs": [
            237,
            238,
            239,
            240,
            241,
            242,
            243,
            244
          ],
          "Patches": [
            "xsa245/*"
          ]
        }
      }
    },
    "4.8": {
      "XenVersion": "4.8",
      "Recipes": {
        "xen": {
          "StableRef": "36898eb12572f0a1f85cb54d4a9e90afcb6f7045",
          "Prereqs": [
            237,
            238,
            239,
            240,
            241,
            242,
            243,
            244
          ],
          "Patches": [
            "xsa245/*"
          ]
        }
      }
    },
    "4.9": {
      "XenVersion": "4.9",
      "Recipes": {
        "xen": {
          "StableRef": "2cc3d32f40c71cb242477a3f8938074d4fc36829",
          "Prereqs": [
            237,
            238,
            239,
            240,
            241,
            242,
            243,
            244
          ],
          "Patches": [
            "xsa245/*"
          ]
        }
      }
    },
    "master": {
      "XenVersion": "master",
      "Recipes": {
        "xen": {
          "StableRef": "a8ea6e2688118a3e19e29b39e316faa5f96ab9d1",
          "Prereqs": [
            237,
            238,
            239,
            240,
            241,
            242,
            243,
            244
          ],
          "Patches": [
            "xsa245/*"
          ]
        }
      }
    }
  }
}

[-- Attachment #3: xsa245/0001-xen-page_alloc-Cover-memory-unreserved-after-boot-in.patch --]
[-- Type: application/octet-stream, Size: 1650 bytes --]

From a48d47febc1340f27d6c716545692641a09b414c Mon Sep 17 00:00:00 2001
From: Julien Grall <julien.grall@arm.com>
Date: Thu, 21 Sep 2017 14:13:08 +0100
Subject: [PATCH 1/2] xen/page_alloc: Cover memory unreserved after boot in
 first_valid_mfn

On Arm, some regions (e.g Initramfs, Dom0 Kernel...) are marked as
reserved until the hardware domain is built and they are copied into its
memory. Therefore, they will not be added in the boot allocator via
init_boot_pages.

Instead, init_xenheap_pages will be called once the region are not used
anymore.

Update first_valid_mfn in both init_heap_pages and init_boot_pages
(already exist) to cover all the cases.

Signed-off-by: Julien Grall <julien.grall@arm.com>
[Adjust comment, added locking around first_valid_mfn update]
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 xen/common/page_alloc.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 0b9f6cc6df..fbe5a8af39 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1700,6 +1700,16 @@ static void init_heap_pages(
 {
     unsigned long i;
 
+    /*
+     * Some pages may not go through the boot allocator (e.g reserved
+     * memory at boot but released just after --- kernel, initramfs,
+     * etc.).
+     * Update first_valid_mfn to ensure those regions are covered.
+     */
+    spin_lock(&heap_lock);
+    first_valid_mfn = min_t(unsigned long, page_to_mfn(pg), first_valid_mfn);
+    spin_unlock(&heap_lock);
+
     for ( i = 0; i < nr_pages; i++ )
     {
         unsigned int nid = phys_to_nid(page_to_maddr(pg+i));
-- 
2.11.0


[-- Attachment #4: xsa245/0002-xen-arm-Correctly-report-the-memory-region-in-the-du.patch --]
[-- Type: application/octet-stream, Size: 2600 bytes --]

From cbfcf039d0e0b6f4c4cb3de612f7bf788a0c47cd Mon Sep 17 00:00:00 2001
From: Julien Grall <julien.grall@arm.com>
Date: Mon, 18 Sep 2017 14:24:08 +0100
Subject: [PATCH 2/2] xen/arm: Correctly report the memory region in the dummy
 NUMA helpers

NUMA is currently not supported on Arm. Because common code is
NUMA-aware, dummy helpers are instead provided to expose a single node.

Those helpers are for instance used to know the region to scrub.

However the memory region is not reported correctly. Indeed, the
frametable may not be at the beginning of the memory and there might be
multiple memory banks. This will lead to not scrub some part of the
memory.

The memory information can be found using:
    * first_valid_mfn as the start of the memory
    * max_page - first_valid_mfn as the spanned pages

Note that first_valid_mfn is now been exported. The prototype has been
added in asm-arm/numa.h and not in a common header because I would
expect the variable to become static once NUMA is fully supported on
Arm.

Signed-off-by: Julien Grall <julien.grall@arm.com>
---
 xen/common/page_alloc.c    |  6 +++++-
 xen/include/asm-arm/numa.h | 10 ++++++++--
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index fbe5a8af39..472c6fe329 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -192,7 +192,11 @@ PAGE_LIST_HEAD(page_broken_list);
  * BOOT-TIME ALLOCATOR
  */
 
-static unsigned long __initdata first_valid_mfn = ~0UL;
+/*
+ * first_valid_mfn is exported because it is use in ARM specific NUMA
+ * helpers. See comment in asm-arm/numa.h.
+ */
+unsigned long first_valid_mfn = ~0UL;
 
 static struct bootmem_region {
     unsigned long s, e; /* MFNs @s through @e-1 inclusive are free */
diff --git a/xen/include/asm-arm/numa.h b/xen/include/asm-arm/numa.h
index a2c1a3476d..3e7384da9e 100644
--- a/xen/include/asm-arm/numa.h
+++ b/xen/include/asm-arm/numa.h
@@ -12,9 +12,15 @@ static inline __attribute__((pure)) nodeid_t phys_to_nid(paddr_t addr)
     return 0;
 }
 
+/*
+ * TODO: make first_valid_mfn static when NUMA is supported on Arm, this
+ * is required because the dummy helpers is using it.
+ */
+extern unsigned long first_valid_mfn;
+
 /* XXX: implement NUMA support */
-#define node_spanned_pages(nid) (total_pages)
-#define node_start_pfn(nid) (pdx_to_pfn(frametable_base_pdx))
+#define node_spanned_pages(nid) (max_page - first_valid_mfn)
+#define node_start_pfn(nid) (first_valid_mfn)
 #define __node_distance(a, b) (20)
 
 static inline unsigned int arch_get_dma_bitsize(void)
-- 
2.11.0


[-- Attachment #5: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 3+ messages in thread