Re: [PATCH] Documentation/admin-guide: Embargoed hardware security issues

[Jonathan Corbet]

On Thu, 25 Jul 2019 15:01:13 +0200
Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:

> From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> 
> 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.
> 

[...]

>  Documentation/admin-guide/embargoed-hardware-issues.rst |  281 ++++++++++++++++
>  Documentation/admin-guide/index.rst                     |    1 
>  2 files changed, 282 insertions(+)

So I would argue that the admin guide (which is aimed at sysadmins) is the
wrong place for this document.  It's process information and is best placed
in the process manual (Documentation/process) IMO.  (Yes, I know
security-bugs.rst is in the admin guide; I remember there was a discussion
at the time and it ended up there, but I'm not really sure that's right
either).

> Note, this document has gone through numerous reviews by a number of
> kernel developers, developers at some of the Linux distros, as well as
> all of the lawyers from almost all open source-related companies.  It's
> been sitting on my local drive with no comments for a few months now,
> and it's about time to get this out and merged properly.
> 
> If anyone has any final comments, please let me know.

I do think it could benefit from a pass for basic language issues; I can do
that if such an effort would be welcome.

> If anyone from any company listed below wishes to add their name to the
> document, please send a follow-on patch and I will be glad to add it to
> the series.  I had a number of "I'll sign up" type comments from
> different people, but I want something with a "s-o-b" to keep people on
> the hook for this, so I did not add their name to the file without that.
> 
> thanks,
> 
> greg k-h
> 
> 
> 
> --- /dev/null
> +++ b/Documentation/admin-guide/embargoed-hardware-issues.rst
> @@ -0,0 +1,281 @@
> +.. _embargoedhardwareissues:

This label isn't used anywhere.

> +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

Somebody may well complain about the "smart quotes" here; non-ascii stuff
has led to unhappiness in the past.

> +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

s/is only handling/only handles/

> +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/
> +<securitybugs>`) instead.
> +
> +The team can be contacted by email at <hardware-security@xxxxxxxxxx>. 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/....

Somebody needs to fill in some dots there...:)

> +While hardware security issues are often handled by the affected hardware
> +vendor, we welcome contact from researchers or individuals who identified a

who *have* identified

> +potential hardware flaw.
> +
> +Hardware security officers
> +^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +The current team of hardware security officers:
> +
> +  - Linus Torvalds (Linux Foundation Fellow)
> +  - Greg Kroah-Hartman (Linux Foundation Fellow)
> +  - Thomas Gleixner (Linux Foundation Fellow)
> +
> +Operation of mailing-lists
> +^^^^^^^^^^^^^^^^^^^^^^^^^^

I would de-hyphenate "mailing list" throughout.  But that's me.

> +The encrypted mailing-lists which are used in our process are hosted on
> +Linux Foundation's IT infrastructure. By providing this service Linux
> +Foundation's director of IT Infrastructure security technically has the
> +ability to access the embargoed information, but is obliged to
> +confidentiality by his employment contract. Linux Foundation's director of
> +IT Infrastructure security is also responsible for the kernel.org
> +infrastructure.
> +
> +The Linux Foundation's current director of IT Infrastructure security is
> +Konstantin Ryabitsev.
> +
> +
> +Non-disclosure agreements
> +-------------------------
> +
> +The Linux kernel hardware security team is not a formal body and therefore
> +unable to enter into any non-disclosure agreements.  The kernel community
> +is aware of the sensitive nature of such issues and offers a Memorandum of
> +Understanding instead.
> +
> +
> +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.
> +
> +The Linux kernel community has successfully handled hardware security
> +issues in the past and has the necessary mechanisms in place to allow
> +community compliant development under embargo restrictions.
> +
> +The Linux kernel community has a dedicated hardware security team for
> +initial contact, which oversees the process of handling such issues under
> +embargo rules.
> +
> +The hardware security team identifies the developers (domain experts) which
> +form the initial response team for a particular issue. The initial response

s/which form/who will form/

> +team can bring in further developers (domain experts) to address the issue
> +in the best technical way.

Does the reporter get any say in who can be in this group?  That should
probably be made explicit either 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
> +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
> +immediately to the Hardware security officers.
> +
> +
> +Process
> +^^^^^^^
> +
> +Due to the globally distributed nature of Linux kernel development, face to
> +face meetings are almost impossible to address hardware security issues.

face-to-face

> +Phone conferences are hard to coordinate due to time zones and other
> +factors and should be only used when absolutely necessary. Encrypted email
> +has been proven to be the most effective and secure communication 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.
> +
> +The hardware security team will provide a per incident specific encrypted

s/per incident specific/incident-specific/

> +mailing-list which will be used for initial discussion with the reporter,
> +further disclosure and coordination.
> +
> +The hardware security team will provide the disclosing party a list of
> +developers (domain experts) who should be informed initially about the
> +issue after confirming with the developers  that they will adhere to this
> +Memorandum of Understanding and the documented process. These developers
> +form the initial response team and will be responsible for handling the
> +issue after initial contact. The hardware security team is supporting the
> +response team, but is not necessarily involved in the mitigation
> +development process.

Again, "should be informed" is conditional, suggesting that the reporter
might have some sort of veto power.  But the actual policy is not clear.

> +While individual developers might be covered by a non-disclosure agreement
> +via their employer, they cannot enter individual non-disclosure agreements
> +in their role as Linux kernel developers. They will, however, adhere to
> +this documented process and the Memorandum of Understanding.

They will *agree to* adhere ...  We expect that actual adherence will be
the case but there is no way (even if an NDA were involved) to guarantee
that.

> +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
> +done via email.
> +
> +Mitigation development
> +""""""""""""""""""""""
> +
> +The initial response team sets up an encrypted mailing-list or repurposes
> +an existing one if appropriate. The disclosing party should provide a list
> +of contacts for all other parties who have already been, or should be
> +informed about the issue. The response team contacts these parties so they
> +can name experts who should be subscribed to the mailing-list.
> +
> +Using a mailing-list is close to the normal Linux development process and
> +has been successfully used in developing 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
> +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.

Do we want to envision a KPTI-like situation where the mitigation can be
developed publicly?  Or perhaps just handle any such case if and when it
ever arises?

> +The initial response team will identify further experts from the Linux
> +kernel developer community as needed and inform the disclosing party about
> +their participation. Bringing in experts can happen at any time of the
> +development process and often needs to be handled in a timely manner.
> +
> +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.
> +
> +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
> +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.
> +
> +CVE assignment
> +""""""""""""""
> +
> +Neither the hardware security team nor the initial response team assign
> +CVEs, nor are CVEs required for the development process. If CVEs are
> +provided by the disclosing party they can be used for documentation
> +purposes.
> +
> +Process ambassadors
> +-------------------
> +
> +For assistance with this process we have established ambassadors in various
> +organizations, who can answer questions about or provide guidance on the
> +reporting process and further handling. Ambassadors are not involved in the
> +disclosure of a particular issue, unless requested by a response team or by
> +an involved disclosed party. The current ambassadors list:
> +
> +  ============== ========================================================
> +  ARM
> +  AMD
> +  IBM
> +  Intel
> +  Qualcomm
> +
> +  Microsoft
> +  VMware
> +  XEN
> +
> +  Canonical
> +  Debian
> +  Oracle
> +  Redhat
> +  Suse           Jiri Kosina <jkosina@xxxxxxxx>
> +
> +  Amazon
> +  Google
> +  ============== ========================================================

Having companies without names seems a little weird.  Unless perhaps you
have people teed up to add their names in follow-on patches?

> +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
> +the Linux kernel community.
> +
> +Encrypted mailing-lists
> +-----------------------
> +
> +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
> +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
> +security of the lists and protection of the data can be found here:
> +https://www.kernel.org/....

That URL is also in need of completion.

The topic of encrypted mailing lists is visited several times in this
document; I wonder if that could be coalesced somehow?

> +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.
> +
> +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.
> +
> +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
> +certificate. If a PGP key is used, it must be available from a public key
> +server and is ideally connected to the Linux kernel's PGP web of trust. See
> +also: https://www.kernel.org/signature.html.

The "public key server" thing isn't working quite as well as it was; does
this requirement need to be revisited?

> +The response team verifies that the subscriber request is valid and adds
> +the subscriber to the list. After subscription the subscriber will receive
> +email from the mailing-list which is signed either with the list's PGP key
> +or the list's S/MIME certificate. The subscriber's email client can extract
> +the PGP key or the S/MIME certificate from the signature so the subscriber
> +can send encrypted email to the list.
> +
> --- a/Documentation/admin-guide/index.rst
> +++ b/Documentation/admin-guide/index.rst
> @@ -33,6 +33,7 @@ problems and bugs in particular.
>  
>     reporting-bugs
>     security-bugs
> +   embargoed-hardware-issues
>     bug-hunting
>     bug-bisect
>     tainted-kernels

jon