是否有比解析/ proc / self / maps更好的方法来确定内存保护？

丁业

2023-03-14

问题内容：

在Linux（或Solaris）上，有没有比/proc/self/maps重复进行手动分析更好的方法，以弄清您是否可以读取，写入或执行存储在内存中一个或多个地址上的内容？

例如，在Windows中，您拥有VirtualQuery。

在Linux中，我可以mprotect更改这些值，但是无法读回。

此外，mmap除了做一些极具侵害性的事情并ptrace在进程中的所有线程上使用并拦截任何syscall可能影响内存的尝试外，是否有其他方法可以知道这些权限何时发生更改（例如，某人使用我背后的文件）地图？

更新：

不幸的是，我在一个JIT内部使用了它，它几乎没有关于它正在执行的代码的信息，以获得近似的常量。是的，我意识到我可以拥有不变的可变数据映射，例如Linux使用的vsyscall页面。我
可以放心地认为，初始解析中未包含的任何内容都是易变且危险的，但是我对该选项并不完全满意。

现在我要做的是阅读/proc/self/maps并构建一个结构，可以对指定地址的保护进行二进制搜索。每当我需要了解某个不在我的结构中的页面时，我都会重新读取/
proc / self / maps，前提是假设该页面已在此期间添加，否则无论如何我都会进行段错误。

似乎解析文本以获取此信息而又不知道它何时更改是非常棘手的。（/dev/inotify在几乎没有任何作用/proc）

问题答案：

我不知道VirtualQueryLinux上的等效功能。但是，其他可行或不可行的方法是：

您设置了捕获SIGBUS / SIGSEGV的信号处理程序，然后继续进行读取或写入。如果内存受到保护，则将调用您的信号捕获代码。如果不是，则不调用您的信号捕获代码。无论哪种方式，您都会赢。
您可以在每次调用时进行跟踪，mprotect并建立相应的数据结构，以帮助您了解某个区域是否受读或写保护。如果您可以访问所有使用的代码，那么这很好mprotect。
mprotect通过将代码与重新定义函数的库链接起来，可以监视过程中的所有调用mprotect。然后，您可以构建必要的数据结构，以了解某个区域是否受到读或写保护，然后调用系统mprotect以真正设置保护。
您可以尝试使用/dev/inotify和监视文件/proc/self/maps中的任何更改。我想这是行不通的，但值得尝试。