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.
does GDB temporarily set write permissions
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 —
The kernel doesn’t have to do the same for
man ptrace says:
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.