[llvm] Improve description of what is considered a security issue (PR #147035)

[Kristof Beyls via llvm-commits]

================
@@ -217,31 +222,51 @@ security-sensitive). This requires a rationale, and buy-in from the LLVM
 community as for any RFC. In some cases, parts of the codebase could be handled
 as security-sensitive but need significant work to get to the stage where that's
 manageable. The LLVM community will need to decide whether it wants to invest in
-making these parts of the code securable, and maintain these security
-properties over time. In all cases the LLVM Security Response Group should be consulted,
+making these parts of the code securable, and maintain these security properties
+over time. In all cases the LLVM Security Response Group should be consulted,
 since they'll be responding to security issues filed against these parts of the
 codebase.
 
-If you're not sure whether an issue is in-scope for this security process or
-not, err towards assuming that it is. The Security Response Group might agree or disagree
-and will explain its rationale in the report, as well as update this document
-through the above process.
-
 The security-sensitive parts of the LLVM Project currently are the following.
-Note that this list can change over time.
-
-* None are currently defined. Please don't let this stop you from reporting
-  issues to the LLVM Security Response Group that you believe are security-sensitive.
+Note that this list can change over time. If you're not sure whether an issue is
+in-scope for this security process or not, err towards assuming that it is. The
+Security Response Group might agree or disagree and will explain its rationale
+in the report, as well as update this document through the above process.
+
+* Code generation: most miscompilations are not security sensitive. However, a
+  miscompilation where there are clear indications that it can result in the
+  produced binary becoming significantly easier to exploit could be considered
+  security sensitive, and should be reported to the security response group.
+* Run-time libraries: only parts of the run-time libraries are considered
+  security-sensitive. The parts that are not considered security-sensitive are
+  documented below.
 
 The parts of the LLVM Project which are currently treated as non-security
 sensitive are the following. Note that this list can change over time.
 
-* Language front-ends, such as clang, for which a malicious input file can cause
-  undesirable behavior. For example, a maliciously crafted C or Rust source file
-  can cause arbitrary code to execute in LLVM. These parts of LLVM haven't been
-  hardened, and compiling untrusted code usually also includes running utilities
-  such as `make` which can more readily perform malicious things.
-
+* LLVM's language frontends, analyzers, optimizers, and code generators for
+  which a malicious input can cause undesirable behavior. For example, a
+  maliciously crafted C, Rust or bitcode input file can cause arbitrary code
+  to execute in LLVM. These parts of LLVM haven't been hardened, and handling
+  untrusted code usually also includes running utilities such as make which can
+  more readily perform malicious things. For example, vulnerabilities in
+  clang, clangd, or the LLVM optimizer in a JIT caused by untrusted inputs are
+  outside of the scope. We recommend the use of an external sandbox in those
+  cases.
+* The following parts of the run-time libraries are explicitly not considered
+  security-sensitive:
+
+  * parts of the run-time libraries that are not meant to be included in
----------------
kbeyls wrote:

We could add more examples to the "For example, ...." sentence. But I'm not sure it would add enough value to offset the "cost" of making the documentation a bit longer to read through...

I guess one way to change the sentence would be "For example, most sanitizers are not considered security-sensitive as they are meant to be used during development only, not in production. Profiling and coverage-related run-time code is similarly meant for development only".
(I haven't tried adding words to explain that some features of ubsan are considered suitable for production)

Overall, I'm still in favour of keeping the text as simple as it is. Of course, we can always adapt/improve it based on future experience.

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