【问题标题】:Which anonymous areas are created/accessed by libc?libc 创建/访问了哪些匿名区域?
【发布时间】:2015-07-10 12:21:07
【问题描述】:

有没有办法找出 libc 创建/访问了哪些匿名虚拟内存区域?

我有一个程序在其地址空间上mprotects VMA。 但是当它mprotects 一个将被 libc 访问的区域时,就会发生 SIGSEGV。不幸的是,我安装的信号处理程序只处理发生在我的代码上的错误,而不是 libc 的。

详细地说,我得到的错误是因为printf 使用可变参数。它尝试访问位于va_list 结构中的reg_save_area 的位置。该位置属于我之前拥有的匿名 VMA mprotected。

那么,在我mprotect 之前,有没有人知道这些区域是什么?或者至少有一种方法可以知道stdarg.h 选择放置reg_save_area 的位置?

最干净的方法是处理出现在 libc 中的 SIGSEGV。 但我怀疑是否有这种方法。

注意: libc 的 data/bss 段很容易识别,因为它不是匿名的。如果我也mprotect那个VMA,它也会导致一个未处理的SIGSEGV,这就是我选择不这样做的原因。

【问题讨论】:

    标签: c segmentation-fault signal-handling mprotect


    【解决方案1】:

    对您的问题最简单的答案是:除了您自己明确映射的那些之外,所有这些都是。

    不要做你自己没有mmapmprotect 内存范围。库,甚至可能内核会一直在你背后做事。他们将进行自己的分配和映射。您不能更改它们,因为它们不属于您的管理。

    顺便说一句。我真的是指上面的mmap。您从 malloc 或任何其他分配功能获得的内存保护也不是您可以触及的。如果你想完全控制你的内存映射,不要使用 libc 也不要做动态链接。

    【讨论】:

    • 谢谢。好主意。但是,目前我正在尝试其他可能有效的方法。稍后我会提供更新!
    • @Paschalis 你正在做的是向你的汽车引擎开枪,然后在互联网上询问瞄准的地方,这样它就不会着火。正确答案不是告诉你瞄准哪里,而是告诉你停止用霰弹枪射击你的引擎。
    • 是的,这就是它的样子,除非你知道我这样做的原因! ;)
    【解决方案2】:

    最干净的方法是处理在 库。但我怀疑有没有这样的方法。

    其实C库代码引起的SIGSEGV问题是可以处理的。我确实会处理它们。 无法处理的 SIGSEGV 发生在处理程序函数本身或执行 VMA 的mprotection 的函数中。

    那么,在我保护它们之前,有没有人知道这些区域是什么? 或者至少是一种了解 stdarg.h 选择放置位置的方法 reg_save_area?

    除了@Art 的建议之外,没有办法知道 libc 创建了哪些区域,但我的问题的解决方案是跳过对处理程序本身正在使用的页面的保护,或者是建立整体保护机制。

    PS。我不认为这是对我的问题的回答,因为它根本没有回答我提出的问题。它解决了我最初的问题,这就是我分享它的原因。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2014-03-08
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2014-10-31
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多