[llvm-dev] [RFC] LLVM Security Group and Process

[Philip Reames via llvm-dev]

On 11/15/19 10:58 AM, JF Bastien via llvm-dev wrote:
>
>
>   Hello compiler enthusiasts,
>
>
> The Apple LLVM team would like to propose that a new a security 
> process and an associated private LLVM Security Group be created under 
> the umbrella of the LLVM project.
>
> A draft proposal for how we could organize such a group and what its 
> process could be is available on Phabricator 
> <https://reviews.llvm.org/D70326>. The proposal starts with a list of 
> goals for the process and Security Group, repeated here:
>
> The LLVM Security Group has the following goals:
>
>  1. Allow LLVM contributors and security researchers to disclose
>     security-related issues affecting the LLVM project to members of
>     the LLVM community.
>  2. Organize fixes, code reviews, and release management for said issues.
>  3. Allow distributors time to investigate and deploy fixes before
>     wide dissemination of vulnerabilities or mitigation shortcomings.
>  4. Ensure timely notification and release to vendors who package and
>     distribute LLVM-based toolchains and projects.
>  5. Ensure timely notification to users of LLVM-based toolchains whose
>     compiled code is security-sensitive, through the CVE process
>     <https://cve.mitre.org/>.
>
>
> We’re looking for answers to the following questions:
>
>  1. _On this list_: Should we create a security group and process?
>
Probably, thought we haven't seen a strong need to date.

If a group does form, we (Azul) are definitely interested in 
participating as a vendor.

>  1. _On this list_: Do you agree with the goals listed in the proposal?
>
Yes
>
>  1. _On this list_: at a high-level, what do you think should be done
>     differently, and what do you think is exactly right in the draft
>     proposal?
>
I'm a bit uncomfortable with the board selected initial group.  I see 
the need for a final decision maker, but maybe require public on-list 
nominations before ratification by the board?  If there's broad 
consensus, no need to appeal to the final decision maker.

>  1. _On the Phabricator code review_: going into specific details,
>     what do you think should be done differently, and what do you
>     think is exactly right in the draft proposal?
>  2. _On this list_: to help understand where you’re coming from with
>     your feedback, it would be helpful to state how you personally
>     approach this issue:
>      1. Are you an LLVM contributor (individual or representing a
>         company)?
>
Yes, in this email responding in both my capacity as an individual 
contributor, and on the behalf of my employer, Azul Systems.
>
>      1. Are you involved with security aspects of LLVM (if so, which)?
>
We have responded to a couple of security relevant bugs, though we've 
generally not acknowledged that fact upstream until substantially later.
>
>      1. Do you maintain significant downstream LLVM changes?
>
Yes.
>
>      1. Do you package and deploy LLVM for others to use (if so, to
>         how many people)?
>
Yes.  Can't share user count.
>
>      1. Is your LLVM distribution based on the open-source releases?
>
No.  We build off of periodic ToT snapshots.
>
>      1. How often do you usually deploy LLVM?
>
We have a new release roughly monthly. We backport selectively as needed.
>
>      1. How fast can you deploy an update?
>
Usual process would be a week or two.  In a true emergency, much less.
>
>      1. Does your LLVM distribution handle untrusted inputs, and what
>         kind?
>
Yes, for any well formed java input we may generate IR and invoke the 
optimizer.  We fuzz extensively for this reason.
>
>      1. What’s the threat model for your LLVM distribution?
>
In the worst case, attacker controlled bytecode.  Given that, the 
attacker can influence, but not entirely control IR fed to the compiler.

>
> Other open-source projects have security-related groups and processes. 
> They structure their group very differently from one another. This 
> proposal borrows from some of these projects’ processes. A few examples:
>
>   * https://webkit.org/security-policy/
>   * https://chromium.googlesource.com/chromium/src/+/lkgr/docs/security/faq.md
>   * https://wiki.mozilla.org/Security
>   * https://www.openbsd.org/security.html
>   * https://security-team.debian.org/security_tracker.html
>   * https://www.python.org/news/security/
>
> When providing feedback, it would be great to hear if you’ve dealt 
> with these or other projects’ processes, what works well, and what can 
> be done better.
>
>
> I’ll go first in answering my own questions above:
>
>  1. Yes! We should create a security group and process.
>  2. We agree with the goals listed.
>  3. We think the proposal is exactly right, but would like to hear the
>     community’s opinions.
>  4. Here’s how we approach the security of LLVM:
>      1. I contribute to LLVM as an Apple employee.
>      2. I’ve been involved in a variety of LLVM security issues, from
>         automatic variable initialization to security-related
>         diagnostics, as well as deploying these mitigations to
>         internal codebases.
>      3. We maintain significant downstream changes.
>      4. We package and deploy LLVM, both internally and externally,
>         for a variety of purposes, including the clang, Swift, and
>         mobile GPU shader compilers.
>      5. Our LLVM distribution is not directly derived from the
>         open-source release. In all cases, all non-upstream public
>         patches for our releases are available in repository branches
>         at https://github.com/apple.
>      6. We have many deployments of LLVM whose release schedules vary
>         significantly. The LLVM build deployed as part of Xcode
>         historically has one major release per year, followed by
>         roughly one minor release every 2 months. Other releases of
>         LLVM are also security-sensitive and don’t follow the same
>         schedule.
>      7. This depends on which release of LLVM is affected.
>      8. Yes, our distribution sometimes handles untrusted input.
>      9. The threat model is highly variable depending on the
>         particular language front-ends being considered.
>
> Apple is involved with a variety of open-source projects and their 
> disclosures. For example, we frequently work with the WebKit community 
> to handle security issues through their process.
>
>
> Thanks,
>
> JF
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191125/0a243703/attachment.html>