On Wed, Feb 17, 2010 at 04:13:11PM +0100, Jan Kiszka wrote:
> Gleb Natapov wrote:
> > On Wed, Feb 17, 2010 at 12:32:05PM +0100, Jan Kiszka wrote:
> >> Gleb Natapov wrote:
> >>> On Mon, Feb 15, 2010 at 02:20:31PM +0100, Jan Kiszka wrote:
> >>>> Jan Kiszka wrote:
> >>>>> Gleb Natapov wrote:
> >>>>>> Lets check if SVM works. I can do that if you tell me how.
> >>>>> - Fire up some Linux guest with gdb installed
> >>>>> - Attach gdb to gdbstub of the VM
> >>>>> - Set a soft breakpoint in guest kernel, ideally where it does not
> >>>>> immediately trigger, e.g. on sys_reboot (use grep sys_reboot
> >>>>> /proc/kallsyms if you don't have symbols for the guest kernel)
> >>>>> - Start gdb /bin/true in the guest
> >>>>> - run
> >>>>>
> >>>>> As gdb sets some automatic breakpoints, this already exercises the
> >>>>> reinjection of #BP.
> >>>> I just did this on our primary AMD platform (Embedded Opteron, 13KS EE),
> >>>> and it just worked.
> >>>>
> >>> I tested it on processor without NextRIP and your test case works there
> >>> too,
> >>> but it shouldn't have, so I looked deeper into that and what I see is
> >>> that GDB outsmart us. It doesn't matter if we inject event before int3
> >>> inserted by GDB or after it GDB correctly finds breakpoint that
> >>> triggered and restart instruction correctly. I assume it doesn't use
> >>> exact match between rip where int3 was inserted and where exceptions
> >>> triggers.
> >> At latest when you have two successive breakpoints on single-byte
> >> instructions, gdb will reach its limits (for it failed earlier, BTW).
> >> And other debuggers under other OSes may become unhappy as well.
> > Yes, and that is why I am saying checking with GDB is not a good test.
> > GDB may work, but it doesn't mean injection works correctly. It took me
> > some time to write test that finally confused gdb. It was like this:
> >
> > 1: int main(int argc, char **argv)
> > 2: {
> > 3: if (argc == 1)
> > 4: goto a;
> > 5: asm("cmc");
> > 6: a:
> > 7: asm("cmc");
> > 8: return 0;
> > 9: }
> >
> > If you set breakpoint on lines 5 and 7 when breakpoint triggers GDB
> > thinks it is on line 5.
> >
> > So can you run int3 test below on master on AMD with NextRIP support?
> > I doubt the result will be correct.
>
> If you meant your test above: Works out of the box with unpatched kvm on
> modern AMD CPUs, ie. gdb always stops at line 7 even if host debugging
> is active.
>
I meant test that does asm("int3") and see that rip it reports with and
without host debugging active is the same and points after int3. But I
guess if program above works correctly int3 test should work too. Thanks.
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
