From: Andrew Cooper Date: Wed, 18 Jul 2018 11:22:55 +0000 (+0100) Subject: x86/xstate: Make errors in xstate calculations more obvious by crashing the domain X-Git-Tag: archive/raspbian/4.14.0+80-gd101b417b7-1+rpi1^2~63^2~3567 X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=d6371ccb93012db4ad6615fe666205b86308cb4e;p=xen.git 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 --- 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;