Does gdb temporarily give pages write permission?

Question

I was debugging a seg fault in a Linux app that was caused by a program trying to change a static constant array structure (so the data was in the read-only section of the ELF and subsequently loaded in a page that was then given read-only permission).

While in GDB I put a breakpoint on the line of assembler that did the bad store, and when it stopped there I manually performed the equivalent write action using GDB. GDB did this without any complaints, and reading the value back proved it had indeed been written. I looked in /proc/thepid/maps and that particular page was still marked as "not writeable".

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

Answer 1

does GDB temporarily set write permissions

No.

On Linux/*86, ptrace() (which is what GDB uses to read and write the inferior (being debugged) process memory) allows reads and writes to pages that are not readable/writable by the inferior, leading exactly to the confusion you've described.

This could be considered a bug in the kernel.

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

The kernel doesn't 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's memory.
   As above, the two requests are currently equivalent.

I believe it's that equivalentness that causes the current behavior.