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

[Robinson, Paul via llvm-dev]

My answers to your "on the list" questions:

1. Should we create a security group and process?
SGTM.  It appears that gcc has CVEs against it, why should they have all the fun.

2. Do you agree with the goals listed in the proposal?
They also SGTM.

3. at a high-level, what do you think should be done differently, and what do you think is exactly right in the draft proposal?
The involvement of the Foundation Board to bootstrap the initial security team... seems a tad odd.  Basically you're calling for volunteers and wanting some sort of vetting process, and picked the Board to do that initially for lack of any other alternatives?  I agree that the Board should sign on to have a security team at all, that falls within their purview, but they don't need to be part of the initial selection process. The initial volunteers can demonstrate their appropriateness to each other, just like later nominees would.


And answers to "where you're coming from":

1. Are you an LLVM contributor (individual or representing a company)?
I am a contributor, as a Sony employee, and code-owner for the PS4 target.

2. Are you involved with security aspects of LLVM (if so, which)?
I have participated in security-related discussions that come up. I've recently done some work on the stack-smash protector pass; IIRC, Sony contributed the 'strong' flavor, which I reviewed.  Some years ago there was a random-nop-insertion pass (for ROP gadget removal) proposed, which didn't stick; we recently had a summer intern work on it but did not get to proper quality; I'd like to revive that.
Pre-LLVM, I spent over a decade working on OS security for DEC and Tandem.  I can’t say I’m still current on the topic, but it remains an interest.

3. Do you maintain significant downstream LLVM changes?
Yes.

4. Do you package and deploy LLVM for others to use (if so, to how many people)?
We package a Clang-based toolchain for app and game-development studios; I don't have exact numbers but the developer population is definitely in the thousands.

5. Is your LLVM distribution based on the open-source releases?
Yes; we do continuous integration from upstream master but we base our releases on the upstream release branches.

6. How often do you usually deploy LLVM?
Twice a year; rarely, we deploy hot fixes.

7. How fast can you deploy an update?
A new release based on a new upstream branch has a very long lead time (months).  We have deployed hot fixes based on a previous release in a few weeks, but we don't like to do that.

8. Does your LLVM distribution handle untrusted inputs, and what kind?
I'm unclear what you mean by this.

9. What’s the threat model for your LLVM distribution?
I can't speak to our internal security team's thoughts--we will likely want to nominate a second Sony person, from that team, to be a non-compiler-expert "vendor representative" who can better address that question.  I can say that we use the same toolchain to build our OS, as well as other sensitive software such as the browser, along with games and other apps that could engage in online transactions involving actual money.