[PATCH] D70326: [docs] LLVM Security Group and Process

[Shayne Hiet-Block via Phabricator via llvm-commits]

Shayne added a comment.

In D70326#1810421 <https://reviews.llvm.org/D70326#1810421>, @jfb wrote:

> In D70326#1809735 <https://reviews.llvm.org/D70326#1809735>, @theraven wrote:
>
> > We (Microsoft) are interested in participating in this process.
>
>
> Thanks David.
>
> > I have one concern, which is that most of the security issues arising from LLVM are not necessarily security issues in LLVM itself.  For example, a miscompilation that breaks invariants that a sandboxing technique depends on will appear to most LLVM developers as a simple miscompilation and may be a security issue only for downstream consumers.  Presumably this group should be involved if the issue may apply to multiple downstream consumers?
> > 
> > Where do things like the null-check elision that caught Linux fall?  This was a Linux dependence on undefined behaviour that caused compilers to emit code that introduced security vulnerabilities into Linux.  Is that in scope for this group, or would we regard that as a Linux vulnerability independent of LLVM?  What about, for example, a change to if-conversion that introduces branches in C code believed to be constant time and introduces vulnerabilities in crypto libraries, is that in scope?
> > 
> > I don't think that we can characterize security issues based on where in the code they exist, but rather based on the kinds of behaviour that they trigger and we need to provide very clear advice on what that should be.
>
> I absolutely agree! This complexity is why I'm not trying to decide what's in / out right now, and would rather have that process occur as follow-up RFCs (with updates to this document explaining what's in / out and why). Folks were expressing similar worries on the mailing list.


Hello. As David mentioned, we are interested in being involved and I'll be the contact from Microsoft. We have quite a few teams using LLVM to compile parts of their products, and it's going to be important to figure out how to ensure security. As David said, this often will not mean changes to LLVM, but rebuilding the project source with new security fixes/features. Thinking about a previous security vulnerability, Spectre, if this group would have handled it, we could learn about LLVM features to apply to our projects prior to disclosure.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70326/new/

https://reviews.llvm.org/D70326