[XSA-156] x86: CPU lockup during exception delivery

ISSUE DESCRIPTION

When a benign exception occurs while delivering another benign
exception, it is architecturally specified that these would be
delivered sequentially. There are, however, cases where this results in
an infinite loop inside the CPU, which (in the virtualized case) can be
broken only by intercepting delivery of the respective exception.

Architecturally, at least some of these cases should also be
resolvable by an arriving NMI or external interrupt, but empirically
this has been determined to not be the case.

The cases affecting Xen are:

#AC (Alignment Check Exception, CVE-2015-5307): When a 32-bit guest
sets up the IDT entry corresponding to this exception to reference a
ring-3 handler, and when ring 3 code triggers the exception while
running with an unaligned stack pointer, delivering the exception will
re-encounter #AC, ending in an infinite loop.

#DB (Debug Exception, CVE-2015-8104): When a guest sets up a hardware
breakpoint covering a data structure involved in delivering #DB, upon
completion of the delivery of the first exception another #DB will
need to be delivered. The effects slightly differ depending on further
guest characteristics:

• • Guests running in 32-bit mode would be expected to sooner or later encounter another fault due to the stack pointer decreasing during each iteration of the loop. The most likely case would be #PF (Page Fault) due to running into unmapped virtual space. However, an infinite loop cannot be excluded (e.g. when the guest is running with paging disabled).
• • Guests running in long mode, but not using the IST (Interrupt Stack Table) feature for the IDT entry corresponding to #DB would behave similarly to guests running in 32-bit mode, just that the larger virtual address space allows for a much longer loop. The loop can't, however, be infinite, as eventually the stack pointer would move into non-canonical address space, causing #SS (Stack Fault) instead.
• • Guests running in long mode and using IST for the IDT entry corresponding to #DB would enter an infinite loop, as the stack pointer wouldn't change between #DB instances.

IMPACT

A malicious HVM guest administrator can cause a denial of service.
Specifically, prevent use of a physical CPU for a significant, perhaps
indefinite period.

If a host watchdog (Xen or dom0) is in use, this can lead to a
watchdog timeout and consequently a reboot of the host. If another,
innocent, guest, is configured with a watchdog, this issue can lead to
a reboot of such a guest.

It is possible that a guest kernel might expose the #AC vulnerability
to malicious unprivileged guest users (by permitting #AC to be handled
in guest user mode). However, we believe that almost all ordinary
operating system kernels do not permit this; we are not aware of any
exceptions. (A guest kernel which exposed the #AC vulnerability to
guest userspace would be vulnerable when running on baremetal, without
Xen involved.)

VULNERABLE SYSTEMS

The vulnerability is exposed to any x86 HVM guest.

ARM is not vulnerable. x86 PV VMs are not vulnerable.

All versions of Xen are affected.

x86 CPUs from all manufacturers are affected.