Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Handling of embargoed security issues

[Thomas Gleixner <tglx@linutronix.de>]

On Fri, 7 Sep 2018, Andy Lutomirski wrote:
> (There was another CVE that got much less press that I was involved,
> and it didn't get much attention in Linux land because Linux was only
> minimally affected.  Despite being an Intel/AMD issue, all of the
> coordination was done by Microsoft, and it was done remarkably well
> once the process actually got started.)

The point is that the coordination done by the entity who 'owns' the thing
is the key.

Contrary to Meltdown/Spectre Intel informed us about L1Tf halfways early
and allowed _all_ involved parties to talk to each other. There were still
some rough edges to bring key people like Greg in, but that was a minor
nuisance compared to the whole Meltdown/Spectre mess.

Of course there was no communication channel which allowed us to talk in a
workable way, but that got resolved by ourself setting up a encrypted
mailing list which made halfways normal kernel style cooperation
possible. That still has its rough edges vs. limited review capacity and
testing, but compared to Meltdown/Spectre L1TF was halfways workable.

So we surely have the ability to communicate properly in an embargo
situation, but that requires that the entity who controls the issue is

 1) Telling us in time and putting all cards on the table
 2) Setting no silly restrictions vs. who can talk to whom

That said, I agree that a more formal process with clear rules might make
it easier for companies to handle that proper. It's definitely worth to
try.

Though it won't make the issues which come inherently with embargo
development go away. Mechanisms we rely on like 0-bot, kernel-ci and others
need to grow an embargo mode as well.

Thanks,

	tglx