Re: [Xen-devel] [PATCH v3 2/4] hvm/svm: Enable Breakpoint events
On Mi, 2018-02-14 at 19:11 +, Andrew Cooper wrote: > On 14/02/18 18:22, Andrew Cooper wrote: > > > > On 14/02/18 16:10, Alexandru Stefan ISAILA wrote: > > > > > > On Lu, 2018-02-12 at 15:54 +, Andrew Cooper wrote: > > > > > > > > On 12/02/18 15:08, Alexandru Isaila wrote: > > > > > > > > > > @@ -2619,14 +2634,31 @@ void svm_vmexit_handler(struct > > > > > cpu_user_regs *regs) > > > > > break; > > > > > > > > > > case VMEXIT_EXCEPTION_BP: > > > > > -if ( !v->domain->debugger_attached ) > > > > > -goto unexpected_exit_type; > > > > > -/* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do > > > > > not > > > > > update RIP. */ > > > > > -if ( (inst_len = __get_instruction_length(v, > > > > > INSTR_INT3)) > > > > > == 0 ) > > > > > +inst_len = __get_instruction_length(v, INSTR_INT3); > > > > There are multiple ways of ending up with this vmexit, and INT3 > > > > is > > > > not > > > > the only way. > > > > > > > > The old code was somewhat broken (but only in the case that a > > > > debugger > > > > was attached), but now with this introspection hook active, > > > > executing > > > > `0xcd 0x03` will end up crashing the domain because of a length > > > > mismatch > > > > looking for 0xcc. > > > > > > > > You need to inspect EXITINTINFO to work out what went on here, > > > > and > > > > distinguish INT3 from INT $3. > > > > > > > > Can I suggest that you run this unit test > > > > http://xenbits.xen.org/docs/xtf/test-swint-emulation.html under > > > > debug > > > > introspection an check that you get all expected events? Every > > > > time > > > > we > > > > touch this code, we seem to break it :( > > > > > > > > ~Andrew > > > > > > > I've tested on Intel and AMD and I only get events on int3. > > > Further > > > more, I don't think there is any way to use the vmcb->exitintinfo > > > because all the fields are 0 on the time of VMEXIT_EXCEPTION_BP. > > > Did I > > > understand the test scenario correctly? > > Quite possibly, but now I'm even more confused. I'll have a quick > > play. > Ok - after some investigation, executing `int $3` triggers > VMEXIT_SWINT, > with the vector in EXITINFO1, as opposed to triggering VMEXIT_EXCP3, > except that we don't have INTERCEPT_SWINT active, so it completes > internally. > > Therefore, in your patch, we do expect only ever to find an int3 > triggering VMEXIT_EXCEPTION_BP. Sorry for the noise. > > However, do you mind rebasing the remainder of your series onto > staging? It doesn't apply cleanly any more. > > ~Andrew > Nice to hear that. Ok, I will re base to staging and address your other comments as well. Alex This email was scanned by Bitdefender ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/4] hvm/svm: Enable Breakpoint events
On 14/02/18 18:22, Andrew Cooper wrote: > On 14/02/18 16:10, Alexandru Stefan ISAILA wrote: >> On Lu, 2018-02-12 at 15:54 +, Andrew Cooper wrote: >>> On 12/02/18 15:08, Alexandru Isaila wrote: @@ -2619,14 +2634,31 @@ void svm_vmexit_handler(struct cpu_user_regs *regs) break; case VMEXIT_EXCEPTION_BP: -if ( !v->domain->debugger_attached ) -goto unexpected_exit_type; -/* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not update RIP. */ -if ( (inst_len = __get_instruction_length(v, INSTR_INT3)) == 0 ) +inst_len = __get_instruction_length(v, INSTR_INT3); >>> There are multiple ways of ending up with this vmexit, and INT3 is >>> not >>> the only way. >>> >>> The old code was somewhat broken (but only in the case that a >>> debugger >>> was attached), but now with this introspection hook active, >>> executing >>> `0xcd 0x03` will end up crashing the domain because of a length >>> mismatch >>> looking for 0xcc. >>> >>> You need to inspect EXITINTINFO to work out what went on here, and >>> distinguish INT3 from INT $3. >>> >>> Can I suggest that you run this unit test >>> http://xenbits.xen.org/docs/xtf/test-swint-emulation.html under debug >>> introspection an check that you get all expected events? Every time >>> we >>> touch this code, we seem to break it :( >>> >>> ~Andrew >>> >> I've tested on Intel and AMD and I only get events on int3. Further >> more, I don't think there is any way to use the vmcb->exitintinfo >> because all the fields are 0 on the time of VMEXIT_EXCEPTION_BP. Did I >> understand the test scenario correctly? > Quite possibly, but now I'm even more confused. I'll have a quick play. Ok - after some investigation, executing `int $3` triggers VMEXIT_SWINT, with the vector in EXITINFO1, as opposed to triggering VMEXIT_EXCP3, except that we don't have INTERCEPT_SWINT active, so it completes internally. Therefore, in your patch, we do expect only ever to find an int3 triggering VMEXIT_EXCEPTION_BP. Sorry for the noise. However, do you mind rebasing the remainder of your series onto staging? It doesn't apply cleanly any more. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/4] hvm/svm: Enable Breakpoint events
On 14/02/18 16:10, Alexandru Stefan ISAILA wrote: > On Lu, 2018-02-12 at 15:54 +, Andrew Cooper wrote: >> On 12/02/18 15:08, Alexandru Isaila wrote: >>> @@ -2619,14 +2634,31 @@ void svm_vmexit_handler(struct >>> cpu_user_regs *regs) >>> break; >>> >>> case VMEXIT_EXCEPTION_BP: >>> -if ( !v->domain->debugger_attached ) >>> -goto unexpected_exit_type; >>> -/* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not >>> update RIP. */ >>> -if ( (inst_len = __get_instruction_length(v, INSTR_INT3)) >>> == 0 ) >>> +inst_len = __get_instruction_length(v, INSTR_INT3); >> There are multiple ways of ending up with this vmexit, and INT3 is >> not >> the only way. >> >> The old code was somewhat broken (but only in the case that a >> debugger >> was attached), but now with this introspection hook active, >> executing >> `0xcd 0x03` will end up crashing the domain because of a length >> mismatch >> looking for 0xcc. >> >> You need to inspect EXITINTINFO to work out what went on here, and >> distinguish INT3 from INT $3. >> >> Can I suggest that you run this unit test >> http://xenbits.xen.org/docs/xtf/test-swint-emulation.html under debug >> introspection an check that you get all expected events? Every time >> we >> touch this code, we seem to break it :( >> >> ~Andrew >> > I've tested on Intel and AMD and I only get events on int3. Further > more, I don't think there is any way to use the vmcb->exitintinfo > because all the fields are 0 on the time of VMEXIT_EXCEPTION_BP. Did I > understand the test scenario correctly? Quite possibly, but now I'm even more confused. I'll have a quick play. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/4] hvm/svm: Enable Breakpoint events
On Lu, 2018-02-12 at 15:54 +, Andrew Cooper wrote: > On 12/02/18 15:08, Alexandru Isaila wrote: > > > > @@ -2619,14 +2634,31 @@ void svm_vmexit_handler(struct > > cpu_user_regs *regs) > > break; > > > > case VMEXIT_EXCEPTION_BP: > > -if ( !v->domain->debugger_attached ) > > -goto unexpected_exit_type; > > -/* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not > > update RIP. */ > > -if ( (inst_len = __get_instruction_length(v, INSTR_INT3)) > > == 0 ) > > +inst_len = __get_instruction_length(v, INSTR_INT3); > There are multiple ways of ending up with this vmexit, and INT3 is > not > the only way. > > The old code was somewhat broken (but only in the case that a > debugger > was attached), but now with this introspection hook active, > executing > `0xcd 0x03` will end up crashing the domain because of a length > mismatch > looking for 0xcc. > > You need to inspect EXITINTINFO to work out what went on here, and > distinguish INT3 from INT $3. > > Can I suggest that you run this unit test > http://xenbits.xen.org/docs/xtf/test-swint-emulation.html under debug > introspection an check that you get all expected events? Every time > we > touch this code, we seem to break it :( > > ~Andrew > I've tested on Intel and AMD and I only get events on int3. Further more, I don't think there is any way to use the vmcb->exitintinfo because all the fields are 0 on the time of VMEXIT_EXCEPTION_BP. Did I understand the test scenario correctly? Thanks, Alex This email was scanned by Bitdefender ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/4] hvm/svm: Enable Breakpoint events
On Mon, Feb 12, 2018 at 8:54 AM, Andrew Cooperwrote: > On 12/02/18 15:08, Alexandru Isaila wrote: >> @@ -2619,14 +2634,31 @@ void svm_vmexit_handler(struct cpu_user_regs *regs) >> break; >> >> case VMEXIT_EXCEPTION_BP: >> -if ( !v->domain->debugger_attached ) >> -goto unexpected_exit_type; >> -/* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not update RIP. >> */ >> -if ( (inst_len = __get_instruction_length(v, INSTR_INT3)) == 0 ) >> +inst_len = __get_instruction_length(v, INSTR_INT3); > > There are multiple ways of ending up with this vmexit, and INT3 is not > the only way. > > The old code was somewhat broken (but only in the case that a debugger > was attached), but now with this introspection hook active, executing > `0xcd 0x03` will end up crashing the domain because of a length mismatch > looking for 0xcc. > > You need to inspect EXITINTINFO to work out what went on here, and > distinguish INT3 from INT $3. > > Can I suggest that you run this unit test > http://xenbits.xen.org/docs/xtf/test-swint-emulation.html under debug > introspection an check that you get all expected events? Every time we > touch this code, we seem to break it :( > +1, this used to be an issue under vmx as well Tamas ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/4] hvm/svm: Enable Breakpoint events
On 12/02/18 15:08, Alexandru Isaila wrote: > @@ -2619,14 +2634,31 @@ void svm_vmexit_handler(struct cpu_user_regs *regs) > break; > > case VMEXIT_EXCEPTION_BP: > -if ( !v->domain->debugger_attached ) > -goto unexpected_exit_type; > -/* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not update RIP. > */ > -if ( (inst_len = __get_instruction_length(v, INSTR_INT3)) == 0 ) > +inst_len = __get_instruction_length(v, INSTR_INT3); There are multiple ways of ending up with this vmexit, and INT3 is not the only way. The old code was somewhat broken (but only in the case that a debugger was attached), but now with this introspection hook active, executing `0xcd 0x03` will end up crashing the domain because of a length mismatch looking for 0xcc. You need to inspect EXITINTINFO to work out what went on here, and distinguish INT3 from INT $3. Can I suggest that you run this unit test http://xenbits.xen.org/docs/xtf/test-swint-emulation.html under debug introspection an check that you get all expected events? Every time we touch this code, we seem to break it :( ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel