[flang-commits] [flang] [flang][docs] Add an FAQ about an executable stack (PR #171241)

[via flang-commits]

================
@@ -0,0 +1,54 @@
+<!--===- docs/FAQ.md
+
+   Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+   See https://llvm.org/LICENSE.txt for license information.
+   SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+
+-->
+
+<!-- TODO: remove this after adding this page to ToC -->
+```{eval-rst}
+:orphan:
+```
+
+# Frequently Asked Questions (FAQ)
+
+```{contents}
+---
+local:
+---
+```
+
+## Driver
+
+### Why do I get a warning or an error about an executable stack?
+
+This occurs because Flang's implementation of pointers to internal procedures requires an executable stack.
+
+When an internal procedure is referenced from outside its host scope (for example, via a procedure pointer), the implementation must ensure that it can still access variables from that host scope.
+To achieve this, the current implementation of Flang generates a small piece of code, called a "trampoline", on the stack.
+When the procedure is called, execution first goes through this trampoline.
+This means that the stack must be executable.
+For a more detailed explanation of trampolines, please refer to the [design document](InternalProcedureTrampolines.md).
+
+However, an executable stack can introduce security vulnerabilities (for example, by increasing the impact of [stack buffer overflow attacks](https://en.wikipedia.org/wiki/Buffer_overflow#Stack-based_exploitation)).
+Therefore, modern linkers often issue a warning or an error if an executable stack is not explicitly requested by the developer.
+For instance, the GNU Linker (`ld`) issues a warning while the LLVM Linker (`lld`) emits an error.
+
+```{note}
+The trampoline code generated by Flang is not itself a security risk.
+The risk comes from the possibility of executing malicious code, that is injected into the program, from the stack.
----------------
MattPD wrote:

> If you have a really good, really specific article from someone reputable (GCC docs, redhat, that sort of place) then we could link that but otherwise I think we just say that there is a risk and leave it at that.

Perhaps this could be relevant:

Low-Level Software Security for Compiler Developers - Stack buffer overflows
https://llsoftsec.github.io/llsoftsecbook/#stack-buffer-overflows

> The obvious solution to this issue is to use memory protection features of the processor in order to mark the stack (along with other data sections) as non-executable. [Note that the use of nested functions in GCC requires trampolines which reside on an executable stack. The use of nested functions, therefore, poses a security risk.. However, even when the stack is not executable, more advanced techniques can be used to exploit an overflow that overwrites the return address. These take advantage of code that already exists in the executable or in library code, and will be described in the next section.]


https://github.com/llvm/llvm-project/pull/171241