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>

+31
+31
Documentation/process/embargoed-hardware-issues.rst
··· 219 private mailing list. List participants may not use any shared resources 220 (e.g. employer build farms, CI systems, etc) when working on patches. 221 222 223 Coordinated release 224 """""""""""""""""""
··· 219 private mailing list. List participants may not use any shared resources 220 (e.g. employer build farms, CI systems, etc) when working on patches. 221 222 + Early access 223 + """""""""""" 224 + 225 + The patches discussed and developed on the list can neither be distributed 226 + to any individual who is not a member of the response team nor to any other 227 + organization. 228 + 229 + To allow the affected silicon vendors to work with their internal teams and 230 + industry partners on testing, validation, and logistics, the following 231 + exception is provided: 232 + 233 + Designated representatives of the affected silicon vendors are 234 + allowed to hand over the patches at any time to the silicon 235 + vendor’s response team. The representative must notify the kernel 236 + response team about the handover. The affected silicon vendor must 237 + have and maintain their own documented security process for any 238 + patches shared with their response team that is consistent with 239 + this policy. 240 + 241 + The silicon vendor’s response team can distribute these patches to 242 + their industry partners and to their internal teams under the 243 + silicon vendor’s documented security process. Feedback from the 244 + industry partners goes back to the silicon vendor and is 245 + communicated by the silicon vendor to the kernel response team. 246 + 247 + The handover to the silicon vendor’s response team removes any 248 + responsibility or liability from the kernel response team regarding 249 + premature disclosure, which happens due to the involvement of the 250 + silicon vendor’s internal teams or industry partners. The silicon 251 + vendor guarantees this release of liability by agreeing to this 252 + process. 253 254 Coordinated release 255 """""""""""""""""""