On 11/05/14 08:34, joaoandrefe...@sapo.pt wrote: > > > > > Citando George Anzinger <geo...@wildturkeyranch.net>: > >> On 10/31/14 11:06, joaoandrefe...@sapo.pt wrote: >>> Hello all, >>> >>> Lately, I've been experimenting with KGDB to do some kernel debugging. >>> While doing this, a doubt arised while using the "set" command, trying >>> to change the value of some registers. I've been able to successfully >>> change the value of all the registers provided by the "info registers" >>> command (i. e., in my case $eax, $ecx, $edx, $ebx, $esp, $ebp, $esi, >>> $edi, $eip, $eflags, $cs, $ss, $ds, $es, $fs and $gs) *except* for >>> $esp, $ss, $fs and $gs. Why is it so? >> If you were to be successful in changing these once you continued from >> KGDB you would likely be immeadiatly back in KGDB to handle a system >> fault. If you got them exactly right, you just might be in another >> thread and might even execute a few instructions before the system >> discovered (the hard way) that it was executing code from a thread that >> was not the one the system tables indicate is running. >> >> Some of the registers you can change need to be handled VERY carefully >> (eip or esp for example) or you could easily confuse the system as well. > Hello George, > > Thanks for your answer (and sorry for the late reply). I know that > messing around with registers can lead to awkward results, but in a > certain that is precisely what I am trying to do: I'm using KGDB do to > some fault injection on the kernel, and for now that implies > bit-flipping registers. With that in mind I've made these simple > experiences (bit-flip every register I possibly could with (K)GDB), > just for testing purposes. And so, my initial doubt persists: why > these four registers doesn't allow me to change their value? It is > supposed to be like this? And if so, is there a workaround? There is ALWAYS a workaround with KGDB, however it may require knowledge of just where and how it saves state on the stack, for example. In the distant past, I recall putting code in KGDB expressly to prevent messing with its internal state, bounds checks on store addresses as I recall. This is likely why some of the registers you can not change are included even though they could be changed without doing real harm. Its just that the protected ones are saved in the same chunk of memory, and, at the time I could not see any reason to mess with them.
As to a workaround, short of changing the KGDB code, the only easy way I see is to alias the memory locations so that they logically appear in two palaces. Another way would be to get KGDB to insert a call to a function that did the dirty work. This would involve a complex messing with the stack and the return address, which you can change, but would, of course, require different code for each arch. A long time ago, I did have code in KGDB that would actually implement the gdb call function request, but, alas, I never submitted this, again because it was arch dependent. So, in short, something to think about but not much help. -- George > >> -- >> George >>> I've been making these tests >>> after hitting a hardware breakpoint, then I set the values with e. g. >>> "set $es = 0xf1c2007c", and verifiy the assignemt with "info reg $es". >>> As I've pointed out, it works with the majority of the registers, >>> except for that four (in this particular case, the first command >>> doesn't output any error, but the second command shows me that the >>> registers remain with the initial value). By the way, I've started GDB >>> with the -write option (checked it inside GDb with the "show write" >>> command). My GDB version is 7.2. I have a practical example below the >>> end of this message, with "set debug remote 1" option enabled. Still >>> regarding this exxample, from what I've been told in the GDB mailing >>> list, it seems KGDB is ignoring the value change on $ss. >>> >>> Anyone here knows why? If someone knows something about this situation >>> and can share it with me, it would be great. >>> >>> Best regards, >>> João >>> >>> Example: >>> >>> (gdb) info reg $es >>> es 0x7b 123 >>> (gdb) set $es = 0x7c >>> Sending packet: $Pd=7c000000#ab...Ack >>> Packet received: >>> Packet P (set-register) is NOT supported >>> Sending packet: >>> $G14000000ccb59cc00000000067000000089fcbf10c9fcbf1ac309dc00000000079154ac09600000060000000680000007b009dc07c000000ffff0000ffff0000#61...Ack >>> Packet received: OK >>> Sending packet: $g#67...Ack >>> Packet received: >>> 14000000ccb59cc00000000067000000089fcbf10c9fcbf1ac309dc00000000079154ac09600000060000000680000007b009dc07c000000ffff0000ffff0000 >>> (gdb) info reg $es >>> es 0x7c 124 >>> (gdb) info reg $ssPedro >>> ss 0x68 104 >>> (gdb) set $ss = 0x69 >>> Sending packet: >>> $G14000000ccb59cc00000000067000000089fcbf10c9fcbf1ac309dc00000000079154ac09600000060000000690000007b009dc07c000000ffff0000ffff0000#62...Ack >>> Packet received: OK >>> Sending packet: $g#67...Ack >>> Packet received: >>> 14000000ccb59cc00000000067000000089fcbf10c9fcbf1ac309dc00000000079154ac09600000060000000680000007b009dc07c000000ffff0000ffff0000 >>> (gdb) info reg $ss >>> ss 0x68 104 >>> >>> Best regards, >>> João >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Kgdb-bugreport mailing list >>> Kgdb-bugreport@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport >>> >> -- >> George Anzinger geo...@wildturkeyranch.net >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Kgdb-bugreport mailing list >> Kgdb-bugreport@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport > > > ------------------------------------------------------------------------------ > _______________________________________________ > Kgdb-bugreport mailing list > Kgdb-bugreport@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport > -- George Anzinger geo...@wildturkeyranch.net ------------------------------------------------------------------------------ _______________________________________________ Kgdb-bugreport mailing list Kgdb-bugreport@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
