diff options
Diffstat (limited to 'l.patch')
| -rw-r--r-- | l.patch | 348 |
1 files changed, 0 insertions, 348 deletions
diff --git a/l.patch b/l.patch deleted file mode 100644 index 3a687a892dd5e5..00000000000000 --- a/l.patch +++ /dev/null @@ -1,348 +0,0 @@ -Subject: [PATCH] Documentation/admin-guide: Embargoed hardware security issues - -From: Thomas Gleixner <tglx@linutronix.de> - -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. - -This memo can help with hardware companies who, and I quote, "[my -manager] doesn't want to bet his job on the list keeping things secret." -This despite numerous leaks directly from that company over the years, -and none ever so far from the kernel security team. Cognitive -dissidence seems to be a requirement to be a good manager. - -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 <tglx@linutronix.de> -Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> -Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com> -Acked-by: Laura Abbott <labbott@redhat.com> -Acked-by: Ben Hutchings <ben@decadent.org.uk> -Reviewed-by: Tyler Hicks <tyhicks@canonical.com> -Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> -Reviewed-by: Jiri Kosina <jkosina@suse.cz> -Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> - ---- - Documentation/process/embargoed-hardware-issues.rst | 279 ++++++++++++++++++++ - Documentation/process/index.rst | 1 - 2 files changed, 280 insertions(+) - ---- /dev/null -+++ b/Documentation/process/embargoed-hardware-issues.rst -@@ -0,0 +1,279 @@ -+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 only handles 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/ -+<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 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, we welcome contact from researchers or individuals who have -+identified a 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 -+^^^^^^^^^^^^^^^^^^^^^^^^^^ -+ -+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) who -+will form the initial response team for a particular issue. The initial -+response team can bring in further developers (domain experts) to address -+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 -+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. 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 an incident-specific encrypted -+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. -+ -+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, agree to -+adhere to this documented process and the Memorandum of Understanding. -+ -+ -+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. -+ -+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 Tyler Hicks <tyhicks@canonical.com> -+ Debian Ben Hutchings <ben@decadent.org.uk> -+ Oracle Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> -+ Red Hat Josh Poimboeuf <jpoimboe@redhat.com> -+ SUSE Jiri Kosina <jkosina@suse.cz> -+ -+ Amazon -+ Google -+ ============== ======================================================== -+ -+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/.... -+ -+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 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/process/index.rst -+++ b/Documentation/process/index.rst -@@ -45,6 +45,7 @@ Other guides to the community that are o - submit-checklist - kernel-docs - deprecated -+ embargoed-hardware-issues - - These are some overall technical guides that have been put here for now for - lack of a better place. |