Merge tag 'v6.11-rc6' into docs-mw
This is done primarily to get a docs build fix merged via another tree so that "make htmldocs" stops failing.
This commit is contained in:
Jonathan Corbet
@@ -629,18 +629,6 @@ The preferred style for long (multi-line) comments is:
|
||||
* with beginning and ending almost-blank lines.
|
||||
*/
|
||||
|
||||
For files in net/ and drivers/net/ the preferred style for long (multi-line)
|
||||
comments is a little different.
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
/* The preferred comment style for files in net/ and drivers/net
|
||||
* looks like this.
|
||||
*
|
||||
* It is nearly the same as the generally preferred comment style,
|
||||
* but there is no initial almost-blank line.
|
||||
*/
|
||||
|
||||
It's also important to comment data, whether they are basic types or derived
|
||||
types. To this end, use just one data declaration per line (no commas for
|
||||
multiple data declarations). This leaves you room for a small comment on each
|
||||
|
||||
@@ -13,9 +13,9 @@ 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.
|
||||
silicon vendors, hardware integrators, and other parties. For some of the
|
||||
issues, software mitigations can depend on microcode or firmware updates,
|
||||
which need further coordination.
|
||||
|
||||
.. _Contact:
|
||||
|
||||
@@ -32,8 +32,8 @@ Linux kernel security team (:ref:`Documentation/admin-guide/
|
||||
<securitybugs>`) instead.
|
||||
|
||||
The team can be contacted by email at <hardware-security@kernel.org>. This
|
||||
is a private list of security officers who will help you to coordinate a
|
||||
fix according to our documented process.
|
||||
is a private list of security officers who will help you coordinate a fix
|
||||
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
|
||||
@@ -43,7 +43,7 @@ the following URLs:
|
||||
- PGP: https://www.kernel.org/static/files/hardware-security.asc
|
||||
- S/MIME: https://www.kernel.org/static/files/hardware-security.crt
|
||||
|
||||
While hardware security issues are often handled by the affected hardware
|
||||
While hardware security issues are often handled by the affected silicon
|
||||
vendor, we welcome contact from researchers or individuals who have
|
||||
identified a potential hardware flaw.
|
||||
|
||||
@@ -65,7 +65,7 @@ of Linux Foundation's IT operations personnel technically have the
|
||||
ability to access the embargoed information, but are obliged to
|
||||
confidentiality by their employment contract. Linux Foundation IT
|
||||
personnel are also responsible for operating and managing the rest of
|
||||
kernel.org infrastructure.
|
||||
kernel.org's infrastructure.
|
||||
|
||||
The Linux Foundation's current director of IT Project infrastructure is
|
||||
Konstantin Ryabitsev.
|
||||
@@ -85,7 +85,7 @@ Memorandum of Understanding
|
||||
|
||||
The Linux kernel community has a deep understanding of the requirement to
|
||||
keep hardware security issues under embargo for coordination between
|
||||
different OS vendors, distributors, hardware vendors and other parties.
|
||||
different OS vendors, distributors, silicon vendors, and other parties.
|
||||
|
||||
The Linux kernel community has successfully handled hardware security
|
||||
issues in the past and has the necessary mechanisms in place to allow
|
||||
@@ -103,11 +103,11 @@ the issue in the best technical way.
|
||||
All involved developers pledge to adhere to the embargo rules and to keep
|
||||
the received information confidential. Violation of the pledge will lead to
|
||||
immediate exclusion from the current issue and removal from all related
|
||||
mailing-lists. In addition, the hardware security team will also exclude
|
||||
mailing lists. In addition, the hardware security team will also exclude
|
||||
the offender from future issues. The impact of this consequence is a highly
|
||||
effective deterrent in our community. In case a violation happens the
|
||||
hardware security team will inform the involved parties immediately. If you
|
||||
or anyone becomes aware of a potential violation, please report it
|
||||
or anyone else becomes aware of a potential violation, please report it
|
||||
immediately to the Hardware security officers.
|
||||
|
||||
|
||||
@@ -124,14 +124,16 @@ method for these types of issues.
|
||||
Start of Disclosure
|
||||
"""""""""""""""""""
|
||||
|
||||
Disclosure starts by contacting the Linux kernel hardware security team by
|
||||
email. This initial contact should contain a description of the problem and
|
||||
a list of any known affected hardware. If your organization builds or
|
||||
distributes the affected hardware, we encourage you to also consider what
|
||||
other hardware could be affected.
|
||||
Disclosure starts by emailing the Linux kernel hardware security team per
|
||||
the Contact section above. This initial contact should contain a
|
||||
description of the problem and a list of any known affected silicon. If
|
||||
your organization builds or distributes the affected hardware, we encourage
|
||||
you to also consider what other hardware could be affected. The disclosing
|
||||
party is responsible for contacting the affected silicon vendors in a
|
||||
timely manner.
|
||||
|
||||
The hardware security team will provide an incident-specific encrypted
|
||||
mailing-list which will be used for initial discussion with the reporter,
|
||||
mailing list which will be used for initial discussion with the reporter,
|
||||
further disclosure, and coordination of fixes.
|
||||
|
||||
The hardware security team will provide the disclosing party a list of
|
||||
@@ -158,8 +160,8 @@ This serves several purposes:
|
||||
- The disclosed entities can be contacted to name experts who should
|
||||
participate in the mitigation development.
|
||||
|
||||
- If an expert which is required to handle an issue is employed by an
|
||||
listed entity or member of an listed entity, then the response teams can
|
||||
- If an expert who is required to handle an issue is employed by a listed
|
||||
entity or member of an listed entity, then the response teams can
|
||||
request the disclosure of that expert from that entity. This ensures
|
||||
that the expert is also part of the entity's response team.
|
||||
|
||||
@@ -169,8 +171,8 @@ Disclosure
|
||||
The disclosing party provides detailed information to the initial response
|
||||
team via the specific encrypted mailing-list.
|
||||
|
||||
From our experience the technical documentation of these issues is usually
|
||||
a sufficient starting point and further technical clarification is best
|
||||
From our experience, the technical documentation of these issues is usually
|
||||
a sufficient starting point, and further technical clarification is best
|
||||
done via email.
|
||||
|
||||
Mitigation development
|
||||
@@ -179,57 +181,93 @@ Mitigation development
|
||||
The initial response team sets up an encrypted mailing-list or repurposes
|
||||
an existing one if appropriate.
|
||||
|
||||
Using a mailing-list is close to the normal Linux development process and
|
||||
has been successfully used in developing mitigations for various hardware
|
||||
Using a mailing list is close to the normal Linux development process and
|
||||
has been successfully used to develop mitigations for various hardware
|
||||
security issues in the past.
|
||||
|
||||
The mailing-list operates in the same way as normal Linux development.
|
||||
Patches are posted, discussed and reviewed and if agreed on applied to a
|
||||
non-public git repository which is only accessible to the participating
|
||||
The mailing list operates in the same way as normal Linux development.
|
||||
Patches are posted, discussed, and reviewed and if agreed upon, applied to
|
||||
a non-public git repository which is only accessible to the participating
|
||||
developers via a secure connection. The repository contains the main
|
||||
development branch against the mainline kernel and backport branches for
|
||||
stable kernel versions as necessary.
|
||||
|
||||
The initial response team will identify further experts from the Linux
|
||||
kernel developer community as needed. Bringing in experts can happen at any
|
||||
time of the development process and needs to be handled in a timely manner.
|
||||
kernel developer community as needed. Any involved party can suggest
|
||||
further experts to be included, each of which will be subject to the same
|
||||
requirements outlined above.
|
||||
|
||||
If an expert is employed by or member of an entity on the disclosure list
|
||||
Bringing in experts can happen at any time in the development process and
|
||||
needs to be handled in a timely manner.
|
||||
|
||||
If an expert is employed by or a member of an entity on the disclosure list
|
||||
provided by the disclosing party, then participation will be requested from
|
||||
the relevant entity.
|
||||
|
||||
If not, then the disclosing party will be informed about the experts
|
||||
If not, then the disclosing party will be informed about the experts'
|
||||
participation. The experts are covered by the Memorandum of Understanding
|
||||
and the disclosing party is requested to acknowledge the participation. In
|
||||
case that the disclosing party has a compelling reason to object, then this
|
||||
objection has to be raised within five work days and resolved with the
|
||||
incident team immediately. If the disclosing party does not react within
|
||||
five work days this is taken as silent acknowledgement.
|
||||
and the disclosing party is requested to acknowledge their participation.
|
||||
In the case where the disclosing party has a compelling reason to object,
|
||||
any objection must to be raised within five working days and resolved with
|
||||
the incident team immediately. If the disclosing party does not react
|
||||
within five working days this is taken as silent acknowledgment.
|
||||
|
||||
After acknowledgement or resolution of an objection the expert is disclosed
|
||||
by the incident team and brought into the development process.
|
||||
After the incident team acknowledges or resolves an objection, the expert
|
||||
is disclosed and brought into the development process.
|
||||
|
||||
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
|
||||
"""""""""""""""""""
|
||||
|
||||
The involved parties will negotiate the date and time where the embargo
|
||||
ends. At that point the prepared mitigations are integrated into the
|
||||
relevant kernel trees and published. There is no pre-notification process:
|
||||
fixes are published in public and available to everyone at the same time.
|
||||
The involved parties will negotiate the date and time when the embargo
|
||||
ends. At that point, the prepared mitigations are published into the
|
||||
relevant kernel trees. There is no pre-notification process: the
|
||||
mitigations are published in public and available to everyone at the same
|
||||
time.
|
||||
|
||||
While we understand that hardware security issues need coordinated embargo
|
||||
time, the embargo time should be constrained to the minimum time which is
|
||||
required for all involved parties to develop, test and prepare the
|
||||
time, the embargo time should be constrained to the minimum time that is
|
||||
required for all involved parties to develop, test, and prepare their
|
||||
mitigations. Extending embargo time artificially to meet conference talk
|
||||
dates or other non-technical reasons is creating more work and burden for
|
||||
the involved developers and response teams as the patches need to be kept
|
||||
up to date in order to follow the ongoing upstream kernel development,
|
||||
which might create conflicting changes.
|
||||
dates or other non-technical reasons creates more work and burden for the
|
||||
involved developers and response teams as the patches need to be kept up to
|
||||
date in order to follow the ongoing upstream kernel development, which
|
||||
might create conflicting changes.
|
||||
|
||||
CVE assignment
|
||||
""""""""""""""
|
||||
@@ -275,34 +313,35 @@ an involved disclosed party. The current ambassadors list:
|
||||
|
||||
If you want your organization to be added to the ambassadors list, please
|
||||
contact the hardware security team. The nominated ambassador has to
|
||||
understand and support our process fully and is ideally well connected in
|
||||
understand and support our process fully and is ideally well-connected in
|
||||
the Linux kernel community.
|
||||
|
||||
Encrypted mailing-lists
|
||||
-----------------------
|
||||
|
||||
We use encrypted mailing-lists for communication. The operating principle
|
||||
We use encrypted mailing lists for communication. The operating principle
|
||||
of these lists is that email sent to the list is encrypted either with the
|
||||
list's PGP key or with the list's S/MIME certificate. The mailing-list
|
||||
list's PGP key or with the list's S/MIME certificate. The mailing list
|
||||
software decrypts the email and re-encrypts it individually for each
|
||||
subscriber with the subscriber's PGP key or S/MIME certificate. Details
|
||||
about the mailing-list software and the setup which is used to ensure the
|
||||
about the mailing list software and the setup that is used to ensure the
|
||||
security of the lists and protection of the data can be found here:
|
||||
https://korg.wiki.kernel.org/userdoc/remail.
|
||||
|
||||
List keys
|
||||
^^^^^^^^^
|
||||
|
||||
For initial contact see :ref:`Contact`. For incident specific mailing-lists
|
||||
the key and S/MIME certificate are conveyed to the subscribers by email
|
||||
sent from the specific list.
|
||||
For initial contact see the :ref:`Contact` section above. For incident
|
||||
specific mailing lists, the key and S/MIME certificate are conveyed to the
|
||||
subscribers by email sent from the specific list.
|
||||
|
||||
Subscription to incident specific lists
|
||||
Subscription to incident-specific lists
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Subscription is handled by the response teams. Disclosed parties who want
|
||||
to participate in the communication send a list of potential subscribers to
|
||||
the response team so the response team can validate subscription requests.
|
||||
Subscription to incident-specific lists is handled by the response teams.
|
||||
Disclosed parties who want to participate in the communication send a list
|
||||
of potential experts to the response team so the response team can validate
|
||||
subscription requests.
|
||||
|
||||
Each subscriber needs to send a subscription request to the response team
|
||||
by email. The email must be signed with the subscriber's PGP key or S/MIME
|
||||
|
||||
@@ -355,23 +355,6 @@ just do it. As a result, a sequence of smaller series gets merged quicker and
|
||||
with better review coverage. Re-posting large series also increases the mailing
|
||||
list traffic.
|
||||
|
||||
Multi-line comments
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Comment style convention is slightly different for networking and most of
|
||||
the tree. Instead of this::
|
||||
|
||||
/*
|
||||
* foobar blah blah blah
|
||||
* another line of text
|
||||
*/
|
||||
|
||||
it is requested that you make it look like this::
|
||||
|
||||
/* foobar blah blah blah
|
||||
* another line of text
|
||||
*/
|
||||
|
||||
Local variable ordering ("reverse xmas tree", "RCS")
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
Reference in New Issue
Block a user