Obsolete
Status Update
No update yet.
Comments
gm...@gmail.com
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?
Also is it possible to attach the patch to this bug report so we can see what is involved on the clang side?
th...@gmail.com
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?
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?
qu...@google.com
as...@google.com
(re-reading, my second paragraph just repeats what you already laid out. Good independent verification but apologies for not reading the dates more carefully.)
sa...@google.com
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.
* 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.
Description