]> xenbits.xensource.com Git - xen.git/commit
x86/xstate: Use a guests CPUID policy, rather than allowing all features
authorAndrew Cooper <andrew.cooper3@citrix.com>
Mon, 30 Jul 2018 10:09:18 +0000 (12:09 +0200)
committerJan Beulich <jbeulich@suse.com>
Mon, 30 Jul 2018 10:09:18 +0000 (12:09 +0200)
commite343ee80bee451ce0ce49f5570a834533bb18036
tree99065c9256800f99a3d0fb46a0cf867a29a2dec2
parent5566272d5ac148da962e14bc045ce23b22f38bbc
x86/xstate: Use a guests CPUID policy, rather than allowing all features

It turns out that Xen has never enforced that a domain remain within the
xstate features advertised in CPUID.

The check of new_bv against xfeature_mask ensures that a domain stays within
the set of features that Xen has enabled in hardware (and therefore isn't a
security problem), but this does means that attempts to level a guest for
migration safety might not be effective if the guest ignores CPUID.

Check the CPUID policy in validate_xstate() (for incoming migration) and in
handle_xsetbv() (for guest XSETBV instructions).  This subsumes the PKRU check
for PV guests in handle_xsetbv() (and also demonstrates that I should have
spotted this problem while reviewing c/s fbf9971241f).

For migration, this is correct despite the current (mis)ordering of data
because d->arch.cpuid is the applicable max policy.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 361b835fa00d9f45167c50a60e054ccf22c065d7
master date: 2018-07-19 19:57:26 +0100
xen/arch/x86/domctl.c
xen/arch/x86/hvm/hvm.c
xen/arch/x86/xstate.c
xen/include/asm-x86/xstate.h