更详细地说，问题是：没有root权限，一个进程是否有可能读取（不仅仅是写入）另一个进程的内存？ （例如，通过某种方式读取 /proc/gcore 或 /proc/[PID]/mem。我还不确定他们的权限要求。）
我确实理解实现了虚拟地址，并且每个进程都有自己的空间。我进行了快速搜索，但既没有找到强有力的保证，也没有找到破解方法。 This article 说：
系统中的每个进程都有自己的虚拟地址空间。这些虚拟地址空间彼此完全分离，因此运行一个应用程序的进程不能影响另一个。此外，硬件虚拟内存机制允许保护内存区域防止写入。这可以保护代码和数据不被恶意应用程序覆盖。
我不确定“影响”是否也包括“读取”，似乎硬件只是保护内存不被覆盖。
任何人都知道Linux系统的这种隔离是否有很强的保证，或者如果它可以被黑客入侵，如何保证？
提前致谢！
【问题讨论】：
标签： linux memory process isolation
旁注：据我所知，鉴于其作为安全问题的重要性，这是一个记录不充分的主题。
太长了；不要阅读：一个进程的virtual address space 与另一个进程完全隔离。 Linux 内核可以访问整个内存，因为它在kernel mode 中运行。它提供系统调用，允许进程在某些情况下（请参阅下面的Ptrace 访问模式检查）访问另一个进程的内存。
Linux内核中有一些系统调用允许读/写其他进程的内存：
process_vm_readv() 和 process_vm_writev()（同一手册页）
这些系统调用在调用进程（“本地进程”）的地址空间和由 pid 标识的进程（“远程进程”）之间传输数据。数据直接在两个进程的地址空间之间移动，不经过内核空间。
最后一句指的是内核模式下发生的事情（内核实际上在两个物理地址之间进行复制）。用户模式不能访问其他虚拟地址空间。有关技术详情，请查看the implementation patch。
关于所需的权限：
读取或写入另一个进程的权限由 ptrace 访问模式 PTRACE_MODE_ATTACH_REALCREDS 检查控制；见ptrace()。
ptrace() 系统调用提供了一种方法，通过该方法一个进程（“跟踪器”）可以观察和控制另一个进程（“跟踪器”）的执行，并检查和更改跟踪器的内存和寄存器。
关于所需的权限，根据ptrace()手册页：
Ptrace 访问模式检查
内核用户空间 API 的各个部分（不仅仅是 ptrace() 操作）需要所谓的“ptrace 访问模式”检查，其结果决定了操作是否被允许（或者，在少数情况下，导致一个“读取”操作以返回经过清理的数据）。 这些检查是在一个进程可以检查有关另一个进程的敏感信息或在某些情况下修改另一个进程的状态的情况下执行的。这些检查基于两个进程的凭据和能力等因素，“目标”进程是否可转储，以及任何已启用的 Linux 安全模块 (LSM)（例如 SELinux、Yama 或 Smack）和 commoncap LSM（始终被调用）执行的检查结果。
相关内容：
CAP_SYS_PTRACE 能力。请参阅capabilities 手册页。
List 包含所有 Linux 内核系统调用的手册页。
【讨论】：