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

[Peter Smith 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
----------------
smithp35 wrote:

Could be worth going into a bit more detail here. Otherwise I expect something like, miscompile causes a segfault leading to denial of service attack. I think we would be looking for something systemic that affected multiple programs in a predictable way that an attacker could exploit.

I've found it difficult to think of concrete examples:
* Major mitigation bypasses
* Breaking security properties of certain attributes like `cmse_nonsecure_call`

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