On Thu, 25 Jul 2019, Greg Kroah-Hartman wrote:
> To address the requirements of embargoed hardware issues, like Meltdown,
> Spectre, L1TF, etc. it is necessary to define and document a process for
> handling embargoed hardware security issues.
I don't know what exactly went wrong, but there is a much more up-to-date
version of that document (especially when it comes to vendor contacts),
which I sent around on Thu, 2 May 2019 20:23:48 +0200 (CEST) already.
Please find it below.
From: Jiri Kosina
Subject: [PATCH] Documentation/admin-guide: Embargoed hardware security issues
To address the requirements of embargoed hardware issues, like Meltdown,
Spectre, L1TF etc. it is necessary to define and document a process for
handling embargoed hardware security issues.
Following the discussion at the maintainer summit 2018 in Edinburgh
(https://lwn.net/Articles/769417/) the volunteered people have worked
out a process and a Memorandum of Understanding. The latter addresses
the fact that the Linux kernel community cannot sign NDAs for various
reasons.
The initial contact point for hardware security issues is different from
the regular kernel security contact to provide a known and neutral
interface for hardware vendors and researchers. The initial primary
contact team is proposed to be staffed by Linux Foundation Fellows, who
are not associated to a vendor or a distribution and are well connected
in the industry as a whole.
The process is designed with the experience of the past incidents in mind
and tries to address the remaining gaps, so future (hopefully rare)
incidents can be handled more efficiently. It won't remove the fact, that
most of this has to be done behind closed doors, but it is set up to avoid
big bureaucratic hurdles for individual developers.
The process is solely for handling hardware security issues and cannot
be used for regular kernel (software only) security bugs.
To accelerate the adoption of this process, we introduce the concept of
ambassadors in participating companies. The ambassadors are there to
guide people to comply with the process, but are not automatically
involved in the disclosure of a particular incident.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Josh Poimboeuf
Acked-by: Laura Abbott
Acked-by: Ben Hutchings
Reviewed-by: Tyler Hicks
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Jiri Kosina
---
v6 -> v7: added contacts (and Acks/Reviewed-bys) for distro people
fixed spelling of Red Hat
fixed spelling of SUSE
v5 -> v6: legal review and minor wording and line-wrapping changes
Fixed Jiri's email address
V4 -> V5: Fix the last bits (LF and space/tab)
V3 -> V4: Addressed review comments
Added changelog
Added Google and Amazon to the ambassador list. Is there
any company missing?
.../admin-guide/embargoed-hardware-issues.rst | 281 +
Documentation/admin-guide/index.rst| 1 +
2 files changed, 282 insertions(+)
create mode 100644 Documentation/admin-guide/embargoed-hardware-issues.rst
diff --git a/Documentation/admin-guide/embargoed-hardware-issues.rst
b/Documentation/admin-guide/embargoed-hardware-issues.rst
new file mode 100644
index ..0bc4d01e13dd
--- /dev/null
+++ b/Documentation/admin-guide/embargoed-hardware-issues.rst
@@ -0,0 +1,281 @@
+.. _embargoedhardwareissues:
+
+Embargoed hardware issues
+=
+
+Scope
+-
+
+Hardware issues which result in security problems are a different category
+of security bugs than pure software bugs which only affect the Linux
+kernel.
+
+Hardware issues like Meltdown, Spectre, L1TF etc. must be treated
+differently because they usually affect all Operating Systems (???OS???) and
+therefore need coordination across different OS vendors, distributions,
+hardware vendors and other parties. For some of the issues, software
+mitigations can depend on microcode or firmware updates, which need further
+coordination.
+
+.. _Contact:
+
+Contact
+---
+
+The Linux kernel hardware security team is separate from the regular Linux
+kernel security team.
+
+The team is only handling the coordination of embargoed hardware security
+issues. Reports of pure software security bugs in the Linux kernel are not
+handled by this team and the reporter will be guided to contact the regular
+Linux kernel security team (:ref:`Documentation/admin-guide/
+`) instead.
+
+The team can be contacted by email at . This
+is a private list of security officers who will help you to coordinate an
+issue according to our documented process.
+
+The list is encrypted and email to the list can be sent by either PGP or
+S/MIME encrypted and must be signed with the reporter's PGP key or S/MIME
+certificate. The list's PGP key and S/MIME certificate are available from
+https://www.kernel.org/
+
+While hardware security issues are often handled by the affected hardware
+vendor,
