How does ptrace POKETEXT works when modifying program text?

Question

Does it bypass read only page permissions of the traced process? Or does it need to change permission temporarily to be writable? If that's the case is the permission change visible to the traced process?

Answer 1

Looking at the kernel sources, x86 uses the generic (as opposed to arch-specific) ptrace request functions.

The actual changes are done by mm/memory.c:__access_remote_vm(), which uses mm/gup.c:get_user_pages_remote() to obtain the kernel mapping for the target page, followed by kmap(page), copy_to_user_pages(), set_page_dirty_lock(), kunmap(page), and put_page(page).

The simple description of what is actually done, is that the target process memory containing the code is accessed (modified) thorough the kernel mapping — the virtual memory "window" or "barrier" between the target process and the kernel — and not through the mappings visible to user-space processes.

Based on the above, we can answer the stated questions:

Does PTRACE_POKETEXT bypass read only page permissions of the traced process?

Yes. The kernel does not use the page protection mechanisms visible to userspace processes for this; it uses its own internal mappings.

Or does it need to change permission temporarily to be writable?

No, it does not.

Note that except for the changed data in the userspace memory (and possibly whether the pages are backed by an executable file or not), and for any kernel or hardware bugs there might be, when and how the kernel uses its own mappings is invisible and undetectable to userspace processes.