Linux系统Python进程/proc/PID/maps映射段分散异常原因问询

• 你的python3.9可执行文件以*位置无关可执行文件（PIE）*格式编译：Fedora 33及后续版本默认所有系统二进制都开启PIE编译，符合该前提
• 内核开启全地址空间随机化（ASLR），且使用5.8+版本内核新增的细粒度ELF段随机化特性：你使用的5.13内核属于支持范围，Fedora 33默认开启该配置（可通过cat /proc/sys/kernel/randomize_va_space验证，返回值为2即开启全随机）
• 所用glibc版本的动态链接器（ld-linux.so）支持PIE文件的分段映射逻辑，不再强制要求同一ELF文件的所有段连续排布

你认知里的"同一ELF映射段连续、可执行文件段排在地址空间最前"是传统非PIE可执行文件的加载规则，不适用于现在默认开启PIE+全ASLR的发行版：

• PIE格式的可执行文件本质是特殊的共享对象，和普通动态链接库没有本质区别，动态链接器可以将其任意段映射到地址空间的任意位置，不需要固定基地址，自然也不需要排在所有共享库之前
• 5.8+内核的细粒度ASLR会对同一个ELF（包括可执行文件、共享库）的不同权限段（代码段、只读数据段、读写数据段）分别做地址随机化，段与段之间会插入不可访问的匿名防护页，甚至会插入其他ELF的映射段，大幅提升漏洞利用的难度，这就是你看到python3.9和libpython3.9.so.1.0段分散的核心原因
• 动态链接器对PIE文件的加载优先级不再固定：可以先加载部分DT_NEEDED依赖的共享库，再映射PIE可执行文件的剩余段，甚至可以在所有共享库加载完成后，再补充映射可执行文件的特殊段（比如注解段、额外的只读元数据段），这就是可执行文件段出现在共享库之后的原因
• 若进程运行过程中调用mmap/mremap调整原有段地址、或者动态dlopen加载新的共享库，还会进一步加剧段的分散程度

内容的提问来源于stack exchange，提问作者Dargor