禁運硬體問題¶
範圍¶
導致安全問題的硬體問題與僅影響 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://kernel.linux.club.tw/signature.html。
響應團隊驗證訂閱請求的有效性並將訂閱者新增到列表中。訂閱後，訂閱者將收到來自郵件列表的電子郵件，該郵件已使用列表的 PGP 金鑰或列表的 S/MIME 證書進行簽名。訂閱者的電子郵件客戶端可以從簽名中提取 PGP 金鑰或 S/MIME 證書，以便訂閱者可以向列表傳送加密電子郵件。