From: Thomas Gleixner <tglx@linutronix.de>
To: Jiri Kosina <jikos@kernel.org>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
mchehab+samsung@kernel.org,
ksummit <ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Handling of embargoed security issues
Date: Tue, 11 Sep 2018 11:03:25 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.21.1809111050280.5110@nanos.tec.linutronix.de> (raw)
In-Reply-To: <nycvar.YFH.7.76.1809111013260.15880@cbobk.fhfr.pm>
On Tue, 11 Sep 2018, Jiri Kosina wrote:
> On Mon, 10 Sep 2018, Thomas Gleixner wrote:
>
> > Looking at SSBD/L1TF only and ignoring the Meltdown/Spectre disaster (which
> > was completely FUBARed by Intel), having something like this in place could
> > have certainly solved the main gap which we had. We were able to
> > communicate freely between the informed parties and their allowed to know
> > kernel developers, even accross vendors.
>
> Agreed, this worked pretty well this time.
>
> > But there was no simple way to bring in anybody else. It tooks us almost
> > 2 months to get GregKH on board, but there was no way to talk to e.g.
> > the BPF folks in time.
>
> But this was what has caused real pain indeed. Do we know / can it be
> publicly said what exactly was the issue in those cases? Was it perhaps
> that those people were not employed by a company the disclosing party had
> a NDA in place already (like it probably had with all the involved
> vendors, etc)?
Greg is not employed by one of the companies to which the issue was
disclosed and had no NDA in place. AFAIK he's not doing the NDA mess
either, so it took time to sort it out.
For others, who were not employed by one of the involved parties and were
not covered by some magic NDA construct, we just gave up because at the
point we realized that we need their expertise it was way too late to wait
a couple of month/weeks to get that sorted.
That's where I see the embargo coordination to have it's place. If the
people working on the embargoed issue need the expertise of somebody who is
not covered in one way or the other, then the embargo team can disclose it
due to technical necessarity and based on trust.
And I can see that working, because if someone gets pulled in and spills
the beans then he has not only violated the trust put into him for this
particular embargo issue, he also killed his reputation and trust
relationships in the community as a whole.
I doubt that any coordinator in a company - despite the whole NDA/work
contract/whatever stuff in place - will disclose a sensitive embargo issue
to an engineer whom he doesn't trust fully.
Thanks,
tglx
next prev parent reply other threads:[~2018-09-11 9:03 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-06 19:18 Jiri Kosina
2018-09-06 20:56 ` Linus Torvalds
2018-09-06 21:14 ` Jiri Kosina
2018-09-06 22:51 ` Eduardo Valentin
2018-09-07 9:17 ` Jani Nikula
2018-09-07 14:43 ` David Woodhouse
2018-09-06 22:55 ` Eduardo Valentin
2018-09-07 8:21 ` Geert Uytterhoeven
2018-09-10 23:26 ` Eduardo Valentin
2018-09-11 8:45 ` Greg KH
2018-09-11 17:10 ` Dave Hansen
2018-09-11 18:28 ` Greg KH
2018-09-11 18:44 ` Thomas Gleixner
2018-09-07 13:30 ` Jiri Kosina
2018-09-09 12:55 ` Greg KH
2018-09-09 19:48 ` Jiri Kosina
2018-09-10 4:04 ` Eduardo Valentin
2018-09-12 7:03 ` Greg KH
2018-09-10 4:12 ` Eduardo Valentin
2018-09-10 11:10 ` Mark Brown
2018-09-12 4:22 ` Balbir Singh
2018-09-08 4:21 ` Andy Lutomirski
2018-09-08 8:56 ` Thomas Gleixner
2018-09-08 11:21 ` Mauro Carvalho Chehab
2018-09-08 11:34 ` Greg KH
2018-09-08 14:20 ` Andy Lutomirski
2018-09-08 15:29 ` Greg KH
2018-09-08 15:00 ` James Bottomley
2018-09-08 15:32 ` Greg KH
2018-09-08 15:54 ` James Bottomley
2018-09-08 19:49 ` Linus Torvalds
2018-09-08 21:24 ` James Bottomley
2018-09-08 22:33 ` Andy Lutomirski
2018-09-09 12:18 ` Mauro Carvalho Chehab
2018-09-10 22:59 ` Dave Hansen
2018-09-11 8:48 ` Greg KH
2018-09-09 12:51 ` Greg KH
2018-09-09 14:20 ` Linus Torvalds
2018-09-09 14:38 ` James Bottomley
2018-09-09 14:51 ` Andy Lutomirski
2018-09-09 17:20 ` Theodore Y. Ts'o
2018-09-09 17:48 ` David Woodhouse
2018-09-09 18:17 ` Andy Lutomirski
2018-09-09 18:56 ` Theodore Y. Ts'o
2018-09-09 19:19 ` Andy Lutomirski
2018-09-09 20:20 ` Jiri Kosina
2018-09-09 21:36 ` James Bottomley
2018-09-10 9:25 ` Thomas Gleixner
2018-09-10 14:40 ` James Bottomley
2018-09-11 8:20 ` Jiri Kosina
2018-09-11 9:03 ` Thomas Gleixner [this message]
2018-09-09 19:41 ` Jiri Kosina
2018-09-08 19:26 ` Jiri Kosina
2018-09-08 19:47 ` James Bottomley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.21.1809111050280.5110@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=James.Bottomley@HansenPartnership.com \
--cc=jikos@kernel.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=mchehab+samsung@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox