
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Chris!<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 18, 2019, at 11:42 AM, Chris Bieneman <<a href="mailto:chris.bieneman@me.com" class="">chris.bieneman@me.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hey JF,<div class=""><br class=""></div><div class="">Thanks for putting this RFC together. LLVM security issues are very important, and I'm really glad someone is focusing attention here.</div><div class=""><br class=""></div><div class="">I'm generally in agreement with much of what you have proposed. I do have a few thoughts I'd like to bring up.</div><div class=""><br class=""></div><div class="">Having the group appointed by the board seems a bit odd to me. Historically the board has not involved itself technical processes. I'm curious what the board's thoughts are relating to this level of involvement in project direction (I know you wanted proposal feedback on Phabricator, but I think the role of the board is something worth discussing here).</div></div></div></blockquote><div><br class=""></div><div>I consulted the board before sending out the RFC, and they didn’t express concerns about this specific point. I’m happy to have another method to find the right seed group, but that’s the best I could come up with :)</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">My other meta thought is about focus and direction for the group. How do you define security issues?</div><div class=""><br class=""></div><div class="">To give you where I'm coming from. One of the big concerns I have at the moment is about running LLVM in secure execution contexts, where we care about bugs in the compiler that could influence code generation, not just the code generation itself. Historically, I believe, the security focus of LLVM has primarily been on generated code, do you see this group tackling both sides of the problem?</div></div></div></blockquote><div><br class=""></div><div>That’s indeed a difficult one!</div><div><br class=""></div><div>I think there are two aspects to this: for a non-LLVM contributor, it doesn’t really matter. If they think it’s a security thing, we should go through this process. They shouldn’t need to try to figure out what LLVM thinks is its security boundary, that’s the project’s job. So I want to be fairly accepting, and let people file things that aren’t actually security related as security issues, because that has lower risk of folks doing the wrong thing (filing security issues as not security related).</div><div><br class=""></div><div>On the flip side, I think it’s up to the project to figure it out. I used to care about what you allude to when working on PNaCl, but nowadays I mostly just care about the code generation. If we have people with that type of concern in the security group then we’re in a good position to handle those problems. If nobody represents that concern, then I don’t think we can address them, even if we nominally care. In other words: it’s security related if an LLVM contributor signs up to shepherd this kind of issue through the security process. If nobodies volunteers, then it’s not something the security process can handle. That might point out a hole in our coverage, one we should address.</div><div><br class=""></div><div>Does that make sense?</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Thanks,</div><div class="">-Chris</div><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Nov 15, 2019, at 10:58 AM, JF Bastien via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><h1 style="caret-color: rgb(0, 0, 0);" class=""><span style="font-weight: normal; font-size: 12px;" class=""><font face="HelveticaNeue" class="">Hello compiler enthusiasts,</font></span></h1><font face="HelveticaNeue" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><div class=""><font face="HelveticaNeue" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font></div>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.</span><br style="caret-color: rgb(0, 0, 0);" class=""><br style="caret-color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0);" class="">A draft proposal for how we could organize such a group and what its process could be is </span></font><a href="https://reviews.llvm.org/D70326" class="">available on Phabricator</a><font face="HelveticaNeue" class=""><span style="caret-color: rgb(0, 0, 0);" class="">. The proposal starts with a list of goals for the process and Security Group, repeated here:</span><br style="caret-color: rgb(0, 0, 0);" class=""><br style="caret-color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0);" class="">The LLVM Security Group has the following goals:</span><br style="caret-color: rgb(0, 0, 0);" class=""></font><ol style="caret-color: rgb(0, 0, 0);" class=""><li class=""><font face="HelveticaNeue" class="">Allow LLVM contributors and security researchers to disclose security-related issues affecting the LLVM project to members of the LLVM community.</font></li><li class=""><font face="HelveticaNeue" class="">Organize fixes, code reviews, and release management for said issues.</font></li><li class=""><font face="HelveticaNeue" class="">Allow distributors time to investigate and deploy fixes before wide dissemination of vulnerabilities or mitigation shortcomings.</font></li><li class=""><font face="HelveticaNeue" class="">Ensure timely notification and release to vendors who package and distribute LLVM-based toolchains and projects.</font></li><li class=""><font face="HelveticaNeue" class="">Ensure timely notification to users of LLVM-based toolchains whose compiled code is security-sensitive, through <a href="https://cve.mitre.org/" class="">the CVE process</a>.</font></li></ol><font face="HelveticaNeue" class=""><br style="caret-color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0);" class="">We’re looking for answers to the following questions:</span><br style="caret-color: rgb(0, 0, 0);" class=""></font><ol style="caret-color: rgb(0, 0, 0);" class=""><li class=""><font face="HelveticaNeue" class=""><u class="">On this list</u>: Should we create a security group and process?</font></li><li class=""><font face="HelveticaNeue" class=""><u class="">On this list</u>: Do you agree with the goals listed in the proposal?</font></li><li class=""><font face="HelveticaNeue" class=""><u class="">On this list</u>: at a high-level, what do you think should be done differently, and what do you think is exactly right in the draft proposal?</font></li><li class=""><font face="HelveticaNeue" class=""><u class="">On the Phabricator code review</u>: going into specific details, what do you think should be done differently, and what do you think is exactly right in the draft proposal?</font></li><li class=""><font face="HelveticaNeue" class=""><u class="">On this list</u>: to help understand where you’re coming from with your feedback, it would be helpful to state how you personally approach this issue:</font></li><ol class=""><li class=""><font face="HelveticaNeue" class="">Are you an LLVM contributor (individual or representing a company)?</font></li><li class=""><font face="HelveticaNeue" class="">Are you involved with security aspects of LLVM (if so, which)?</font></li><li class=""><font face="HelveticaNeue" class="">Do you maintain significant downstream LLVM changes?</font></li><li class=""><font face="HelveticaNeue" class="">Do you package and deploy LLVM for others to use (if so, to how many people)?</font></li><li class=""><font face="HelveticaNeue" class="">Is your LLVM distribution based on the open-source releases?</font></li><li class=""><font face="HelveticaNeue" class="">How often do you usually deploy LLVM?</font></li><li class=""><font face="HelveticaNeue" class="">How fast can you deploy an update?</font></li><li class=""><font face="HelveticaNeue" class="">Does your LLVM distribution handle untrusted inputs, and what kind?</font></li><li class=""><font face="HelveticaNeue" class="">What’s the threat model for your LLVM distribution?</font></li></ol></ol><font face="HelveticaNeue" class=""><br style="caret-color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0);" class="">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:</span><br style="caret-color: rgb(0, 0, 0);" class=""></font><ul style="caret-color: rgb(0, 0, 0);" class=""><li class=""><a href="https://webkit.org/security-policy/" class=""><font face="HelveticaNeue" class="">https://webkit.org/security-policy/</font></a></li><li class=""><a href="https://chromium.googlesource.com/chromium/src/+/lkgr/docs/security/faq.md" class=""><font face="HelveticaNeue" class="">https://chromium.googlesource.com/chromium/src/+/lkgr/docs/security/faq.md</font></a></li><li class=""><a href="https://wiki.mozilla.org/Security" class=""><font face="HelveticaNeue" class="">https://wiki.mozilla.org/Security</font></a></li><li class=""><a href="https://www.openbsd.org/security.html" class=""><font face="HelveticaNeue" class="">https://www.openbsd.org/security.html</font></a></li><li class=""><a href="https://security-team.debian.org/security_tracker.html" class=""><font face="HelveticaNeue" class="">https://security-team.debian.org/security_tracker.html</font></a></li><li class=""><a href="https://www.python.org/news/security/" class=""><font face="HelveticaNeue" class="">https://www.python.org/news/security/</font></a></li></ul><font face="HelveticaNeue" class=""><span style="caret-color: rgb(0, 0, 0);" class="">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.</span><br style="caret-color: rgb(0, 0, 0);" class=""><br style="caret-color: rgb(0, 0, 0);" class=""><br style="caret-color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0);" class="">I’ll go first in answering my own questions above:</span><br style="caret-color: rgb(0, 0, 0);" class=""></font><ol style="caret-color: rgb(0, 0, 0);" class=""><li class=""><font face="HelveticaNeue" class="">Yes! We should create a security group and process.</font></li><li class=""><font face="HelveticaNeue" class="">We agree with the goals listed.</font></li><li class=""><font face="HelveticaNeue" class="">We think the proposal is exactly right, but would like to hear the community’s opinions.</font></li><li class=""><font face="HelveticaNeue" class="">Here’s how we approach the security of LLVM:</font></li><ol class=""><li class=""><font face="HelveticaNeue" class="">I contribute to LLVM as an Apple employee.</font></li><li class=""><font face="HelveticaNeue" class="">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.</font></li><li class=""><font face="HelveticaNeue" class="">We maintain significant downstream changes.</font></li><li class=""><font face="HelveticaNeue" class="">We package and deploy LLVM, both internally and externally, for a variety of purposes, including the clang, Swift, and mobile GPU shader compilers.</font></li><li class=""><font face="HelveticaNeue" class="">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 <a href="https://github.com/apple" class="">https://github.com/apple</a>.</font></li><li class=""><font face="HelveticaNeue" class="">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.</font></li><li class=""><font face="HelveticaNeue" class="">This depends on which release of LLVM is affected.</font></li><li class=""><font face="HelveticaNeue" class="">Yes, our distribution sometimes handles untrusted input.</font></li><li class=""><font face="HelveticaNeue" class="">The threat model is highly variable depending on the particular language front-ends being considered.</font></li></ol></ol><font face="HelveticaNeue" class=""><span style="caret-color: rgb(0, 0, 0);" class="">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.</span><br style="caret-color: rgb(0, 0, 0);" class=""><br style="caret-color: rgb(0, 0, 0);" class=""><br style="caret-color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0);" class="">Thanks,</span><br style="caret-color: rgb(0, 0, 0);" class=""><br style="caret-color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0);" class="">JF</span></font><br style="caret-color: rgb(0, 0, 0);" class=""><div class=""><font face="HelveticaNeue" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font></div></div>_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></body></html>