From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Thomas Gleixner <tglx@linutronix.de>, "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: mchehab+samsung@kernel.org,
ksummit <ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Handling of embargoed security issues
Date: Mon, 10 Sep 2018 07:40:32 -0700 [thread overview]
Message-ID: <1536590432.4035.1.camel@HansenPartnership.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1809101026160.1402@nanos.tec.linutronix.de>
On Mon, 2018-09-10 at 11:25 +0200, Thomas Gleixner wrote:
> On Sun, 9 Sep 2018, Theodore Y. Ts'o wrote:
> > On Sun, Sep 09, 2018 at 11:17:20AM -0700, Andy Lutomirski wrote:
> > >
> > > What I want is the opposite of an NDA. I want a gentlemen’s
> > > agreement plus an explicit statement that the relevant people
> > > *may* talk about the issue among themselves despite any NDAs that
> > > might already exist. And that they may release patches when the
> > > embargo is up. And that the embargo has an end date, and that the
> > > developers may decline an extension.
> >
> > So what you're talking about is some kind of "Memo of
> > Understanding" that has no talk about "if this leaks it will Intel
> > will suffer millons and billons and zillons of dollars and Intel
> > well sue you until your assets are a smoking crater in the ground"?
> >
> > If there are no consequences to violating the Gentleman's agreement
> > (other than not being included the next time *when* another CPU
> > vulnerability comes up), then nothing really needs to be signed,
> > since it has no legal impact.
>
> 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. 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.
>
> I think this needs to have some formal setup. The way disclosure to
> companies work is through coordinators, who then disclose it
> internaly to the relevant people.
>
> We should provide something similar, i.e. an embargo coordination
> group, which coordinates the issue with the disclosing party. And
> yes, this only can be based on a general Memo of Understanding, as
> there is no way to make that whole NDA mess work when the group needs
> to bring in individual developers.
The good thing about doing this is we can set the rules for onward
disclosure from the embargo co-ordination group. We could probably get
away with something that said (co-ordinate with required linux kernel
subsystem maintainers on a need to know basis) i.e. under our rules we
could disclose to a maintainer if they needed to know without an NDA.
> Having something formal and halfways familiar in place is definitely
> something we need before we are starting to communicate and negotiate
> that through all channels.
>
> What I came up with so far is:
>
> - work out a Memo of Understanding
>
> - appoint an initial group of embargo coordinators, ideally people
> who have already an established trust relationship in the
> industry.
>
> - come up with a clear and well defined set of rules what this
> embargo group is doing and what not.
This is the key for better co-ordination. One of the rules should be
"take responsibility for determining who needs to know in the Linux
Kernel maintainer community and communicating relevant information to
them on a strict need to know basis".
It can probably be better phrased and we'd need a lawyer to look it
over because this is the point at which the NDA gives way to a
"gentleman's agreement".
James
next prev parent reply other threads:[~2018-09-10 14:40 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-06 19:18 [Ksummit-discuss] [MAINTAINERS SUMMIT] Handling of embargoed security issues 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 [this message]
2018-09-11 8:20 ` Jiri Kosina
2018-09-11 9:03 ` Thomas Gleixner
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=1536590432.4035.1.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=mchehab+samsung@kernel.org \
--cc=tglx@linutronix.de \
--cc=tytso@mit.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.