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

[Jan Beulich <jbeulich@xxxxxxxx>]

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? (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?

Jan

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