All of lore.kernel.org
 help / color / mirror / Atom feed
* Xen Security Advisory 244 (CVE-2017-15594) - x86: Incorrect handling of IST settings during CPU hotplug
@ 2017-10-18 12:08 Xen.org security team
  0 siblings, 0 replies; only message in thread
From: Xen.org security team @ 2017-10-18 12:08 UTC (permalink / raw)
  To: xen-announce, xen-devel, xen-users, oss-security; +Cc: Xen.org security team

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

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

            Xen Security Advisory CVE-2017-15594 / XSA-244
                              version 3

      x86: Incorrect handling of IST settings during CPU hotplug

UPDATES IN VERSION 3
====================

CVE assigned.

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

The x86-64 architecture allows interrupts to be run on distinct stacks.
The choice of stack is encoded in a field of the corresponding
interrupt descriptor in the Interrupt Descriptor Table (IDT).  That
field selects an entry from the active Task State Segment (TSS).

Since, on AMD hardware, Xen switches to an HVM guest's TSS before
actually entering the guest, with the Global Interrupt Flag still set,
the selectors in the IDT entry are switched when guest context is
loaded/unloaded.

When a new CPU is brought online, its IDT is copied from CPU0's IDT,
including those selector fields.  If CPU0 happens at that moment to be
in HVM context, wrong values for those IDT fields would be installed
for the new CPU.  If the first guest vCPU to be run on that CPU
belongs to a PV guest, it will then have the ability to escalate its
privilege or crash the hypervisor.

IMPACT
======

A malicious or buggy x86 PV guest could escalate its privileges or
crash the hypervisor.

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

All Xen versions from at least 3.2 onwards are vulnerable.  Earlier
versions have not been checked.

Only PV guests can exploit the vulnerability.  HVM guests cannot
exploit the vulnerability, but their presence is necessary for the
exposure of the vulnerability to PV guests.

Only x86 systems using SVM (AMD virtualisation extensions) rather than
VMX (Intel virtualisation extensions) are vulnerable.  Therefore AMD
x86 hardware is vulnerable; Intel hardware is not vulnerable.

ARM systems are not vulnerable.

MITIGATION
==========

Avoiding to online CPUs at runtime will avoid this vulnerability.

Running only HVM or only PV guests on any individual host will also
avoid this vulnerability.

CREDITS
=======

This issue was discovered by Andrew Cooper of Citrix.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa244.patch           xen-unstable, Xen 4.9.x, Xen 4.8.x
xsa244-4.7.patch       Xen 4.7.x
xsa244-4.6.patch       Xen 4.6.x
xsa244-4.5.patch       Xen 4.5.x

$ sha256sum xsa244*
5b663620a1b0d5f07e7ae4d1d3506d925515d5f85830ca49dda75cab1218506f  xsa244.meta
bcf22b332bf3f6fe8c86e4de67f82628c9b8e257d9513c3bf5c7f5dd71d86c33  xsa244.patch
4c4543fdfd25b4a8ea7d53f3f45011ec137798e7d4e690d8f3ea58d77afb5f06  xsa244-4.5.patch
eaa3ba303980d783813db7aee948a9cb2723328da5fa5650ffca7b825c21bab6  xsa244-4.6.patch
4d8cf754f760ef05488e9fb25a7ebd9a7e46f3742e91eee1a8385fd1e611ea8c  xsa244-4.7.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJZ50QqAAoJEIP+FMlX6CvZmsEIAKuPA1/ly1Hgf9vZCkbKauO/
df8JgVdLemcGSEfDwzVlRjHQh0QtpMLNG5RCYRD+s8hrCotKc8dC95+pIztDY/l+
lw6k9bCFup7hI++IdL/fmy79RS+WUOinMEOwD39zqFVK+y6J2M0iXnuKqxtF+j/7
zWVmzdZIHbM+6DlRr1uN0jpirqkJ8P5yNMBgqhp4zH4efOe0Olv+0SQtNtNclCib
MR4ipBbkK9sCMN6odZCbnwKkn2zyCDSfPiXnINfiIbsUweCf9n6MEpry8Kiae90Z
BFn+KGkRcC9gQkoKRoF/rDwG02P6KCb34pNY0nVgxtr4pDYqJzhEh7+eGXfVHME=
=dk0t
-----END PGP SIGNATURE-----

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

{
  "XSA": 244,
  "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
          ],
          "Patches": [
            "xsa244-4.5.patch"
          ]
        }
      }
    },
    "4.6": {
      "XenVersion": "4.6",
      "Recipes": {
        "xen": {
          "StableRef": "1658a87690ac839e85db12bbf409be62bb938640",
          "Prereqs": [
            237,
            238,
            239,
            240,
            241,
            242,
            243
          ],
          "Patches": [
            "xsa244-4.6.patch"
          ]
        }
      }
    },
    "4.7": {
      "XenVersion": "4.7",
      "Recipes": {
        "xen": {
          "StableRef": "c7783d9c26fc191862d9883da22387340b1fab18",
          "Prereqs": [
            237,
            238,
            239,
            240,
            241,
            242,
            243
          ],
          "Patches": [
            "xsa244-4.7.patch"
          ]
        }
      }
    },
    "4.8": {
      "XenVersion": "4.8",
      "Recipes": {
        "xen": {
          "StableRef": "36898eb12572f0a1f85cb54d4a9e90afcb6f7045",
          "Prereqs": [
            237,
            238,
            239,
            240,
            241,
            242,
            243
          ],
          "Patches": [
            "xsa244.patch"
          ]
        }
      }
    },
    "4.9": {
      "XenVersion": "4.9",
      "Recipes": {
        "xen": {
          "StableRef": "2cc3d32f40c71cb242477a3f8938074d4fc36829",
          "Prereqs": [
            237,
            238,
            239,
            240,
            241,
            242,
            243
          ],
          "Patches": [
            "xsa244.patch"
          ]
        }
      }
    },
    "master": {
      "XenVersion": "master",
      "Recipes": {
        "xen": {
          "StableRef": "a8ea6e2688118a3e19e29b39e316faa5f96ab9d1",
          "Prereqs": [
            237,
            238,
            239,
            240,
            241,
            242,
            243
          ],
          "Patches": [
            "xsa244.patch"
          ]
        }
      }
    }
  }
}

[-- Attachment #3: xsa244.patch --]
[-- Type: application/octet-stream, Size: 2366 bytes --]

From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH] x86/cpu: Fix IST handling during PCPU bringup

Clear IST references in newly allocated IDTs.  Nothing good will come of
having them set before the TSS is suitably constructed (although the chances
of the CPU surviving such an IST interrupt/exception is extremely slim).

Uniformly set the IST references after the TSS is in place.  This fixes an
issue on AMD hardware, where onlining a PCPU while PCPU0 is in HVM context
will cause IST_NONE to be copied into the new IDT, making that PCPU vulnerable
to privilege escalation from PV guests until it subsequently schedules an HVM
guest.

This is XSA-244

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/cpu/common.c | 5 +++++
 xen/arch/x86/smpboot.c    | 3 +++
 2 files changed, 8 insertions(+)

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 78f5667..6cf3628 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -640,6 +640,7 @@ void __init early_cpu_init(void)
  * - Sets up TSS with stack pointers, including ISTs
  * - Inserts TSS selector into regular and compat GDTs
  * - Loads GDT, IDT, TR then null LDT
+ * - Sets up IST references in the IDT
  */
 void load_system_tables(void)
 {
@@ -702,6 +703,10 @@ void load_system_tables(void)
 	asm volatile ("ltr  %w0" : : "rm" (TSS_ENTRY << 3) );
 	asm volatile ("lldt %w0" : : "rm" (0) );
 
+	set_ist(&idt_tables[cpu][TRAP_double_fault],  IST_DF);
+	set_ist(&idt_tables[cpu][TRAP_nmi],	      IST_NMI);
+	set_ist(&idt_tables[cpu][TRAP_machine_check], IST_MCE);
+
 	/*
 	 * Bottom-of-stack must be 16-byte aligned!
 	 *
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 3ca716c..1609b62 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -724,6 +724,9 @@ static int cpu_smpboot_alloc(unsigned int cpu)
     if ( idt_tables[cpu] == NULL )
         goto oom;
     memcpy(idt_tables[cpu], idt_table, IDT_ENTRIES * sizeof(idt_entry_t));
+    set_ist(&idt_tables[cpu][TRAP_double_fault],  IST_NONE);
+    set_ist(&idt_tables[cpu][TRAP_nmi],           IST_NONE);
+    set_ist(&idt_tables[cpu][TRAP_machine_check], IST_NONE);
 
     for ( stub_page = 0, i = cpu & ~(STUBS_PER_PAGE - 1);
           i < nr_cpu_ids && i <= (cpu | (STUBS_PER_PAGE - 1)); ++i )

[-- Attachment #4: xsa244-4.5.patch --]
[-- Type: application/octet-stream, Size: 2069 bytes --]

From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: x86/cpu: fix IST handling during PCPU bringup

Clear IST references in newly allocated IDTs.  Nothing good will come of
having them set before the TSS is suitably constructed (although the chances
of the CPU surviving such an IST interrupt/exception is extremely slim).

Uniformly set the IST references after the TSS is in place.  This fixes an
issue on AMD hardware, where onlining a PCPU while PCPU0 is in HVM context
will cause IST_NONE to be copied into the new IDT, making that PCPU vulnerable
to privilege escalation from PV guests until it subsequently schedules an HVM
guest.

This is XSA-244.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -556,6 +556,7 @@ void __init early_cpu_init(void)
  * - Sets up TSS with stack pointers, including ISTs
  * - Inserts TSS selector into regular and compat GDTs
  * - Loads GDT, IDT, TR then null LDT
+ * - Sets up IST references in the IDT
  */
 void __cpuinit load_system_tables(void)
 {
@@ -602,6 +603,10 @@ void __cpuinit load_system_tables(void)
 	asm volatile ("lidt %0"  : : "m"  (idtr) );
 	asm volatile ("ltr  %w0" : : "rm" (TSS_ENTRY << 3) );
 	asm volatile ("lldt %w0" : : "rm" (0) );
+
+	set_ist(&idt_tables[cpu][TRAP_double_fault],  IST_DF);
+	set_ist(&idt_tables[cpu][TRAP_nmi],	      IST_NMI);
+	set_ist(&idt_tables[cpu][TRAP_machine_check], IST_MCE);
 }
 
 /*
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -664,6 +664,9 @@ static int cpu_smpboot_alloc(unsigned in
     if ( idt_tables[cpu] == NULL )
         goto oom;
     memcpy(idt_tables[cpu], idt_table, IDT_ENTRIES * sizeof(idt_entry_t));
+    set_ist(&idt_tables[cpu][TRAP_double_fault],  IST_NONE);
+    set_ist(&idt_tables[cpu][TRAP_nmi],           IST_NONE);
+    set_ist(&idt_tables[cpu][TRAP_machine_check], IST_NONE);
 
     if ( zalloc_cpumask_var(&per_cpu(cpu_sibling_mask, cpu)) &&
          zalloc_cpumask_var(&per_cpu(cpu_core_mask, cpu)) )

[-- Attachment #5: xsa244-4.6.patch --]
[-- Type: application/octet-stream, Size: 2072 bytes --]

From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: x86/cpu: fix IST handling during PCPU bringup

Clear IST references in newly allocated IDTs.  Nothing good will come of
having them set before the TSS is suitably constructed (although the chances
of the CPU surviving such an IST interrupt/exception is extremely slim).

Uniformly set the IST references after the TSS is in place.  This fixes an
issue on AMD hardware, where onlining a PCPU while PCPU0 is in HVM context
will cause IST_NONE to be copied into the new IDT, making that PCPU vulnerable
to privilege escalation from PV guests until it subsequently schedules an HVM
guest.

This is XSA-244.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -558,6 +558,7 @@ void __init early_cpu_init(void)
  * - Sets up TSS with stack pointers, including ISTs
  * - Inserts TSS selector into regular and compat GDTs
  * - Loads GDT, IDT, TR then null LDT
+ * - Sets up IST references in the IDT
  */
 void __cpuinit load_system_tables(void)
 {
@@ -604,6 +605,10 @@ void __cpuinit load_system_tables(void)
 	asm volatile ("lidt %0"  : : "m"  (idtr) );
 	asm volatile ("ltr  %w0" : : "rm" (TSS_ENTRY << 3) );
 	asm volatile ("lldt %w0" : : "rm" (0) );
+
+	set_ist(&idt_tables[cpu][TRAP_double_fault],  IST_DF);
+	set_ist(&idt_tables[cpu][TRAP_nmi],	      IST_NMI);
+	set_ist(&idt_tables[cpu][TRAP_machine_check], IST_MCE);
 }
 
 /*
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -749,6 +749,9 @@ static int cpu_smpboot_alloc(unsigned in
     if ( idt_tables[cpu] == NULL )
         goto oom;
     memcpy(idt_tables[cpu], idt_table, IDT_ENTRIES * sizeof(idt_entry_t));
+    set_ist(&idt_tables[cpu][TRAP_double_fault],  IST_NONE);
+    set_ist(&idt_tables[cpu][TRAP_nmi],           IST_NONE);
+    set_ist(&idt_tables[cpu][TRAP_machine_check], IST_NONE);
 
     for ( stub_page = 0, i = cpu & ~(STUBS_PER_PAGE - 1);
           i < nr_cpu_ids && i <= (cpu | (STUBS_PER_PAGE - 1)); ++i )

[-- Attachment #6: xsa244-4.7.patch --]
[-- Type: application/octet-stream, Size: 2052 bytes --]

From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: x86/cpu: fix IST handling during PCPU bringup

Clear IST references in newly allocated IDTs.  Nothing good will come of
having them set before the TSS is suitably constructed (although the chances
of the CPU surviving such an IST interrupt/exception is extremely slim).

Uniformly set the IST references after the TSS is in place.  This fixes an
issue on AMD hardware, where onlining a PCPU while PCPU0 is in HVM context
will cause IST_NONE to be copied into the new IDT, making that PCPU vulnerable
to privilege escalation from PV guests until it subsequently schedules an HVM
guest.

This is XSA-244.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -617,6 +617,7 @@ void __init early_cpu_init(void)
  * - Sets up TSS with stack pointers, including ISTs
  * - Inserts TSS selector into regular and compat GDTs
  * - Loads GDT, IDT, TR then null LDT
+ * - Sets up IST references in the IDT
  */
 void load_system_tables(void)
 {
@@ -663,6 +664,10 @@ void load_system_tables(void)
 	asm volatile ("lidt %0"  : : "m"  (idtr) );
 	asm volatile ("ltr  %w0" : : "rm" (TSS_ENTRY << 3) );
 	asm volatile ("lldt %w0" : : "rm" (0) );
+
+	set_ist(&idt_tables[cpu][TRAP_double_fault],  IST_DF);
+	set_ist(&idt_tables[cpu][TRAP_nmi],	      IST_NMI);
+	set_ist(&idt_tables[cpu][TRAP_machine_check], IST_MCE);
 }
 
 /*
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -715,6 +715,9 @@ static int cpu_smpboot_alloc(unsigned in
     if ( idt_tables[cpu] == NULL )
         goto oom;
     memcpy(idt_tables[cpu], idt_table, IDT_ENTRIES * sizeof(idt_entry_t));
+    set_ist(&idt_tables[cpu][TRAP_double_fault],  IST_NONE);
+    set_ist(&idt_tables[cpu][TRAP_nmi],           IST_NONE);
+    set_ist(&idt_tables[cpu][TRAP_machine_check], IST_NONE);
 
     for ( stub_page = 0, i = cpu & ~(STUBS_PER_PAGE - 1);
           i < nr_cpu_ids && i <= (cpu | (STUBS_PER_PAGE - 1)); ++i )

[-- Attachment #7: Type: text/plain, Size: 127 bytes --]

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

^ permalink raw reply related	[flat|nested] only message in thread

only message in thread, other threads:[~2017-10-18 12:08 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-18 12:08 Xen Security Advisory 244 (CVE-2017-15594) - x86: Incorrect handling of IST settings during CPU hotplug Xen.org security team

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.