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.
>
> > But if I run program below on latest kernel which prints rip
> > where #DB was delivered in dmesg I get different results with and
> > without external breakpoint inserted.
>
> Does applying v2 of my patch corrects the picture?
>
Of course, since it now injects #DB at correct address. If exception
will happen during #DB processing thins will go wrong, but we can do
only so much on broken SVM without emulating int3 in software.
> >
> > int main(int argc, char **argv)
> > {
> > asm("int3");
> > return 0;
> > }
> >
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
