[llvm-dev] [RFC] LLVM Security Group and Process
Arnaud Allard de Grandmaison via llvm-dev
llvm-dev at lists.llvm.org
Fri Jan 24 10:22:22 PST 2020
On behalf of the board, I'd like to acknowledge that given the growing
usage of LLVM in wildly different areas, having some structure or process
to address security aspects is important, if not critical, for the health
and success of the LLVM project as a whole.
The board will fully support this group, but will not "run" it, as this
does not fall in the Foundation's remits.
We believe this is mostly an entity thing (companies, distributions, ...),
and these are notoriously slow to react. It has to interact with their own
security groups and their internal processes (SDL, ...) ; the usually
active people on the mailing list are not necessarily the ones
interested in this topic.
Each security advisory being very specific (spectre is quite different from
stack protection), plus the LLVM projects spectrum growing overtime (f18,
mlir, libc, ...) makes us think that the people in that group are rather
well identified security aware / knowledgeable / trusted contacts points in
the entities (and used to deal with coordination amongst entities) rather
than deep technical experts (the former is mandatory, the second is nice to
have). Actual technical experts spot-on the advisory under work will need
to be brought in on a need be basis by the security group. The board
believes the real benefit with this group is the coordination of the
security fix investigation and deployment amongst the different community
entity-members.
Finally, we believe it's best to begin with a small & motivated group,
laying the foundations, and then extend it on a need be basis.
On behalf of the board, I'd like to invite those who think their entity
should care about this proposal to prod the relevant person(s) in their
entity to comment on this proposal, preferably on the mailing list or
phabricator, but worst case directly to JF or myself.
Once we have some more comments / feedback, we can think of committing this
policy, and forming an initial group.
Kind regards,
Arnaud
From: Serge Guelton via llvm-dev <llvm-dev at lists.llvm.org>
> Date: Thu, Jan 9, 2020 at 4:55 PM
> Subject: Re: [llvm-dev] [RFC] LLVM Security Group and Process
> To: JF Bastien <jfbastien at apple.com>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>
>
>
> 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
>>
> _______________________________________________
> 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/20200124/ae5043bc/attachment.html>
More information about the llvm-dev
mailing list