一个用户提交了一个bug报告,说我的应用程序在 "__fortify_fail()" 处出现了分段错误。
我知道这与使用Debian的 "hardening"标志 -D_FORTIFY_SOURCE=2 -fstack-protector
有关。
遗憾的是,用户的回溯信息并没有告诉我太多,而且这个用户现在也不太响应。
为了更好地理解发生了什么,我想知道 __fortify_fail
实际上是做什么的。
这个函数通常只是一个错误报告器。glibc中的示例代码如下:
extern char **__libc_argv attribute_hidden;
void
__attribute__ ((noreturn))
__fortify_fail (msg)
const char *msg;
{
/* The loop is added only to keep gcc happy. */
while (1)
__libc_message (2, "*** %s ***: %s terminated\n",
msg, __libc_argv[0] ?: "<unknown>");
}
libc_hidden_def (__fortify_fail)
在某些情况下,需要加强源代码的安全性,这时就会使用"Fortification"。"Fortification"本身只是一些运行时检查。在io/openat.c
中,openat
函数的示例用法如下:
int
__openat_2 (fd, file, oflag)
int fd;
const char *file;
int oflag;
{
if (oflag & O_CREAT)
__fortify_fail ("invalid openat call: O_CREAT without mode");
return __openat (fd, file, oflag);
}
如果没有加强保护,可以不需要mode来使用O_CREAT
(尽管这种情况非常可疑,但是它是合法的)。
将__fortify_fail
看作printf+abort。
关于您的问题,我想说,用户在使用用户代码中的libc时可能会遇到一些问题。/lib/x86_64-linux-gnu/libc.so.6(+0xebdf0)[0x7f75d3576df0]
是libc中某个运行时检查失败的位置,因此pd[0x49b5c0]
是从libc错误调用的位置。