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. Link: https://lore.kernel.org/r/2024073035-bagel-vertigo-e0dd@gregkh Co-developed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Co-developed-by: Michael Dolan <mdolan@linuxfoundation.org> Signed-off-by: Michael Dolan <mdolan@linuxfoundation.org> Co-developed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit is contained in:
parent
a2e4bdca2c
commit
86fee2877f
@ -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
|
||||
"""""""""""""""""""
|
||||
|
Loading…
Reference in New Issue
Block a user