禁运硬件问题¶
范围¶
导致安全问题的硬件问题与仅影响 Linux 内核的纯软件 Bug 属于不同类别的安全 Bug。
Meltdown、Spectre、L1TF 等硬件问题必须区别对待，因为它们通常会影响所有操作系统（“OS”），因此需要在不同的操作系统供应商、发行版、芯片供应商、硬件集成商及其他各方之间进行协调。对于某些问题，软件缓解措施可能依赖于微代码或固件更新，这需要进一步协调。
联系方式¶
Linux 内核硬件安全团队独立于常规的 Linux 内核安全团队。
该团队仅负责开发禁运硬件安全问题的修复程序。Linux 内核中的纯软件安全 Bug 报告不由此团队处理，报告者将被引导联系常规的 Linux 内核安全团队（Documentation/admin-guide/）。
可通过电子邮件联系该团队：<hardware-security@kernel.org>。这是一个私人列表，由安全官员组成，他们将根据我们记录的流程协助您协调修复方案。
该列表已加密，发送到列表的电子邮件可以使用 PGP 或 S/MIME 加密，并且必须使用报告者的 PGP 密钥或 S/MIME 证书进行签名。列表的 PGP 密钥和 S/MIME 证书可从以下 URL 获取：
虽然硬件安全问题通常由受影响的芯片供应商处理，但我们欢迎已发现潜在硬件缺陷的研究人员或个人与我们联系。
硬件安全官¶
当前的硬件安全官团队
Linus Torvalds (Linux 基金会研究员)
Greg Kroah-Hartman (Linux 基金会研究员)
Thomas Gleixner (Linux 基金会研究员)
邮件列表的运作¶
我们流程中使用的加密邮件列表托管在 Linux 基金会的 IT 基础设施上。通过提供此服务，Linux 基金会 IT 运营人员在技术上能够访问禁运信息，但根据其雇佣合同负有保密义务。Linux 基金会 IT 人员还负责运营和管理 kernel.org 的其他基础设施。
Linux 基金会 IT 项目基础设施的现任主管是 Konstantin Ryabitsev。
保密协议¶
Linux 内核硬件安全团队不是一个正式机构，因此无法签订任何保密协议。内核社区了解此类问题的敏感性，因此提供一份谅解备忘录作为替代。
谅解备忘录¶
Linux 内核社区对为协调不同操作系统供应商、分销商、芯片供应商及其他各方而对硬件安全问题进行禁运的需求有深刻的理解。
Linux 内核社区在过去已成功处理过硬件安全问题，并已建立必要的机制，以允许在禁运限制下进行符合社区规范的开发。
Linux 内核社区有一个专门的硬件安全团队负责初始联系，该团队负责监督在禁运规则下处理此类问题的流程。
硬件安全团队会确定将组成特定问题初始响应团队的开发者（领域专家）。初始响应团队可以引入更多开发者（领域专家），以最佳技术方式解决问题。
所有参与的开发者承诺遵守禁运规则，并对收到的信息保密。违反承诺将导致立即被排除在当前问题之外，并从所有相关邮件列表中移除。此外，硬件安全团队还将把违规者排除在未来问题之外。这种后果在我们的社区中是一种高效的威慑。如果发生违规行为，硬件安全团队将立即通知相关方。如果您或其他人发现潜在违规行为，请立即向硬件安全官报告。
流程¶
由于 Linux 内核开发的全球分布式特性，面对面会议几乎无法解决硬件安全问题。电话会议由于时区和其他因素难以协调，应仅在绝对必要时使用。加密电子邮件已被证明是处理此类问题的最有效和最安全的通信方法。
披露开始¶
披露流程通过向上述“联系方式”部分的 Linux 内核硬件安全团队发送电子邮件开始。首次联系应包含问题描述以及所有已知受影响芯片的列表。如果您的组织构建或分发受影响的硬件，我们鼓励您同时考虑可能受影响的其他硬件。披露方负责及时联系受影响的芯片供应商。
硬件安全团队将提供一个针对特定事件的加密邮件列表，用于与报告者进行初步讨论、进一步披露和协调修复。
硬件安全团队将向披露方提供一份开发者（领域专家）名单，这些开发者在确认他们将遵守本谅解备忘录和文件记录的流程后，应被初步告知该问题。这些开发者组成初始响应团队，并将在初步联系后负责处理该问题。硬件安全团队支持响应团队，但不一定参与缓解措施的开发过程。
尽管个人开发者可能通过其雇主受保密协议约束，但他们作为 Linux 内核开发者不能签订个人保密协议。但是，他们将同意遵守此文件记录的流程和谅解备忘录。
披露方应提供一份已获知或应获知该问题的所有其他实体的联系人列表。这有几个目的：
披露实体列表允许行业内的沟通，例如其他操作系统供应商、硬件供应商等。
可以联系已披露的实体，以指派应参与缓解措施开发的专家。
如果处理问题所需的专家受雇于某个列出的实体或属于该实体成员，则响应团队可以请求该实体披露该专家。这确保了该专家也属于该实体的响应团队的一部分。
披露¶
披露方通过特定的加密邮件列表向初始响应团队提供详细信息。
根据我们的经验，这些问题的技术文档通常是足够的起点，进一步的技术澄清最好通过电子邮件完成。
缓解措施开发¶
初始响应团队建立一个加密邮件列表，或酌情重新利用现有列表。
使用邮件列表与正常的 Linux 开发流程相似，并且在过去已成功用于开发各种硬件安全问题的缓解措施。
该邮件列表的运作方式与正常的 Linux 开发相同。补丁会被发布、讨论和评审，如果达成一致，则应用于一个非公开的 Git 仓库，该仓库仅参与开发的开发者通过安全连接访问。该仓库包含针对主线内核的主要开发分支，并在必要时包含稳定内核版本的向后移植分支。
初始响应团队将根据需要从 Linux 内核开发者社区中识别更多专家。任何相关方都可以建议纳入更多专家，每位专家都将受制于上述相同的要求。
引入专家可以在开发过程中的任何时候发生，并且需要及时处理。
如果专家受雇于或属于披露方提供的披露列表中的实体，则将向相关实体请求参与。
如果不是，则会通知披露方有关专家的参与情况。专家受谅解备忘录约束，并要求披露方确认其参与。如果披露方有充分理由反对，任何反对意见必须在五个工作日内提出并立即与事件处理团队解决。如果披露方在五个工作日内未作出回应，则视为默认同意。
在事件处理团队确认或解决异议后，专家将被披露并引入开发流程。
列表参与者不得在私人邮件列表之外就该问题进行沟通。列表参与者在处理补丁时不得使用任何共享资源（例如雇主构建农场、CI 系统等）。
早期访问¶
在列表中讨论和开发的补丁既不能分发给非响应团队成员的个人，也不能分发给任何其他组织。
为使受影响的芯片供应商能与其内部团队和行业伙伴在测试、验证和物流方面进行合作，特设以下例外情况：
受影响芯片供应商的指定代表被允许随时将补丁移交给芯片供应商的响应团队。该代表必须将移交情况通知内核响应团队。受影响的芯片供应商必须拥有并维护其自身针对与响应团队共享的任何补丁的记录在案的安全流程，且该流程需与本政策保持一致。
芯片供应商的响应团队可以在芯片供应商的记录在案的安全流程下，将这些补丁分发给其行业伙伴和内部团队。来自行业伙伴的反馈将返回给芯片供应商，并由芯片供应商传达给内核响应团队。
将补丁移交给芯片供应商的响应团队，解除了内核响应团队因芯片供应商内部团队或行业伙伴的参与而导致的过早披露的任何责任或义务。芯片供应商通过同意此流程来保证免除此责任。
协调发布¶
相关方将协商禁运结束的日期和时间。届时，准备好的缓解措施将发布到相关的内核树中。没有预先通知流程：缓解措施将公开同时发布并供所有人使用。
虽然我们理解硬件安全问题需要协调禁运时间，但禁运时间应限制在所有相关方开发、测试和准备其缓解措施所需的最小时间。为了满足会议演讲日期或其他非技术原因而人为延长禁运时间，会给相关的开发者和响应团队带来更多工作和负担，因为补丁需要持续更新以跟进正在进行的上游内核开发，这可能会产生冲突的更改。
CVE 分配¶
硬件安全团队和初始响应团队均不分配 CVE，开发流程也不要求 CVE。如果披露方提供了 CVE，它们可用于文档目的。
流程大使¶
为协助此流程，我们已在各个组织中设立了大使，他们可以回答有关报告流程和后续处理的问题或提供指导。除非响应团队或相关披露方提出要求，否则大使不参与特定问题的披露。当前大使列表：
AMD
Tom Lendacky <thomas.lendacky@amd.com>
Ampere
Darren Hart <darren@os.amperecomputing.com>
ARM
Catalin Marinas <catalin.marinas@arm.com>
IBM Power
Madhavan Srinivasan <maddy@linux.ibm.com>
IBM Z
Christian Borntraeger <borntraeger@de.ibm.com>
Intel
Tony Luck <tony.luck@intel.com>
高通
Trilok Soni <quic_tsoni@quicinc.com>
RISC-V
Palmer Dabbelt <palmer@dabbelt.com>
三星
Javier González <javier.gonz@samsung.com>
微软
James Morris <jamorris@linux.microsoft.com>
Xen
Andrew Cooper <andrew.cooper3@citrix.com>
Canonical
John Johansen <john.johansen@canonical.com>
Debian
Ben Hutchings <ben@decadent.org.uk>
Oracle
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
红帽
Josh Poimboeuf <jpoimboe@redhat.com>
SUSE
Jiri Kosina <jkosina@suse.cz>
谷歌
Kees Cook <keescook@chromium.org>
LLVM
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>
如果您希望您的组织被添加到大使列表中，请联系硬件安全团队。被提名的大使必须完全理解并支持我们的流程，并且最好在 Linux 内核社区中有良好的人脉。
加密邮件列表¶
我们使用加密邮件列表进行通信。这些列表的运作原则是发送到列表的电子邮件要么使用列表的 PGP 密钥加密，要么使用列表的 S/MIME 证书加密。邮件列表软件解密电子邮件，然后使用每个订阅者的 PGP 密钥或 S/MIME 证书单独重新加密。有关邮件列表软件以及用于确保列表安全和数据保护的设置的详细信息，请参见此处：https://korg.wiki.kernel.org/userdoc/remail。
列表密钥¶
首次联系请参阅上文的联系方式部分。对于特定事件的邮件列表，密钥和 S/MIME 证书将通过从该特定列表发送的电子邮件传达给订阅者。
订阅特定事件列表¶
特定事件列表的订阅由响应团队处理。希望参与通信的已披露方将潜在专家列表发送给响应团队，以便响应团队验证订阅请求。
每个订阅者都需要通过电子邮件向响应团队发送订阅请求。电子邮件必须使用订阅者的 PGP 密钥或 S/MIME 证书进行签名。如果使用 PGP 密钥，则该密钥必须可从公共密钥服务器获取，并且最好与 Linux 内核的 PGP 信任网络相关联。另请参阅：https://linuxkernel.org.cn/signature.html。
响应团队验证订阅请求的有效性并将订阅者添加到列表中。订阅后，订阅者将收到来自邮件列表的电子邮件，该邮件已使用列表的 PGP 密钥或列表的 S/MIME 证书进行签名。订阅者的电子邮件客户端可以从签名中提取 PGP 密钥或 S/MIME 证书，以便订阅者可以向列表发送加密电子邮件。