为什么uClibc UCLIBC_BUILD_NOEXECSTACK实际上不使用链接器标志-Wl、-z、noexec堆栈？

Question

一种现代的Linux安全强化策略是使用选项-Wl,-z-noexecstack编译和链接代码，这将DLL或二进制标记为不需要可执行堆栈。可以使用readelf或其他方法检查此条件。

我一直在使用uClibc，并注意到它生成没有设置此标志的对象(.so文件)。然而，uClibc有一个配置选项UCLIBC_BUILD_NOEXECSTACK，根据帮助，它意味着：

  Mark all assembler files as noexecstack, which will mark uClibc
  as not requiring an executable stack.  (This doesn't prevent other
  files you link against from claiming to need an executable stack, it
  just won't cause uClibc to request it unnecessarily.)

  This is a security thing to make buffer overflows harder to exploit.
  ...etc...

在一些深入Makefiles的文章中，这是正确的--标记只应用于汇编程序。

因为标志只传递给汇编程序，这是否意味着uClibc开发人员错过了一个重要的强化标志？还有其他选项，例如UCLIBC_BUILD_RELRO，它们确实导致将等效的标志添加到链接器中(作为-Wl,-z,relro)。

然而，一个偶然的观察者很容易误解这一点，并假设，正如我最初所做的那样，UCLIBC_BUILD_NOEXECSTACK实际上是在标记.so文件，而实际上它并不是。例如，OpenWRT确保在构建uClibc时设置该标志。

为什么uClibc不按“平常”的方式做事呢？我在这里错过了什么？库(例如librt.so、libpthread.so等)实际上不是NX吗？

EDIT能够使用Makefiles并使用-Wl,-z,noexecstack参数获得noexecstack位。那么，他们为什么不使用它呢？

Answer 1

好的，在列表对话和进一步研究之后，我们发现：

• GNU链接器根据“最低公分母”设置DLL /可执行堆栈状态，也就是说，如果任何链接或引用的部分都有exec堆栈，那么整个对象就是这样设置的。
• 解决此问题的“正确”方法实际上是在不需要使用exec堆栈时找到并修复使用exec堆栈的程序集/对象文件。

如果不能修复根本原因，则使用链接器来“修复”事物是一种解决办法。

因此，对于uClibc解决方案，需要提交一个bug，以便修复底层对象。否则，任何与静态库相关联的东西都不会得到一个非exec堆栈。

对于我自己的问题，如果构建一个不使用任何静态库的定制固件，那么使用链接器标志就足够了。

参考文献：

• Ubuntu安全小组-可执行堆栈