受禁运的硬件问题¶
范围¶
导致安全问题的硬件问题与仅影响 Linux 内核的纯软件错误是不同的安全漏洞类别。
诸如 Meltdown、Spectre、L1TF 等硬件问题必须区别对待，因为它们通常会影响所有操作系统（“OS”），因此需要在不同的操作系统供应商、发行版、芯片供应商、硬件集成商和其他各方之间进行协调。 对于某些问题，软件缓解措施可能取决于微代码或固件更新，这需要进一步协调。
联系方式¶
Linux 内核硬件安全团队独立于常规 Linux 内核安全团队。
该团队仅处理受禁运的硬件安全问题的修复开发。 Linux 内核中纯软件安全漏洞的报告不由该团队处理，报告者将被引导联系常规 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
Michael Ellerman <ellerman@au.ibm.com>
IBM Z
Christian Borntraeger <borntraeger@de.ibm.com>
Intel
Tony Luck <tony.luck@intel.com>
Qualcomm
Trilok Soni <quic_tsoni@quicinc.com>
RISC-V
Palmer Dabbelt <palmer@dabbelt.com>
Samsung
Javier González <javier.gonz@samsung.com>
Microsoft
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>
Red Hat
Josh Poimboeuf <jpoimboe@redhat.com>
SUSE
Jiri Kosina <jkosina@suse.cz>
Kees Cook <keescook@chromium.org>
LLVM
Nick Desaulniers <ndesaulniers@google.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 证书，以便订阅者可以向列表发送加密的电子邮件。