Does gdb provide temporary permission to write to pages?

I debugged a seg error in a Linux application caused by a program trying to change the static structure of an array of constants (therefore, the data was in the ELF read-only section and subsequently loaded into a page that was then read-only).

In GDB, I set a breakpoint on the assembler line that made the bad storage, and when it stopped, I manually performed the equivalent write action using GDB. GDB did this without any complaint, and reading the value back proved that it was indeed written. I looked through / proc / thepid / maps and this page was still marked as "write-ins."

So my question is: does GDB allow you to temporarily set write permissions on a read-only page, write, then reset permissions? Thanks.

+4
source share
1 answer

GDB temporarily sets write permissions

No.

On Linux / * 86, ptrace() (which is what GDB uses to read and write incomplete (being debugged) RAM) allows you to read and write pages that are not read / write inferior, which leads exactly to the confusion that you described .

This can be considered a bug in the kernel.

It should be noted that the kernel should allow ptrace to write to the normally non-writable .text section for the debugger in order to be able to set breakpoints (which is done by overwriting the original command with the breakpoint / trap - int3 through the PTRACE_POKETEXT request).

The kernel does not have to do the same for POKE_DATA , but man ptrace says:

 PTRACE_POKETEXT, PTRACE_POKEDATA Copies the word data to location addr in the child memory. As above, the two requests are currently equivalent. 

I believe the equivalence that causes the current behavior.

+12
source

All Articles