有没有办法找出libc创建/访问的匿名虚拟内存区域?
我有一个mprotect
地址空间VMA的程序。
但是当mprotect
是一个将由libc访问的区域时,会发生SIGSEGV。不幸的是,我安装的信号处理程序只处理我的代码上发生的错误,而不是libc的错误。
详细地说,我得到的错误是因为printf
使用了varargs。它会尝试访问reg_save_area
结构中va_list
的位置。该位置属于我之前mprotect
编辑的匿名VMA。
那么,在我mprotect
之前,是否知道这些区域是哪个?或者至少知道stdarg.h
选择放置reg_save_area
的位置?
最干净的方法是处理libc中发生的SIGSEGV。 但我怀疑是否有这样的方式。
注意:可以轻松识别libc的data / bss段,因为它不是匿名的。如果我mprotect
也是VMA,它也会导致未处理的SIGSEGV,这就是我选择不这样做的原因。
答案 0 :(得分:4)
您问题的最简单答案是:除了您自己明确映射的那些之外,所有这些答案都是。
不要做mprotect
你自己没有mmap
的记忆范围。库甚至内核都会一直在你背后做事。他们将自己进行分配和映射。您不能更改它们,因为它们不属于您自己管理。
顺便说一下。我的意思是mmap
。您从malloc或任何其他分配功能获得的内存保护也不属于您。如果您想完全控制内存映射,请不要使用libc,也不要进行动态链接。
答案 1 :(得分:0)
最干净的方法是处理在其中发生的SIGSEGV libc中。但我怀疑是否有这样的方式。
实际上,可以处理由C库代码引起的SIGSEGV 。我确实处理了它们。
无法处理的SIGSEGV是在处理函数本身内或在执行V mprotection
的函数内发生的。
那么,在我保护这些区域之前,有没有知道这些区域是什么? 或者至少是一种了解stdarg.h选择放置位置的方法 reg_save_area?
除了@Art的建议之外,没有办法知道libc创建了哪些区域,但我的问题的解决方案是跳过对处理程序本身正在使用的页面的保护,或者是建立整体保护机制。
PS。我不认为这是我的问题的答案,因为它根本不回答我问的问题。它解决了我原来的问题,这就是我分享它的原因。