[llvm-dev] [RFC] LLVM Security Group and Process
Serge Guelton via llvm-dev
llvm-dev at lists.llvm.org
Thu Jan 9 07:54:44 PST 2020
Hi JF,
Answering your question both as an individual and with a red hat:
> Should we create a security group and process?
Yes! That's a good starter, and some bits of formalization are likely to be
beneficial.
> 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?
I like the non-intrusive coordination aspect. It also helps to have a group
to speak with for responsible disclosure.
The dispatch mechanism to actual developers is unclear. Do they need to be
part of the group? How are thy contacted / based on which criteria?
> Our approach to this issue:
> 1. Are you an LLVM contributor (individual or representing a company)?
yes and yes (Red Hat)
> 2. Are you involved with security aspects of LLVM (if so, which)?
In the past: yes, building an obfuscating compiler based on LLVM.
In my current role: yes, trying to implement / catch-up with some of the
gcc hardening feature clang doesn't have (e.g. -fstack-clash-protection and
_FORTIFY_SOURCE improvement recently)
> 3. Do you maintain significant downstream LLVM changes?
We're trying to have as few patches as possible, so that's a small yes.
> 4. Do you package and deploy LLVM for others to use (if so, to how many
people)?
Yes (Fedora and RHEL)
> 5. Is your LLVM distribution based on the open-source releases?
Yes., with a larger delay for RHEL.
> 6. How often do you usually deploy LLVM?
At least one for each Major and minor update (Fedora) and then backports +
RHEL.
> 7. How fast can you deploy an update?
For fedora, it can be a matter of days. For RHEL it takes longer but it can
be ~ 1 week.
> 8.Does your LLVM distribution handle untrusted inputs, and what kind?
> 9. What’s the threat model for your LLVM distribution?
I don't think we have something specific to LLVM in the threat model,
especially as gcc is the system compiler for both distributions.
--
Serge
On Wed, Jan 8, 2020 at 6:36 AM JF Bastien via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi folks!
>
> I want to ping this discussion again, now that the holidays are over. I’ve
> updated the patch to address the comments I’ve received.
>
> Overall it seems the feedback is positive, with some worries about parts
> that aren’t defined yet. I’m trying to get things started, so not
> everything needs to be defined yet! I’m glad folks have ideas of *how* we
> should define what’s still open.
>
>
> Thanks,
>
> JF
>
>
> On Nov 15, 2019, at 10:58 AM, JF Bastien via llvm-dev <
> llvm-dev at lists.llvm.org> 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?
> 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:
> 1. Are you an LLVM contributor (individual or representing a
> company)?
> 2. Are you involved with security aspects of LLVM (if so, which)?
> 3. Do you maintain significant downstream LLVM changes?
> 4. Do you package and deploy LLVM for others to use (if so, to how
> many people)?
> 5. Is your LLVM distribution based on the open-source releases?
> 6. How often do you usually deploy LLVM?
> 7. How fast can you deploy an update?
> 8. Does your LLVM distribution handle untrusted inputs, and what
> kind?
> 9. 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:
> 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
>
>
> _______________________________________________
> 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/20200109/ee74c30b/attachment.html>
More information about the llvm-dev
mailing list