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
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> _
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 --------------------------- _
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 """""""""""""" _
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. _
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
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
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.
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
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
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
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.
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
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 """""""""""""""""""
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>
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