x86/shadow: correct SH_LINEAR mapping detection in sh_guess_wrmap()
authorAndrew Cooper <andrew.cooper3@citrix.com>
Thu, 16 Nov 2017 09:38:14 +0000 (10:38 +0100)
committerJan Beulich <jbeulich@suse.com>
Thu, 16 Nov 2017 09:38:14 +0000 (10:38 +0100)
commitd20daf4294adbdb9316850566013edb98db7bfbc
treee45c7b6c7a84a9e475eedafc77c80c12c54fc45f
parent2c458dfcb59f3d9d8a35fc5ffbf780b6ed7a26a6
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>
xen/arch/x86/mm/shadow/multi.c