有没有比解析 /proc/self/maps 更好的方法来找出内存保护？
在 Linux（或 Solaris）上，有一种比反复手动解析 /proc/self/maps 更好的方法来确定您是否可以读取、写入或执行存储在一个或多个地址中的任何内容。记忆？
例如，在 Windows 中，您有 VirtualQuery。
在 Linux 中，我可以 mprotect 更改这些值，但无法读回它们。
此外，有什么方法可以知道这些权限何时发生变化（例如，当有人在我背后对文件使用 mmap 时），而不是做一些非常具有侵入性的事情并在所有内容上使用 ptrace进程中的线程并拦截任何可能影响内存映射的系统调用尝试？
更新：
不幸的是，我在 JIT 内部使用它，它几乎没有关于它正在执行的代码的信息来获得常数的近似值。 是的，我意识到我可以拥有可变数据的常量映射，就像 Linux 使用的 vsyscall 页面一样。 我可以安全地退回到这样一个假设：初始解析中未包含的任何内容都是可变且危险的，但我对这个选项并不完全满意。
现在我所做的就是读取 /proc/self/maps 并构建一个可以通过二进制搜索来保护给定地址的结构。 每当我需要了解不在我的结构中的页面时，我都会重新读取 /proc/self/maps ，假设它已同时添加，否则无论如何我都会出现段错误。
似乎解析文本来获取这些信息而不知道它何时发生变化是非常糟糕的。 （/dev/inotify 对 /proc 中的几乎所有内容都不起作用）
On Linux (or Solaris) is there a better way than hand parsing /proc/self/maps repeatedly to figure out whether or not you can read, write or execute whatever is stored at one or more addresses in memory?
For instance, in Windows you have VirtualQuery.
In Linux, I can mprotect to change those values, but I can't read them back.
Furthermore, is there any way to know when those permissions change (e.g. when someone uses mmap on a file behind my back) other than doing something terribly invasive and using ptrace on all threads in the process and intercepting any attempt to make a syscall that could affect the memory map?
Update:
Unfortunately, I'm using this inside of a JIT that has very little information about the code it is executing to get an approximation of what is constant. Yes, I realize I could have a constant map of mutable data, like the vsyscall page used by Linux. I can safely fall back on an assumption that anything that isn't included in the initial parse is mutable and dangerous, but I'm not entirely happy with that option.
Right now what I do is I read /proc/self/maps and build a structure I can binary search through for a given address's protection. Any time I need to know something about a page that isn't in my structure I reread /proc/self/maps assuming it has been added in the meantime or I'd be about to segfault anyways.
It just seems that parsing text to get at this information and not knowing when it changes is awfully crufty. (/dev/inotify doesn't work on pretty much anything in /proc)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不知道 Linux 上的 VirtualQuery 的等效项。 但其他一些可能有效或无效的方法是：
您设置一个捕获 SIGBUS/SIGSEGV 的信号处理程序，然后继续读取或写入。 如果内存受到保护，您的信号捕获代码将被调用。 如果不是，则不会调用您的信号捕获代码。 无论哪种方式你都会赢。
您可以跟踪每次调用
mprotect并构建相应的数据结构，帮助您了解某个区域是否受到读或写保护。 如果您有权访问所有使用mprotect的代码，这会很好。您可以通过将代码与重新定义函数
mprotect的库链接来监视进程中的所有mprotect调用。 然后，您可以构建必要的数据结构来了解某个区域是否受到读或写保护，然后调用系统mprotect来真正设置保护。您可以尝试使用
/dev/inotify并监视文件/proc/self/maps是否有任何更改。 我想这个不起作用，但应该值得一试。I do not know an equivalent of
VirtualQueryon Linux. But some other ways to do it which may or may not work are:you setup a signal handler trapping SIGBUS/SIGSEGV and go ahead with your read or write. If the memory is protected, your signal trapping code will be called. If not your signal trapping code is not called. Either way you win.
you could track each time you call
mprotectand build a corresponding data structure which helps you in knowing if a region is read or write protected. This is good if you have access to all the code which usesmprotect.you can monitor all the
mprotectcalls in your process by linking your code with a library redefining the functionmprotect. You can then build the necessary data structure for knowing if a region is read or write protected and then call the systemmprotectfor really setting the protection.you may try to use
/dev/inotifyand monitor the file/proc/self/mapsfor any change. I guess this one does not work, but should be worth the try.有一些 is/was /proc/[pid|self]/pagemap，内核中的文档，这里有警告：
https://lkml.org/lkml/2015/7/14/477
所以它并不是完全无害的...
There sorta is/was /proc/[pid|self]/pagemap, documentation in the kernel, caveats here:
https://lkml.org/lkml/2015/7/14/477
So it isn't completely harmless...