tjh.dev / kernel
Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

Documentation: embargoed-hardware-issues.rst: Clarify prenotifaction

There has been a repeated misunderstanding about what the hardware embargo
list is for. Clarify the language in the process so that it is clear
that only fixes are coordinated. There is explicitly no prenotification
process. The list members are also expected to keep total radio silence
during embargoes.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: workflows@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20231004004959.work.258-kees@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

authored by

Kees Cook and committed by
Greg Kroah-Hartman 39fef15b 0f28ada1

+12 -7
+12 -7
Documentation/process/embargoed-hardware-issues.rst
··· 25 25 The Linux kernel hardware security team is separate from the regular Linux 26 26 kernel security team. 27 27 28 - The team only handles the coordination of embargoed hardware security 29 - issues. Reports of pure software security bugs in the Linux kernel are not 28 + The team only handles developing fixes for embargoed hardware security 29 + issues. Reports of pure software security bugs in the Linux kernel are not 30 30 handled by this team and the reporter will be guided to contact the regular 31 31 Linux kernel security team (:ref:`Documentation/admin-guide/ 32 32 <securitybugs>`) instead. 33 33 34 34 The team can be contacted by email at <hardware-security@kernel.org>. This 35 - is a private list of security officers who will help you to coordinate an 36 - issue according to our documented process. 35 + is a private list of security officers who will help you to coordinate a 36 + fix according to our documented process. 37 37 38 38 The list is encrypted and email to the list can be sent by either PGP or 39 39 S/MIME encrypted and must be signed with the reporter's PGP key or S/MIME ··· 132 132 133 133 The hardware security team will provide an incident-specific encrypted 134 134 mailing-list which will be used for initial discussion with the reporter, 135 - further disclosure and coordination. 135 + further disclosure, and coordination of fixes. 136 136 137 137 The hardware security team will provide the disclosing party a list of 138 138 developers (domain experts) who should be informed initially about the 139 - issue after confirming with the developers that they will adhere to this 139 + issue after confirming with the developers that they will adhere to this 140 140 Memorandum of Understanding and the documented process. These developers 141 141 form the initial response team and will be responsible for handling the 142 142 issue after initial contact. The hardware security team is supporting the ··· 209 209 After acknowledgement or resolution of an objection the expert is disclosed 210 210 by the incident team and brought into the development process. 211 211 212 + List participants may not communicate about the issue outside of the 213 + private mailing list. List participants may not use any shared resources 214 + (e.g. employer build farms, CI systems, etc) when working on patches. 215 + 212 216 213 217 Coordinated release 214 218 """"""""""""""""""" 215 219 216 220 The involved parties will negotiate the date and time where the embargo 217 221 ends. At that point the prepared mitigations are integrated into the 218 - relevant kernel trees and published. 222 + relevant kernel trees and published. There is no pre-notification process: 223 + fixes are published in public and available to everyone at the same time. 219 224 220 225 While we understand that hardware security issues need coordinated embargo 221 226 time, the embargo time should be constrained to the minimum time which is