AFAIK, the ptrace syscall uses access_process_vm to read data from other process. However, different process' address space are isolated, how is that achieved?

1 Answer 1


Processes’ address spaces are indeed isolated from each other, but they’re not isolated from the kernel. The kernel always knows the memory layout of all active processes. access_process_vm works as follows:

On 64-bit platforms, in the general case (i.e. the page isn’t an I/O-remapped page), the mapping in the last step relies on the kernel’s direct physical mapping: the kernel has direct access to all physical memory. On 32-bit platforms with HIGHMEM, this might involve creating specific mappings. (The latter is the reason why kmap, in the last link above, is defined in highmem.h — it’s only needed for HIGHMEM.)

  • I'm curious that why does kmap just rely on direct physical mapping on 64-bit platforms . When kernel want to access process' memory, I think it still needs to establish a dynamic temporary mapping to that area, which is released after access_process_vm
    – scottxiao
    Oct 5, 2021 at 10:25
  • The kernel can access any page in memory through the direct mapping, it doesn’t need a temporary mapping. Oct 5, 2021 at 10:35
  • AFAIK, no matter the mapping is direct or not, the mappings are all recored in kernel's page table to make MMU work. Considering this, for those memory mapped for temporary usage in 64bit platform, are they firstly recored into page table and freed after calling access_process_vm
    – scottxiao
    Oct 5, 2021 at 16:01
  • The direct mapping is set up with permanent entries in the kernel’s page tables, there’s no need to add temporary mappings for anything inside it. That’s the whole point of the direct mapping. Oct 5, 2021 at 16:09
  • 1
    The kernel uses huge pages ;-). Oct 5, 2021 at 16:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .