Sign Up
Log In
Log In
or
Sign Up
Places
All Projects
Status Monitor
Collapse sidebar
No build reason found for config:s390x
SUSE:SLE-15-SP1:GA
xen.15298
xsa308.patch
Overview
Repositories
Revisions
Requests
Users
Attributes
Meta
File xsa308.patch of Package xen.15298
From: Andrew Cooper <andrew.cooper3@citrix.com> Subject: x86/vtx: Work around SingleStep + STI/MovSS VMEntry failures See patch comment for technical details. Concerning the timeline, this was first discovered in the aftermath of XSA-156 which caused #DB to be intercepted unconditionally, but only in its SingleStep + STI form which is restricted to privileged software. After working with Intel and identifying the problematic vmentry check, this workaround was suggested, and the patch was posted in an RFC series. Outstanding work for that series (not breaking Introspection) is still pending, and this fix from it (which wouldn't have been good enough in its original form) wasn't committed. A vmentry failure was reported to xen-devel, and debugging identified this bug in its SingleStep + MovSS form by way of INT1, which does not involve the use of any privileged instructions, and proving this to be a security issue. This is XSA-308 Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Kevin Tian <kevin.tian@intel.com> --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -3920,6 +3920,42 @@ void vmx_vmexit_handler(struct cpu_user_ HVMTRACE_1D(TRAP_DEBUG, exit_qualification); __restore_debug_registers(v); write_debugreg(6, exit_qualification | DR_STATUS_RESERVED_ONE); + + /* + * Work around SingleStep + STI/MovSS VMEntry failures. + * + * We intercept #DB unconditionally to work around CVE-2015-8104 / + * XSA-156 (guest-kernel induced host DoS). + * + * STI/MovSS shadows block/defer interrupts/exceptions (exact + * details are complicated and poorly documented). Debug + * exceptions delayed for any reason are stored in the + * PENDING_DBG_EXCEPTIONS field. + * + * The falling edge of PENDING_DBG causes #DB to be delivered, + * resulting in a VMExit, as #DB is intercepted. The VMCS still + * reports blocked-by-STI/MovSS. + * + * The VMEntry checks when EFLAGS.TF is set don't like a VMCS in + * this state. Despite a #DB queued in VMENTRY_INTR_INFO, the + * state is rejected as DR6.BS isn't pending. Fix this up. + */ + if ( unlikely(regs->eflags & X86_EFLAGS_TF) ) + { + unsigned long int_info; + + __vmread(GUEST_INTERRUPTIBILITY_INFO, &int_info); + + if ( int_info & (VMX_INTR_SHADOW_STI | VMX_INTR_SHADOW_MOV_SS) ) + { + unsigned long pending_dbg; + + __vmread(GUEST_PENDING_DBG_EXCEPTIONS, &pending_dbg); + __vmwrite(GUEST_PENDING_DBG_EXCEPTIONS, + pending_dbg | DR_STEP); + } + } + if ( !v->domain->debugger_attached ) { unsigned long insn_len = 0;
Locations
Projects
Search
Status Monitor
Help
OpenBuildService.org
Documentation
API Documentation
Code of Conduct
Contact
Support
@OBShq
Terms
openSUSE Build Service is sponsored by
The Open Build Service is an
openSUSE project
.
Sign Up
Log In
Places
Places
All Projects
Status Monitor