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

Matthew Riley via llvm-dev llvm-dev at lists.llvm.org
Thu Jun 18 16:10:47 PDT 2020 

Just me for now. I'll double-check with Kostya but I didn't get the
impression he wanted to be on the inbound path.

Thanks again for all the effort here.

On Thu, Jun 18, 2020 at 3:57 PM JF Bastien <jfbastien at apple.com> wrote:

> Thanks Zola. Is that Matthew and Kostya (who chimed in to the thread
> earlier), or just Matthew?
>
> On Jun 18, 2020, at 3:47 PM, Zola Bridges <zbrid at google.com> wrote:
>
> Hi everyone,
>
> I followed up with some folks at Google about how we wanted to be involved
> in this group and we decided that Matthew Riley (mattdr at google.com) would
> be the right person to be involved here.
>
> Sorry about the confusion. I'd like to withdraw my request.
>
> Thanks again to everyone involved! I'm glad to see this becoming a part of
> how LLVM works. :)
>
> Zola Bridges
>
>
> On Wed, Jun 17, 2020 at 4:52 PM Zola Bridges <zbrid at google.com> wrote:
>
>> Hi JF,
>>
>> Thanks for the quick response!
>>
>> The biggest reason I think the mailing list would make sense is to avoid
>> a single point of failure within Google. While folks like me and kcc will
>> be the active participants in the group, the mailing list means that any
>> security responders at Google who may need to know this information about a
>> particular issue will have access even if me or kcc (or any other Googler)
>> are all unavailable.
>>
>> Keeping me, kcc, and other Googlers who end up joining as top-level
>> members with their info listed the same as other members seems like it
>> would address the 1st and 3rd points.
>>
>> I think it would make sense if the mailing list had read-only access to
>> limit chatter to address the 4th point. This mailing list isn't intended to
>> be a new set of active participants, but is intended to keep relevant
>> Googlers in the loop for relevant vulnerabilities.
>>
>> The 2nd point is important and folks on the Google-internal list will
>> have expectations set when they join the list. In addition, typically the
>> folks on the list will be those at Google who already work with security
>> incident response and have baseline knowledge about general expectations
>> for lists such as this one.
>>
>> Zola Bridges
>>
>>
>> On Wed, Jun 17, 2020 at 3:59 PM JF Bastien <jfbastien at apple.com> wrote:
>>
>>> Thanks Zola,
>>>
>>> I’d rather have point-contact people, instead of having mailing lists. I
>>> have a few goals with this:
>>>
>>>    1. Listing particular people makes it clear who’s on the hook from
>>>    your organization
>>>    2. These people can still communicate internally, but are
>>>    responsible to ensure that the internal folks know what the LLVM process
>>>    and disclosure restrictions are
>>>    3. Listing a limited number of specific people helps make this part
>>>    of their official work within their company, and ideally those folks make
>>>    sure they’re not all unavailable at the same time
>>>    4. Mailing lists tend to attract chatter and lose focus
>>>
>>>
>>> That being said, there’s certainly convenience to having a list. I’m not
>>> sure that convenience warrants the tradeoffs :)
>>>
>>> LMK what you think!
>>>
>>> JF
>>>
>>>
>>> On Jun 17, 2020, at 3:52 PM, Zola Bridges <zbrid at google.com> wrote:
>>>
>>> Hi everyone!
>>>
>>> I'm very glad this is moving forward! Just a week or two ago there was
>>> an SLH bug that really should've been sent to a group like the one that's
>>> being created here. Thanks a bunch, JF, for driving this!
>>>
>>> I'd like to be in this group representing the C++ security team at
>>> Google. I maintain two speculative execution side channel attack passes:
>>> Speculative Load Hardening and Speculative Execution Side Effect
>>> Suppression.
>>>
>>> I'd also like the mailing list alias llvm-security at google.com to be in
>>> this group. The list is restricted within Google to folks who need to be
>>> involved in security response related to LLVM.
>>>
>>> Are there objections to this? I did read the proposal and it looks like
>>> it's okay for members of the group to share vulnerabilities/reports within
>>> their organization on a need-to-know basis, however it's possible a set up
>>> like this is not what was intended by what was written in the proposal, so
>>> I'd like to hear your thoughts.
>>>
>>> Thanks again to everyone involved in setting this up!
>>>
>>> Zola Bridges
>>>
>>>
>>> On Mon, Jun 15, 2020 at 11:56 AM Renato Golin via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> Great idea! Sign me up, please!
>>>>
>>>> On Fri, 12 Jun 2020 at 16:59, JF Bastien via llvm-dev
>>>> <llvm-dev at lists.llvm.org> wrote:
>>>> >
>>>> > Great! On the Apple side, we’ll propose Oliver Hunt (clang team) and
>>>> Scotty Bolin (product security team), CC’ed to this email.
>>>> >
>>>> >
>>>> > On Jun 12, 2020, at 6:50 AM, Kristof Beyls <Kristof.Beyls at arm.com>
>>>> wrote:
>>>> >
>>>> > Thank you for progressing this, JF!
>>>> >
>>>> > As vendor contacts for Arm, myself (kristof.beyls at arm.com) and Peter
>>>> Smith (peter.smith at arm.com) are interested in being part of the
>>>> Security Group.
>>>> > We’re also interested in helping in the forming of this group.
>>>> >
>>>> > Thanks,
>>>> >
>>>> > Kristof
>>>> >
>>>> > On 11 Jun 2020, at 17:39, JF Bastien via llvm-dev <
>>>> llvm-dev at lists.llvm.org> wrote:
>>>> >
>>>> > Hi security-minded folks!
>>>> >
>>>> > I published this RFC quite a while ago, and have received good
>>>> feedback from y’all, as well as enthusiasm from a few folks whose
>>>> distribution would benefit from having a security process for LLVM. Arnaud
>>>> and the Board approved the patch a few weeks ago, I’ll therefore commit it
>>>> in the next few days and start moving the missing parts forward.
>>>> >
>>>> > Some folks have self-identified as being interested in being part of
>>>> the original Security Group. Let’s take this opportunity to hear from
>>>> anyone else who’s interested: please speak up!
>>>> >
>>>> > 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. The proposal starts with a
>>>> list of goals for the process and Security Group, repeated here:
>>>> >
>>>> > The LLVM Security Group has the following goals:
>>>> >
>>>> > Allow LLVM contributors and security researchers to disclose
>>>> security-related issues affecting the LLVM project to members of the LLVM
>>>> community.
>>>> > Organize fixes, code reviews, and release management for said issues.
>>>> > Allow distributors time to investigate and deploy fixes before wide
>>>> dissemination of vulnerabilities or mitigation shortcomings.
>>>> > Ensure timely notification and release to vendors who package and
>>>> distribute LLVM-based toolchains and projects.
>>>> > 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:
>>>> >
>>>> > On this list: Should we create a security group and process?
>>>> > On this list: Do you agree with the goals listed in the proposal?
>>>> > 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?
>>>> > 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?
>>>> > 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:
>>>> >
>>>> > Yes! We should create a security group and process.
>>>> > We agree with the goals listed.
>>>> > We think the proposal is exactly right, but would like to hear the
>>>> community’s opinions.
>>>> > 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
>>>> >
>>>> > _______________________________________________
>>>> > 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
>>>> _______________________________________________
>>>> 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/20200618/96a8e6ae/attachment.html>

More information about the llvm-dev mailing list