[PATCH 0/4] Documentation/process: embargoed hardware issues additions

[PATCH 0/4] Documentation/process: embargoed hardware issues additions

[Dave Hansen]

Intel will adhere to this process for future hardware embargoed
issues.  This series contains a patch from Tony Luck with him
volunteering to be Intel's ambassador for this process.

These are some minor improvements here to the process document.  I've
had the pleasure of seeing some of the problems with the various
"processes" that led to the need for this document and I think these
tweaks will help.  This part of the series is much more of an RFC than
the first patch, obviously.

Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sasha Levin <sashal@kernel.org>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Laura Abbott <labbott@redhat.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Trilok Soni <tsoni@codeaurora.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

[PATCH 1/4] Documentation/process: Volunteer as the ambassador for Intel

[Dave Hansen]

From: Tony Luck <tony.luck@intel.com>

Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sasha Levin <sashal@kernel.org>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Laura Abbott <labbott@redhat.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Trilok Soni <tsoni@codeaurora.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
---

 b/Documentation/process/embargoed-hardware-issues.rst |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -puN Documentation/process/embargoed-hardware-issues.rst~Documentation-process-Volunteer-as-the-ambassador-for-Intel Documentation/process/embargoed-hardware-issues.rst
--- a/Documentation/process/embargoed-hardware-issues.rst~Documentation-process-Volunteer-as-the-ambassador-for-Intel	2019-09-10 08:39:05.971488123 -0700
+++ b/Documentation/process/embargoed-hardware-issues.rst	2019-09-10 08:39:05.974488123 -0700
@@ -222,7 +222,7 @@ an involved disclosed party. The current
   ARM
   AMD
   IBM
-  Intel
+  Intel		Tony Luck <tony.luck@intel.com>
   Qualcomm	Trilok Soni <tsoni@codeaurora.org>
 
   Microsoft	Sasha Levin <sashal@kernel.org>
_

[PATCH 2/4] Documentation/process: describe relaxing disclosing party NDAs

[Dave Hansen]

From: Dave Hansen <dave.hansen@linux.intel.com>

Hardware companies like Intel have lots of information which they
want to disclose to some folks but not others.  Non-disclosure
agreements are a tool of choice for helping to ensure that the
flow of information is controlled.

But, they have caused problems in mitigation development.  It
can be hard for individual developers employed by companies to
figure out how they can participate, especially if their
employer is under an NDA.

To make this easier for developers, make it clear to disclosing
parties that they are expected to give permission for individuals
to participate in mitigation efforts.

Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sasha Levin <sashal@kernel.org>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Laura Abbott <labbott@redhat.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Trilok Soni <tsoni@codeaurora.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
---

 b/Documentation/process/embargoed-hardware-issues.rst |    7 +++++++
 1 file changed, 7 insertions(+)

diff -puN Documentation/process/embargoed-hardware-issues.rst~hw-sec-0 Documentation/process/embargoed-hardware-issues.rst
--- a/Documentation/process/embargoed-hardware-issues.rst~hw-sec-0	2019-09-10 08:39:02.835488131 -0700
+++ b/Documentation/process/embargoed-hardware-issues.rst	2019-09-10 08:39:02.838488131 -0700
@@ -74,6 +74,13 @@ unable to enter into any non-disclosure
 is aware of the sensitive nature of such issues and offers a Memorandum of
 Understanding instead.
 
+Disclosing parties may have shared information about an issue under a
+non-disclosure agreement with third parties.  In order to ensure that
+these agreements do not interfere with the mitigation development
+process, the disclosing party must provide explicit permission to
+participate to any response team members affected by a non-disclosure
+agreement.  Disclosing parties must resolve requests to do so in a
+timely manner.
 
 Memorandum of Understanding
 ---------------------------
_

[PATCH 3/4] Documentation/process: soften language around conference talk dates

[Dave Hansen]

From: Dave Hansen <dave.hansen@linux.intel.com>

Both hardware companies and the kernel community prefer coordinated
disclosure to the alternatives.  It is also obvious that sitting on
ready-to-go mitigations for months is not so nice for kernel
maintainers.

I want to ensure that the patched text can not be read as "the kernel
does not wait for conference dates".  I'm also fairly sure that, so
far, we *have* waited for a number of conference dates.

Change the text to make it clear that waiting for conference dates
is possible, but keep the grumbling about it being a burden.

While I think this is good for everyone, this patch represents my
personal opinion and not that of my employer.

Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sasha Levin <sashal@kernel.org>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Laura Abbott <labbott@redhat.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Trilok Soni <tsoni@codeaurora.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
---

 b/Documentation/process/embargoed-hardware-issues.rst |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff -puN Documentation/process/embargoed-hardware-issues.rst~hw-sec-1 Documentation/process/embargoed-hardware-issues.rst
--- a/Documentation/process/embargoed-hardware-issues.rst~hw-sec-1	2019-09-10 08:39:03.879488129 -0700
+++ b/Documentation/process/embargoed-hardware-issues.rst	2019-09-10 08:39:03.883488129 -0700
@@ -197,10 +197,9 @@ While we understand that hardware securi
 time, the embargo time should be constrained to the minimum time which is
 required for all involved parties to develop, test and prepare the
 mitigations. Extending embargo time artificially to meet conference talk
-dates or other non-technical reasons is creating more work and burden for
-the involved developers and response teams as the patches need to be kept
-up to date in order to follow the ongoing upstream kernel development,
-which might create conflicting changes.
+dates or other non-technical reasons is possible, but not preferred. These
+artificial extensions burden the response team with constant maintenance
+updating mitigations to follow upstream kernel development.
 
 CVE assignment
 """"""""""""""
_

[PATCH 4/4] Documentation/process: add transparency promise to list subscription

[Dave Hansen]

From: Dave Hansen <dave.hansen@linux.intel.com>

Transparency is good.  It it essential for everyone working under an
embargo to know who is involved and who else is a "knower".  Being
transparent allows everyone to always make informed decisions about
ongoing participating in a mitigation effort.

Add a step to the subscription process which will notify existing
subscribers when a new one is added.

While I think this is good for everyone, this patch represents my
personal opinion and not that of my employer.

Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sasha Levin <sashal@kernel.org>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Laura Abbott <labbott@redhat.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Trilok Soni <tsoni@codeaurora.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
---

 b/Documentation/process/embargoed-hardware-issues.rst |   13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff -puN Documentation/process/embargoed-hardware-issues.rst~hw-sec-2 Documentation/process/embargoed-hardware-issues.rst
--- a/Documentation/process/embargoed-hardware-issues.rst~hw-sec-2	2019-09-10 09:58:47.989476197 -0700
+++ b/Documentation/process/embargoed-hardware-issues.rst	2019-09-10 09:58:47.992476197 -0700
@@ -276,10 +276,11 @@ certificate. If a PGP key is used, it mu
 server and is ideally connected to the Linux kernel's PGP web of trust. See
 also: https://www.kernel.org/signature.html.
 
-The response team verifies that the subscriber request is valid and adds
-the subscriber to the list. After subscription the subscriber will receive
-email from the mailing-list which is signed either with the list's PGP key
-or the list's S/MIME certificate. The subscriber's email client can extract
-the PGP key or the S/MIME certificate from the signature so the subscriber
-can send encrypted email to the list.
+The response team verifies that the subscriber request is valid, adds the
+subscriber to the list, and notifies the existing list subscribers
+including the disclosing party. After subscription the subscriber will
+receive email from the mailing-list which is signed either with the list's
+PGP key or the list's S/MIME certificate. The subscriber's email client can
+extract the PGP key or the S/MIME certificate from the signature so the
+subscriber can send encrypted email to the list.
 
_

Re: [PATCH 2/4] Documentation/process: describe relaxing disclosing party NDAs

[Sasha Levin]

On Tue, Sep 10, 2019 at 10:26:49AM -0700, Dave Hansen wrote:
>
>From: Dave Hansen <dave.hansen@linux.intel.com>
>
>Hardware companies like Intel have lots of information which they
>want to disclose to some folks but not others.  Non-disclosure
>agreements are a tool of choice for helping to ensure that the
>flow of information is controlled.
>
>But, they have caused problems in mitigation development.  It
>can be hard for individual developers employed by companies to
>figure out how they can participate, especially if their
>employer is under an NDA.
>
>To make this easier for developers, make it clear to disclosing
>parties that they are expected to give permission for individuals
>to participate in mitigation efforts.
>
>Cc: Jonathan Corbet <corbet@lwn.net>
>Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>Cc: Sasha Levin <sashal@kernel.org>
>Cc: Ben Hutchings <ben@decadent.org.uk>
>Cc: Thomas Gleixner <tglx@linutronix.de>
>Cc: Laura Abbott <labbott@redhat.com>
>Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>Cc: Trilok Soni <tsoni@codeaurora.org>
>Cc: Kees Cook <keescook@chromium.org>
>Cc: Tony Luck <tony.luck@intel.com>
>Cc: linux-doc@vger.kernel.org
>Cc: linux-kernel@vger.kernel.org
>Acked-by: Dan Williams <dan.j.williams@intel.com>
>Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
>---
>
> b/Documentation/process/embargoed-hardware-issues.rst |    7 +++++++
> 1 file changed, 7 insertions(+)
>
>diff -puN Documentation/process/embargoed-hardware-issues.rst~hw-sec-0 Documentation/process/embargoed-hardware-issues.rst
>--- a/Documentation/process/embargoed-hardware-issues.rst~hw-sec-0	2019-09-10 08:39:02.835488131 -0700
>+++ b/Documentation/process/embargoed-hardware-issues.rst	2019-09-10 08:39:02.838488131 -0700
>@@ -74,6 +74,13 @@ unable to enter into any non-disclosure
> is aware of the sensitive nature of such issues and offers a Memorandum of
> Understanding instead.
>
>+Disclosing parties may have shared information about an issue under a
>+non-disclosure agreement with third parties.  In order to ensure that
>+these agreements do not interfere with the mitigation development
>+process, the disclosing party must provide explicit permission to
>+participate to any response team members affected by a non-disclosure
>+agreement.  Disclosing parties must resolve requests to do so in a
>+timely manner.

Can giving the permission be made explicitly along with the disclosure?
If it's disclosed with Microsoft under NDA, it makes it tricky for me to
participate in the "response team" context here unless premission is
given to do so.

--
Thanks,
Sasha

Re: [PATCH 0/4] Documentation/process: embargoed hardware issues additions

[Greg KH]

On Tue, Sep 10, 2019 at 10:26:44AM -0700, Dave Hansen wrote:
> Intel will adhere to this process for future hardware embargoed
> issues.  This series contains a patch from Tony Luck with him
> volunteering to be Intel's ambassador for this process.
> 
> These are some minor improvements here to the process document.  I've
> had the pleasure of seeing some of the problems with the various
> "processes" that led to the need for this document and I think these
> tweaks will help.  This part of the series is much more of an RFC than
> the first patch, obviously.

I've applied patch 1 to the tree, thank you for that.

The other patches will take a bit more to think about, and calm down
about, before I'll respond.  Please wait until next week for that...

thanks,

greg k-h

Re: [PATCH 2/4] Documentation/process: describe relaxing disclosing party NDAs

[Dave Hansen]

On 9/11/19 3:11 AM, Sasha Levin wrote:
>> +Disclosing parties may have shared information about an issue under a
>> +non-disclosure agreement with third parties.  In order to ensure that
>> +these agreements do not interfere with the mitigation development
>> +process, the disclosing party must provide explicit permission to
>> +participate to any response team members affected by a non-disclosure
>> +agreement.  Disclosing parties must resolve requests to do so in a
>> +timely manner.
> 
> Can giving the permission be made explicitly along with the disclosure?
> If it's disclosed with Microsoft under NDA, it makes it tricky for me to
> participate in the "response team" context here unless premission is
> given to do so.

Hi Sasha,

It is probably possible to do in advance.  But, probably only if we list
the folks for which it needs to be done in advance in the process file.
 It makes a lot of sense to have the stable maintainers as permanent
members of any response team.

But, I was hoping what I described above would be a bit more flexible
than needing to have a list.  The downside is that the response team
needs to explicitly ask every time for folks like you to be included.

Re: [PATCH 2/4] Documentation/process: describe relaxing disclosing party NDAs

[Greg KH]

On Tue, Sep 10, 2019 at 10:26:49AM -0700, Dave Hansen wrote:
> 
> From: Dave Hansen <dave.hansen@linux.intel.com>
> 
> Hardware companies like Intel have lots of information which they
> want to disclose to some folks but not others.  Non-disclosure
> agreements are a tool of choice for helping to ensure that the
> flow of information is controlled.
> 
> But, they have caused problems in mitigation development.  It
> can be hard for individual developers employed by companies to
> figure out how they can participate, especially if their
> employer is under an NDA.
> 
> To make this easier for developers, make it clear to disclosing
> parties that they are expected to give permission for individuals
> to participate in mitigation efforts.
> 
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Sasha Levin <sashal@kernel.org>
> Cc: Ben Hutchings <ben@decadent.org.uk>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Laura Abbott <labbott@redhat.com>
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> Cc: Trilok Soni <tsoni@codeaurora.org>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Tony Luck <tony.luck@intel.com>
> Cc: linux-doc@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Acked-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> ---
> 
>  b/Documentation/process/embargoed-hardware-issues.rst |    7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff -puN Documentation/process/embargoed-hardware-issues.rst~hw-sec-0 Documentation/process/embargoed-hardware-issues.rst
> --- a/Documentation/process/embargoed-hardware-issues.rst~hw-sec-0	2019-09-10 08:39:02.835488131 -0700
> +++ b/Documentation/process/embargoed-hardware-issues.rst	2019-09-10 08:39:02.838488131 -0700
> @@ -74,6 +74,13 @@ unable to enter into any non-disclosure
>  is aware of the sensitive nature of such issues and offers a Memorandum of
>  Understanding instead.
>  
> +Disclosing parties may have shared information about an issue under a
> +non-disclosure agreement with third parties.  In order to ensure that
> +these agreements do not interfere with the mitigation development
> +process, the disclosing party must provide explicit permission to
> +participate to any response team members affected by a non-disclosure
> +agreement.  Disclosing parties must resolve requests to do so in a
> +timely manner.

I wrote a fun long rant of a response here, but deleted it so now I feel
better.  But that doesn't help anyone but myself, so here's my censored
response instead...

Intel had months of review time for this document before this was
published.  Your lawyers had it and never objected to this lack of
inclusion at all, and explictitly said that the document as written was
fine with them.  So I'm sorry, but it is much too late to add something
like this to the document at this point in time.

If your legal department has any remaining objections like this, please
bring it up in the proper legal forum where all of the other companies
that already discussed this in can review and discuss it.  As it is,
including something like this would require their buy-in anyway, and
obviously that did not happen with this proposal.

So no, I'm not going to apply this change, sorry.

Oh, and cute use of the term, "timely manner", as if we are going to
fall for that one again... :)

greg k-h

Re: [PATCH 3/4] Documentation/process: soften language around conference talk dates

[Greg KH]

On Tue, Sep 10, 2019 at 10:26:51AM -0700, Dave Hansen wrote:
> 
> From: Dave Hansen <dave.hansen@linux.intel.com>
> 
> Both hardware companies and the kernel community prefer coordinated
> disclosure to the alternatives.  It is also obvious that sitting on
> ready-to-go mitigations for months is not so nice for kernel
> maintainers.
> 
> I want to ensure that the patched text can not be read as "the kernel
> does not wait for conference dates".  I'm also fairly sure that, so
> far, we *have* waited for a number of conference dates.

We have been "forced" to wait for conference dates.  That is much
different from what we are saying here (i.e. we do NOT want to have to
wait for that type of thing as that causes us all real work that is a
total waste of engineering effort.)

> Change the text to make it clear that waiting for conference dates
> is possible, but keep the grumbling about it being a burden.

I don't think we want that, waiting for long periods of time like we
have been (and are currently) is a royal pain.  We are glad to take
these on a case-by-case basis, but doing delays for no other reason than
a specific conference date 6 months in the future when we have fixes now
benifits no one at all, and in fact HURTS everyone involved, including
our users the most.

> While I think this is good for everyone, this patch represents my
> personal opinion and not that of my employer.

I appreciate the disclaimer :)

I know Thomas and others are totally busy with Plumbers right now (as am
I), so I'll hold on to this and your next patch in my "to-review" queue
to give others a chance to weigh in on the tweaks to see if anyone
disagrees with my comments above.

thanks,

greg k-h

Re: [PATCH 4/4] Documentation/process: add transparency promise to list subscription

[Greg KH]

On Tue, Sep 10, 2019 at 10:26:52AM -0700, Dave Hansen wrote:
> 
> From: Dave Hansen <dave.hansen@linux.intel.com>
> 
> Transparency is good.  It it essential for everyone working under an
> embargo to know who is involved and who else is a "knower".  Being
> transparent allows everyone to always make informed decisions about
> ongoing participating in a mitigation effort.
> 
> Add a step to the subscription process which will notify existing
> subscribers when a new one is added.

As I don't run the mailing list software here, I don't know how much of
a burden adding this support to it would be, so I'll defer to Thomas.

We could just have something like "All new people need to announce
themselves" rule like many other private mailing lists have at times.
That would put the burden on the new person once, instead of the list
manager for every time a new person is added.

thanks,

greg k-h

Re: [PATCH 2/4] Documentation/process: describe relaxing disclosing party NDAs

[Dave Hansen]

On 9/11/19 8:44 AM, Greg KH wrote:
> Intel had months of review time for this document before this was
> published.  Your lawyers had it and never objected to this lack of
> inclusion at all, and explictitly said that the document as written was
> fine with them.  So I'm sorry, but it is much too late to add something
> like this to the document at this point in time.

Hi Greg,

I'll personally take 100% of the blame for this patch.  I intended for
it to show our commitment to work *with* our colleagues in the
community, not to dictate demands.  Please consider this as you would
any other patch: a humble suggestion to address what I see as a gap.

Just to be clear: this addition came from me and only me.  It did not
come from any Intel lawyers and does not represent any kind of objection
to the process.  Intel's support for this process is unconditional and
not dependent on any of these patches.

> Oh, and cute use of the term, "timely manner", as if we are going to
> fall for that one again... 

Oh, I think that was actually a quote from an email from Thomas
explaining how he wanted these things dealt with.  If you change youer
mind and are open to improvements to this process in the future, I'd be
happy to change this to some kind of explicit deadline if that's preferred.

Re: [PATCH 4/4] Documentation/process: add transparency promise to list subscription

[Thomas Gleixner]

On Wed, 11 Sep 2019, Greg KH wrote:
> On Tue, Sep 10, 2019 at 10:26:52AM -0700, Dave Hansen wrote:
> > 
> > From: Dave Hansen <dave.hansen@linux.intel.com>
> > 
> > Transparency is good.  It it essential for everyone working under an
> > embargo to know who is involved and who else is a "knower".  Being
> > transparent allows everyone to always make informed decisions about
> > ongoing participating in a mitigation effort.
> > 
> > Add a step to the subscription process which will notify existing
> > subscribers when a new one is added.
> 
> As I don't run the mailing list software here, I don't know how much of
> a burden adding this support to it would be, so I'll defer to Thomas.
> 
> We could just have something like "All new people need to announce
> themselves" rule like many other private mailing lists have at times.
> That would put the burden on the new person once, instead of the list
> manager for every time a new person is added.

That's trivial and can be fully automated into the list scripts. I'll put
that on to the todo list as I'm in the process of cleaning stuff up and
fixing the documentation before pushing the whole pile out.

Thanks,

	tglx

[PATCH] Documentation/process: Clarify disclosure rules

[Thomas Gleixner]

The role of the contact list provided by the disclosing party and how it
affects the disclosure process and the ability to include experts into
the development process is not really well explained.

Neither is it entirely clear when the disclosing party will be informed
about the fact that a developer who is not covered by an employer NDA needs
to be brought in and disclosed.

Explain the role of the contact list and the information policy along with
an eventual conflict resolution better.

Reported-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 Documentation/process/embargoed-hardware-issues.rst |   40 ++++++++++++++++----
 1 file changed, 33 insertions(+), 7 deletions(-)

--- a/Documentation/process/embargoed-hardware-issues.rst
+++ b/Documentation/process/embargoed-hardware-issues.rst
@@ -143,6 +143,20 @@ via their employer, they cannot enter in
 in their role as Linux kernel developers. They will, however, agree to
 adhere to this documented process and the Memorandum of Understanding.
 
+The disclosing party should provide a list of contacts for all other
+entities who have already been, or should be, informed about the issue.
+This serves several purposes:
+
+ - The list of disclosed entities allows communication accross the
+   industry, e.g. other OS vendors, HW vendors, etc.
+
+ - The disclosed entities can be contacted to name experts who should
+   participate in the mitigation development.
+
+ - If an expert which is required to handle an issue is employed by an
+   listed entity or member of an listed entity, then the response teams can
+   request the disclosure of that expert from that entity. This ensures
+   that the expert is also part of the entity's response team.
 
 Disclosure
 """"""""""
@@ -158,10 +172,7 @@ Mitigation development
 """"""""""""""""""""""
 
 The initial response team sets up an encrypted mailing-list or repurposes
-an existing one if appropriate. The disclosing party should provide a list
-of contacts for all other parties who have already been, or should be,
-informed about the issue. The response team contacts these parties so they
-can name experts who should be subscribed to the mailing-list.
+an existing one if appropriate.
 
 Using a mailing-list is close to the normal Linux development process and
 has been successfully used in developing mitigations for various hardware
@@ -175,9 +186,24 @@ development branch against the mainline
 stable kernel versions as necessary.
 
 The initial response team will identify further experts from the Linux
-kernel developer community as needed and inform the disclosing party about
-their participation. Bringing in experts can happen at any time of the
-development process and often needs to be handled in a timely manner.
+kernel developer community as needed. Bringing in experts can happen at any
+time of the development process and needs to be handled in a timely manner.
+
+If an expert is employed by or member of an entity on the disclosure list
+provided by the disclosing party, then participation will be requested from
+the relevant entity.
+
+If not, then the disclosing party will be informed about the experts
+participation. The experts are covered by the Memorandum of Understanding
+and the disclosing party is requested to acknowledge the participation. In
+case that the disclosing party has a compelling reason to object, then this
+objection has to be raised within five work days and resolved with the
+incident team immediately. If the disclosing party does not react within
+five work days this is taken as silent acknowledgement.
+
+After acknowledgement or resolution of an objection the expert is disclosed
+by the incident team and brought into the development process.
+
 
 Coordinated release
 """""""""""""""""""

Re: [PATCH] Documentation/process: Clarify disclosure rules

[Dave Hansen]

On 9/25/19 1:29 AM, Thomas Gleixner wrote:
> The role of the contact list provided by the disclosing party and how it
> affects the disclosure process and the ability to include experts into
> the development process is not really well explained.
> 
> Neither is it entirely clear when the disclosing party will be informed
> about the fact that a developer who is not covered by an employer NDA needs
> to be brought in and disclosed.
> 
> Explain the role of the contact list and the information policy along with
> an eventual conflict resolution better.

This addresses the concerns I had about individuals who the community
needs to participate but which might be encumbered by an agreement
between their employer and the disclosing party.

To be explicit, this ack does not represent any official Intel position
and has not been reviewed by anyone at Intel other than me.

Acked-by: Dave Hansen <dave.hansen@linux.intel.com>

Re: [PATCH 2/4] Documentation/process: describe relaxing disclosing party NDAs

[Greg KH]

On Wed, Sep 11, 2019 at 09:09:18AM -0700, Dave Hansen wrote:
> On 9/11/19 8:44 AM, Greg KH wrote:
> > Intel had months of review time for this document before this was
> > published.  Your lawyers had it and never objected to this lack of
> > inclusion at all, and explictitly said that the document as written was
> > fine with them.  So I'm sorry, but it is much too late to add something
> > like this to the document at this point in time.
> 
> Hi Greg,
> 
> I'll personally take 100% of the blame for this patch.  I intended for
> it to show our commitment to work *with* our colleagues in the
> community, not to dictate demands.  Please consider this as you would
> any other patch: a humble suggestion to address what I see as a gap.
> 
> Just to be clear: this addition came from me and only me.  It did not
> come from any Intel lawyers and does not represent any kind of objection
> to the process.  Intel's support for this process is unconditional and
> not dependent on any of these patches.

Ok, thanks for the clarification.  It looked like this came from Intel
based on the comments you made on the other patches in this series.  My
confusion, sorry.

I think that Thomas's rewording here makes more sense, and you seem to
agree, so I'll go queue that up now.

thanks,

greg k-h