Re: [PATCH] x86/HVM: correct notion of new CPL in task switch emulation

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 02/06/17 21:02, Andrew Cooper wrote:
> On 01/06/17 13:11, Jan Beulich wrote:
>> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> I have finally managed to reproduce the original vmentry failure with an
> XTF test.

FWIW, the vmentry failure is quite subtle.

%es gets reloaded first.  If the new TSS uses RPL0 data selectors, the
load fails, and #TS[%es] is yielded.

(d3) Going to userspace
(XEN) ** d3v0 Inject event { v 0x02, t 2, ec ffffffff }
(XEN) ** d3v0 Inject event { v 0x0a, t 3, ec 0018 }
(XEN) ** d3v0 Inject event { v 0x0a, t 3, ec 0018 }
(XEN) d3v0 Triple fault - invoking HVM shutdown action 1
(XEN) *** Dumping Dom3 vcpu#0 state: ***
(XEN) ----[ Xen-4.10-unstable  x86_64  debug=y   Tainted:    H ]----

For some reason I haven't gotten to the bottom of yet, end up calling
__vmx_inject_exception() twice while handling the task switch path.  We
shouldn't be.

If however the TSS uses RPL3 data selectors, the %es load succeeds, then
the %cs load succeeds (rpl is 0 as this is an external interrupt
delivery).  The %ss load then fails because the old dpl is 3 (being in
userspace) but the new dpl is 0.  This then yields #TS[%ss], but the
VMCS is in a state with %cs and %ss disagreeing.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel