Re: [Xen-devel] [PATCH 2/2] x86/svm: Write the correct %eip into the outgoing task

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 22/11/2019 14:31, Jan Beulich wrote:
> On 22.11.2019 14:55, Andrew Cooper wrote:
>> On 22/11/2019 13:31, Jan Beulich wrote:
>>> On 21.11.2019 23:15, Andrew Cooper wrote:
>>>> +        /* Fallthrough */
>>>> +    case 0x62: /* bound */
>>> Does "bound" really belong on this list? It raising #BR is like
>>> insns raising random other exceptions, not like INTO / INT3,
>>> where the IDT descriptor also has to have suitable DPL for the
>>> exception to actually get delivered (rather than #GP). I.e. it
>>> shouldn't make it here in the first place, due to the
>>> X86_EVENTTYPE_HW_EXCEPTION check in the caller.
>>>
>>> IOW if "bound" needs to be here, then all others need to be as
>>> well, unless they can't cause any exception at all.
>> More experimentation required.  BOUND doesn't appear to be special cased
>> by SVM, but is by VT-x.  VT-x however does throw it in the same category
>> as #UD, and identify it to be a hardware exception.
>>
>> I suspect you are right, and t doesn't want to be here.
>>
>>>> +    case 0x9a: /* call (far, absolute) */
>>>> +    case 0xca: /* ret imm16 (far) */
>>>> +    case 0xcb: /* ret (far) */
>>>> +    case 0xcc: /* int3 */
>>>> +    case 0xcd: /* int imm8 */
>>>> +    case 0xce: /* into */
>>>> +    case 0xcf: /* iret */
>>>> +    case 0xea: /* jmp (far, absolute) */
>>>> +    case 0xf1: /* icebp */
>>> Same perhaps for ICEBP, albeit I'm less certain here, as its
>>> behavior is too poorly documented (if at all).
>> ICEBP's #DB is a trap, not a fault, so instruction length is important.
> Hmm, this may point at a bigger issue then: Single step and data
> breakpoints are traps, too. But of course they can occur with
> arbitrary insns. Do their intercepts occur with guest RIP already
> updated?

Based on other behaviour, I'm going to guess yes on SVM and no on VT-x.

We'll take the #DB intercept, re-inject, and should see a vectoring task
switch.  The type should match the re-inject, so will be SW_INT/EXC with
a length on VT-x, and be HW_EXCEPTION with no length on SVM.

Either way, I think the logic presented here will work correctly.

> (They wouldn't currently make it here anyway because of
> the X86_EVENTTYPE_HW_EXCEPTION check in the caller.) If they do,
> are you sure ICEBP-#DB's doesn't?

ICEBP itself doesn't get intercepted.  Only the resulting #DB does,
which will will trigger a #DB-vectoring task switch, irrespective of its
exact origin.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel