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

[Arnaud De Grandmaison via llvm-dev]

Hi JF,

Thanks for putting up this proposal.

Regarding your question, which I answer both as an individual and with an Arm hat:

> Should we create a security group and process?
Yes ! We believe it's good to have such a group and a process. It may not be perfect for everyone, but that's way better than nothing, and the current proposal has the necessary bits to evolve and adapt over time to the actual needs.

> Do you agree with the goals listed in the proposal?
Yes !

> At a high-level, what do you think should be done differently, and what do you think is exactly right in the draft proposal?
Dealing with security vulnerabilities is often a bit of a mess, done under time pressure, so having a “safe” place to quickly iterate / coordinate amongst interested parties and taking into account upstream LLVM is necessary.
We like that the role of this group is to deal / coordinate security-related issues, not to define an overall security roadmap for LLVM --- this should happen in the open using the standard communication channels.
We think this group could work on proof of concept fixes or act as a proxy in case the work is done externally, providing (pre-)reviews to ensure the fixes are at the expected LLVM quality level, but the actual code reviews for committing LLVM upstream should be conducted using the standard community process (i.e. no special channel / fast lane for committing).

> Our approach to this issue:
> 1. Are you an LLVM contributor (individual or representing a company)?
I respond here both as an individual contributor and also on behalf of my employer, Arm.

> 2. Are you involved with security aspects of LLVM (if so, which)?
I'm involved with security aspects in general, and have occasionally been involved in some LLVM specific aspects of security.

> 3. Do you maintain significant downstream LLVM changes?
Yes we do, and a number of other companies using Arm also have downstream changes they maintain.

> 4. Do you package and deploy LLVM for others to use (if so, to how many people)?
In our case, the situation is not as simple as "package & deploy".
As a company, we care that all Arm users get the security fixes, wether this is thru software (tools or libraries) directly or indirectly shipped by Arm, or thru their own tool / library provider, or thru the vanilla open source channel.

> 5. Is your LLVM distribution based on the open-source releases?
We don't, but I'm sure there are distributions / users relying on the open-source releases.
We thus believe it's important that backports are made and shared whenever possible.

> 6. How often do you usually deploy LLVM?
We usually have about half a dozen releases a year, but then our downstream users have their own constraints / agenda. This will of course be different for other people providing Arm tools & libraries.

> 7. How fast can you deploy an update?
On our end, we usually need about 4 weeks, and our downstream users have their own constraints / agenda. This will of course be different for other people providing Arm tools & libraries.

> 8.Does your LLVM distribution handle untrusted inputs, and what kind?
> 9. What’s the threat model for your LLVM distribution?
Given our large user base and usage models, answering this precisely now and here is impossible.

Kind regards,
Arnaud

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of JF Bastien via llvm-dev <llvm-dev at lists.llvm.org>
Reply to: JF Bastien <jfbastien at apple.com>
Date: Saturday 16 November 2019 at 17:23
To: llvm-dev <llvm-dev at lists.llvm.org>
Subject: [llvm-dev] [RFC] LLVM Security Group and Process

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?
  2.  On this list: Do you agree with the goals listed in the proposal?
  3.  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?
  4.  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?
  5.  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:
     *   Are you an LLVM contributor (individual or representing a company)?
     *   Are you involved with security aspects of LLVM (if so, which)?
     *   Do you maintain significant downstream LLVM changes?
     *   Do you package and deploy LLVM for others to use (if so, to how many people)?
     *   Is your LLVM distribution based on the open-source releases?
     *   How often do you usually deploy LLVM?
     *   How fast can you deploy an update?
     *   Does your LLVM distribution handle untrusted inputs, and what kind?
     *   What’s the threat model for your LLVM distribution?

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:
     *   I contribute to LLVM as an Apple employee.
     *   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.
     *   We maintain significant downstream changes.
     *   We package and deploy LLVM, both internally and externally, for a variety of purposes, including the clang, Swift, and mobile GPU shader compilers.
     *   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.
     *   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.
     *   This depends on which release of LLVM is affected.
     *   Yes, our distribution sometimes handles untrusted input.
     *   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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191203/48664b0e/attachment.html>