linux-kernel - [PATCH 2/2] Documentation: embargoed-hardware-issues.rst: add a section documenting the "early access" process

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2024073035-bagel-vertigo-e0dd@gregkh>
Date: Tue, 30 Jul 2024 18:09:32 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: corbet@....net
Cc: workflows@...r.kernel.org,
	linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Michael Dolan <mdolan@...uxfoundation.org>
Subject: [PATCH 2/2] Documentation: embargoed-hardware-issues.rst: add a section documenting the "early access" process

Over the past years there have been many "misunderstandings" and
"confusion" as to who is, and is not, allowed early access to the
changes created by the members of the embargoed hardware issue teams
working on a specific problem.

The current process, while it does work, is "difficult" for many
companies to understand and agree with.  Because of this, there has been
numerous attempts by many companies to work around the process by lies,
subterfuge, and other side channels sometimes involving unsuspecting
lawyers.  Cut all of that out, and put the responsibility of
distributing code on the silicon vendor affected, as they already have
legal agreements in place that cover this type of distribution.  When
this distribution happens, the developers involved MUST be notified of
this happening, to be kept aware of the situation at all times.

The wording here has been hashed out by many different companies and
lawyers involved in the process, as well as community members and
everyone now agrees that the proposed change here should work better
than what is currently happening.

This change has been approved by a review from a large number of
different open source legal members, representing the companies involved
in this process.

Co-developed-by: Thomas Gleixner <tglx@...utronix.de>
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Co-developed-by: Michael Dolan <mdolan@...uxfoundation.org>
Signed-off-by: Michael Dolan <mdolan@...uxfoundation.org>
Co-developed-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
---
 .../process/embargoed-hardware-issues.rst     | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/Documentation/process/embargoed-hardware-issues.rst b/Documentation/process/embargoed-hardware-issues.rst
index 2b34bb6b7cda..daebce49cfdf 100644
--- a/Documentation/process/embargoed-hardware-issues.rst
+++ b/Documentation/process/embargoed-hardware-issues.rst
@@ -219,6 +219,37 @@ List participants may not communicate about the issue outside of the
 private mailing list. List participants may not use any shared resources
 (e.g. employer build farms, CI systems, etc) when working on patches.
 
+Early access
+""""""""""""
+
+The patches discussed and developed on the list can neither be distributed
+to any individual who is not a member of the response team nor to any other
+organization.
+
+To allow the affected silicon vendors to work with their internal teams and
+industry partners on testing, validation, and logistics, the following
+exception is provided:
+
+	Designated representatives of the affected silicon vendors are
+	allowed to hand over the patches at any time to the silicon
+	vendor’s response team. The representative must notify the kernel
+	response team about the handover. The affected silicon vendor must
+	have and maintain their own documented security process for any
+	patches shared with their response team that is consistent with
+	this policy.
+
+	The silicon vendor’s response team can distribute these patches to
+	their industry partners and to their internal teams under the
+	silicon vendor’s documented security process. Feedback from the
+	industry partners goes back to the silicon vendor and is
+	communicated by the silicon vendor to the kernel response team.
+
+	The handover to the silicon vendor’s response team removes any
+	responsibility or liability from the kernel response team regarding
+	premature disclosure, which happens due to the involvement of the
+	silicon vendor’s internal teams or industry partners. The silicon
+	vendor guarantees this release of liability by agreeing to this
+	process.
 
 Coordinated release
 """""""""""""""""""
-- 
2.45.2