From d6371ccb93012db4ad6615fe666205b86308cb4e Mon Sep 17 00:00:00 2001 From: Andrew Cooper Date: Wed, 18 Jul 2018 12:22:55 +0100 Subject: [PATCH] x86/xstate: Make errors in xstate calculations more obvious by crashing the domain If xcr0_max exceeds xfeature_mask, then something is broken with the CPUID policy derivation or auditing logic. If hardware rejects new_bv, then something is broken with Xen's xstate logic. In both cases, crash the domain with an obvious error message, to help highlight the issues. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- xen/arch/x86/xstate.c | 26 +++++++++++++++++++++++--- 1 file changed, 23 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c index 1fbb0871d0..c8197d2e40 100644 --- a/xen/arch/x86/xstate.c +++ b/xen/arch/x86/xstate.c @@ -707,12 +707,32 @@ int handle_xsetbv(u32 index, u64 new_bv) if ( index != XCR_XFEATURE_ENABLED_MASK ) return -EOPNOTSUPP; - if ( (new_bv & ~xcr0_max) || - (new_bv & ~xfeature_mask) || !valid_xcr0(new_bv) ) + /* + * The CPUID logic shouldn't be able to hand out an XCR0 exceeding Xen's + * maximum features, but keep the check for robustness. + */ + if ( unlikely(xcr0_max & ~xfeature_mask) ) + { + gprintk(XENLOG_ERR, + "xcr0_max %016" PRIx64 " exceeds hardware max %016" PRIx64 "\n", + new_bv, xfeature_mask); + domain_crash(curr->domain); + + return -EINVAL; + } + + if ( (new_bv & ~xcr0_max) || !valid_xcr0(new_bv) ) return -EINVAL; - if ( !set_xcr0(new_bv) ) + /* By this point, new_bv really should be accepted by hardware. */ + if ( unlikely(!set_xcr0(new_bv)) ) + { + gprintk(XENLOG_ERR, "new_bv %016" PRIx64 " rejected by hardware\n", + new_bv); + domain_crash(curr->domain); + return -EFAULT; + } mask = new_bv & ~curr->arch.xcr0_accum; curr->arch.xcr0 = new_bv; -- 2.39.5