IssueTracker

Could you CC the reviewers to this bug so that they can access it - just so we can get the relevant people involved.

Also is it possible to attach the patch to this bug report so we can see what is involved on the clang side?

adding Chandler, who will have useful opinions on landing mitigations for embargoed vulnerabilities in the LLVM tree

In the past (e.g. when Intel disclosed LVI) our approach was to have patches ready to go and pre-reviewed by appropriate (and appropriately read-in) code owners but not post the patches "for real" until the embargo lifted. Usually this was part of a larger comms strategy where announcements were made in other forums.

Is there an entity beyond security@kernel.org that's coordinating this disclosure?

(re-reading, my second paragraph just repeats what you already laid out. Good independent verification but apologies for not reading the dates more carefully.)

I don't have permission to CC folks it seems, but it would be worth adding:

* Aaron Ballman <aaron@aaronballman.com> (a code owner for clang who has already reviewed my patch off list)
* Craig Topper <craig.topper@gmail.com> (a code owner for the x86 backend who has already reviewed my patch off list)

x86 is the only confirmed architecture affected. ARM has confirmed they're not affected for their micro-architectures. Not all x86 micro-architectures are affected.  Not seeing one particular x86 vendor represented in the LLVM Security Group is...concerning.

> Also is it possible to attach the patch to this bug report so we can see what is involved on the clang side?

Yes, but just note that the LLVM code is somewhat a giveaway of what's going on here.  GCC has had a similar feature for years; they did not publish the patch under embargo but rather did so publicly back when various spectre and meltdown mitigations were being tested before the development of retpoline.  The very first comment on the GCC mailing list was along the lines of "What is this?"  I'd like to avoid that here if possible; the name of the game is to not spill the beans to too wide an audience prematurely.  Doing so would lose LLVM their (lone) seat at the table for Linux kernel vulnerability disclosures such as this.  So we need to be super careful about keeping this need to know.

> Is there an entity beyond security@kernel.org that's coordinating this disclosure?

The encrypted kernel mailing list I'm referring to that is coordinating is not that specific email address.  It's more controlled than even that list and members of that list (security@kernel.org) aren't even considered need to know for this one. I don't know whether linux-distros@vs.openwall.org has even been contacted yet; the kernel patch set is up to ~45 patches and growing, and backports will be painful.

I'm curious what you want from us, if the vulnerability is too sensitive to talk about with (or show a mitigation patch to) the people who have signed up to be responsible about security vulnerabilities.

[Empty comment from Monorail migration]

It seems like the question is: what is the best way for Nick to prepare for this patch to be available in LLVM, so it can benefit LLVM users as soon as possible after the vulnerability is disclosed?

If that's the question, I think the answer is already reached in the discussion above: to the extent possible, get the patch reviewed early by code owners and resolve any concerns there; then post the patch to Phabricator when the embargo lifts. (Absent some tricky KAISER-style subterfuge, posting the patch should be considered equivalent to a public disclosure of the vulnerability.)

Open to others on the list refining or rebutting that message, but otherwise -- Nick, is there anything else you think you need from us?