[llvm-dev] [RFC] LLVM Security Group and Process
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Mon Nov 25 16:51:05 PST 2019
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
> 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?
> 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
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
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?
> 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
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
> 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.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev