• Uncategorized

About linux : Does-gdb-temporarily-give-pages-write-permission

Question Detail

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.

Question Answer

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.

You may also like...

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.