233 lines
10 KiB
ReStructuredText
233 lines
10 KiB
ReStructuredText
|
.. SPDX-License-Identifier: GPL-2.0
|
|||
|
|
|
|||
|
|
.. include:: ../disclaimer-zh_TW.rst
|
|||
|
|
|
|||
|
|
:Original: :ref:`Documentation/process/embargoed-hardware-issues.rst <embargoed_hardware_issues>`
|
|||
|
|
:Translator: Alex Shi <alex.shi@linux.alibaba.com>
|
|||
|
|
Hu Haowen <src.res@email.cn>
|
|||
|
|
|
|||
|
|
被限制的硬體問題
|
|||
|
|
================
|
|||
|
|
|
|||
|
|
範圍
|
|||
|
|
----
|
|||
|
|
|
|||
|
|
導致安全問題的硬體問題與只影響Linux內核的純軟體錯誤是不同的安全錯誤類別。
|
|||
|
|
|
|||
|
|
必須區別對待諸如熔毀(Meltdown)、Spectre、L1TF等硬體問題，因爲它們通常會影響
|
|||
|
|
所有作業系統（「OS」），因此需要在不同的OS供應商、發行版、硬體供應商和其他各方
|
|||
|
|
之間進行協調。對於某些問題，軟體緩解可能依賴於微碼或固件更新，這需要進一步的
|
|||
|
|
協調。
|
|||
|
|
|
|||
|
|
.. _tw_Contact:
|
|||
|
|
|
|||
|
|
接觸
|
|||
|
|
----
|
|||
|
|
|
|||
|
|
Linux內核硬體安全小組獨立於普通的Linux內核安全小組。
|
|||
|
|
|
|||
|
|
該小組只負責協調被限制的硬體安全問題。Linux內核中純軟體安全漏洞的報告不由該
|
|||
|
|
小組處理，報告者將被引導至常規Linux內核安全小組(:ref:`Documentation/admin-guide/
|
|||
|
|
<securitybugs>`)聯繫。
|
|||
|
|
|
|||
|
|
可以通過電子郵件 <hardware-security@kernel.org> 與小組聯繫。這是一份私密的安全
|
|||
|
|
官名單，他們將幫助您根據我們的文檔化流程協調問題。
|
|||
|
|
|
|||
|
|
郵件列表是加密的，發送到列表的電子郵件可以通過PGP或S/MIME加密，並且必須使用報告
|
|||
|
|
者的PGP密鑰或S/MIME證書籤名。該列表的PGP密鑰和S/MIME證書可從
|
|||
|
|
https://www.kernel.org/.... 獲得。
|
|||
|
|
|
|||
|
|
雖然硬體安全問題通常由受影響的硬體供應商處理，但我們歡迎發現潛在硬體缺陷的研究
|
|||
|
|
人員或個人與我們聯繫。
|
|||
|
|
|
|||
|
|
硬體安全官
|
|||
|
|
^^^^^^^^^^
|
|||
|
|
|
|||
|
|
目前的硬體安全官小組:
|
|||
|
|
|
|||
|
|
- Linus Torvalds（Linux基金會院士）
|
|||
|
|
- Greg Kroah Hartman（Linux基金會院士）
|
|||
|
|
- Thomas Gleixner（Linux基金會院士）
|
|||
|
|
|
|||
|
|
郵件列表的操作
|
|||
|
|
^^^^^^^^^^^^^^
|
|||
|
|
|
|||
|
|
處理流程中使用的加密郵件列表託管在Linux Foundation的IT基礎設施上。通過提供這項
|
|||
|
|
服務，Linux基金會的IT基礎設施安全總監在技術上有能力訪問被限制的信息，但根據他
|
|||
|
|
的僱傭合同，他必須保密。Linux基金會的IT基礎設施安全總監還負責 kernel.org 基礎
|
|||
|
|
設施。
|
|||
|
|
|
|||
|
|
Linux基金會目前的IT基礎設施安全總監是 Konstantin Ryabitsev。
|
|||
|
|
|
|||
|
|
保密協議
|
|||
|
|
--------
|
|||
|
|
|
|||
|
|
Linux內核硬體安全小組不是正式的機構，因此無法簽訂任何保密協議。核心社區意識到
|
|||
|
|
這些問題的敏感性，並提供了一份諒解備忘錄。
|
|||
|
|
|
|||
|
|
諒解備忘錄
|
|||
|
|
----------
|
|||
|
|
|
|||
|
|
Linux內核社區深刻理解在不同作業系統供應商、發行商、硬體供應商和其他各方之間
|
|||
|
|
進行協調時，保持硬體安全問題處於限制狀態的要求。
|
|||
|
|
|
|||
|
|
Linux內核社區在過去已經成功地處理了硬體安全問題，並且有必要的機制允許在限制
|
|||
|
|
限制下進行符合社區的開發。
|
|||
|
|
|
|||
|
|
Linux內核社區有一個專門的硬體安全小組負責初始聯繫，並監督在限制規則下處理
|
|||
|
|
此類問題的過程。
|
|||
|
|
|
|||
|
|
硬體安全小組確定開發人員（領域專家），他們將組成特定問題的初始響應小組。最初
|
|||
|
|
的響應小組可以引入更多的開發人員（領域專家）以最佳的技術方式解決這個問題。
|
|||
|
|
|
|||
|
|
所有相關開發商承諾遵守限制規定，並對收到的信息保密。違反承諾將導致立即從當前
|
|||
|
|
問題中排除，並從所有相關郵件列表中刪除。此外，硬體安全小組還將把違反者排除在
|
|||
|
|
未來的問題之外。這一後果的影響在我們社區是一種非常有效的威懾。如果發生違規
|
|||
|
|
情況，硬體安全小組將立即通知相關方。如果您或任何人發現潛在的違規行爲，請立即
|
|||
|
|
向硬體安全人員報告。
|
|||
|
|
|
|||
|
|
流程
|
|||
|
|
^^^^
|
|||
|
|
|
|||
|
|
由於Linux內核開發的全球分布式特性，面對面的會議幾乎不可能解決硬體安全問題。
|
|||
|
|
由於時區和其他因素，電話會議很難協調，只能在絕對必要時使用。加密電子郵件已被
|
|||
|
|
證明是解決此類問題的最有效和最安全的通信方法。
|
|||
|
|
|
|||
|
|
開始披露
|
|||
|
|
""""""""
|
|||
|
|
|
|||
|
|
披露內容首先通過電子郵件聯繫Linux內核硬體安全小組。此初始聯繫人應包含問題的
|
|||
|
|
描述和任何已知受影響硬體的列表。如果您的組織製造或分發受影響的硬體，我們建議
|
|||
|
|
您也考慮哪些其他硬體可能會受到影響。
|
|||
|
|
|
|||
|
|
硬體安全小組將提供一個特定於事件的加密郵件列表，用於與報告者進行初步討論、
|
|||
|
|
進一步披露和協調。
|
|||
|
|
|
|||
|
|
硬體安全小組將向披露方提供一份開發人員（領域專家）名單，在與開發人員確認他們
|
|||
|
|
將遵守本諒解備忘錄和文件化流程後，應首先告知開發人員有關該問題的信息。這些開發
|
|||
|
|
人員組成初始響應小組，並在初始接觸後負責處理問題。硬體安全小組支持響應小組，
|
|||
|
|
但不一定參與緩解開發過程。
|
|||
|
|
|
|||
|
|
雖然個別開發人員可能通過其僱主受到保密協議的保護，但他們不能以Linux內核開發
|
|||
|
|
人員的身份簽訂個別保密協議。但是，他們將同意遵守這一書面程序和諒解備忘錄。
|
|||
|
|
|
|||
|
|
披露方應提供已經或應該被告知該問題的所有其他實體的聯繫人名單。這有幾個目的:
|
|||
|
|
|
|||
|
|
- 披露的實體列表允許跨行業通信，例如其他作業系統供應商、硬體供應商等。
|
|||
|
|
|
|||
|
|
- 可聯繫已披露的實體，指定應參與緩解措施開發的專家。
|
|||
|
|
|
|||
|
|
- 如果需要處理某一問題的專家受僱於某一上市實體或某一上市實體的成員，則響應
|
|||
|
|
小組可要求該實體披露該專家。這確保專家也是實體反應小組的一部分。
|
|||
|
|
|
|||
|
|
披露
|
|||
|
|
""""
|
|||
|
|
|
|||
|
|
披露方通過特定的加密郵件列表向初始響應小組提供詳細信息。
|
|||
|
|
|
|||
|
|
根據我們的經驗，這些問題的技術文檔通常是一個足夠的起點，最好通過電子郵件進行
|
|||
|
|
進一步的技術澄清。
|
|||
|
|
|
|||
|
|
緩解開發
|
|||
|
|
""""""""
|
|||
|
|
|
|||
|
|
初始響應小組設置加密郵件列表，或在適當的情況下重新修改現有郵件列表。
|
|||
|
|
|
|||
|
|
使用郵件列表接近於正常的Linux開發過程，並且在過去已經成功地用於爲各種硬體安全
|
|||
|
|
問題開發緩解措施。
|
|||
|
|
|
|||
|
|
郵件列表的操作方式與正常的Linux開發相同。發布、討論和審查修補程序，如果同意，
|
|||
|
|
則應用於非公共git存儲庫，參與開發人員只能通過安全連接訪問該存儲庫。存儲庫包含
|
|||
|
|
針對主線內核的主開發分支，並根據需要爲穩定的內核版本提供向後移植分支。
|
|||
|
|
|
|||
|
|
最初的響應小組將根據需要從Linux內核開發人員社區中確定更多的專家。引進專家可以
|
|||
|
|
在開發過程中的任何時候發生，需要及時處理。
|
|||
|
|
|
|||
|
|
如果專家受僱於披露方提供的披露清單上的實體或其成員，則相關實體將要求其參與。
|
|||
|
|
|
|||
|
|
否則，披露方將被告知專家參與的情況。諒解備忘錄涵蓋了專家，要求披露方確認參與。
|
|||
|
|
如果披露方有令人信服的理由提出異議，則必須在五個工作日內提出異議，並立即與事件
|
|||
|
|
小組解決。如果披露方在五個工作日內未作出回應，則視爲默許。
|
|||
|
|
|
|||
|
|
在確認或解決異議後，專家由事件小組披露，並進入開發過程。
|
|||
|
|
|
|||
|
|
協調發布
|
|||
|
|
""""""""
|
|||
|
|
|
|||
|
|
有關各方將協商限制結束的日期和時間。此時，準備好的緩解措施集成到相關的內核樹中
|
|||
|
|
並發布。
|
|||
|
|
|
|||
|
|
雖然我們理解硬體安全問題需要協調限制時間，但限制時間應限制在所有有關各方制定、
|
|||
|
|
測試和準備緩解措施所需的最短時間內。人爲地延長限制時間以滿足會議討論日期或其他
|
|||
|
|
非技術原因，會給相關的開發人員和響應小組帶來了更多的工作和負擔，因爲補丁需要
|
|||
|
|
保持最新，以便跟蹤正在進行的上游內核開發，這可能會造成衝突的更改。
|
|||
|
|
|
|||
|
|
CVE分配
|
|||
|
|
"""""""
|
|||
|
|
|
|||
|
|
硬體安全小組和初始響應小組都不分配CVE，開發過程也不需要CVE。如果CVE是由披露方
|
|||
|
|
提供的，則可用於文檔中。
|
|||
|
|
|
|||
|
|
流程專使
|
|||
|
|
--------
|
|||
|
|
|
|||
|
|
爲了協助這一進程，我們在各組織設立了專使，他們可以回答有關報告流程和進一步處理
|
|||
|
|
的問題或提供指導。專使不參與特定問題的披露，除非響應小組或相關披露方提出要求。
|
|||
|
|
現任專使名單:
|
|||
|
|
|
|||
|
|
============= ========================================================
|
|||
|
|
ARM
|
|||
|
|
AMD Tom Lendacky <tom.lendacky@amd.com>
|
|||
|
|
IBM
|
|||
|
|
Intel Tony Luck <tony.luck@intel.com>
|
|||
|
|
Qualcomm Trilok Soni <tsoni@codeaurora.org>
|
|||
|
|
|
|||
|
|
Microsoft Sasha Levin <sashal@kernel.org>
|
|||
|
|
VMware
|
|||
|
|
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>
|
|||
|
|
|
|||
|
|
Amazon
|
|||
|
|
Google Kees Cook <keescook@chromium.org>
|
|||
|
|
============= ========================================================
|
|||
|
|
|
|||
|
|
如果要將您的組織添加到專使名單中，請與硬體安全小組聯繫。被提名的專使必須完全
|
|||
|
|
理解和支持我們的過程，並且在Linux內核社區中很容易聯繫。
|
|||
|
|
|
|||
|
|
加密郵件列表
|
|||
|
|
------------
|
|||
|
|
|
|||
|
|
我們使用加密郵件列表進行通信。這些列表的工作原理是，發送到列表的電子郵件使用
|
|||
|
|
列表的PGP密鑰或列表的/MIME證書進行加密。郵件列表軟體對電子郵件進行解密，並
|
|||
|
|
使用訂閱者的PGP密鑰或S/MIME證書爲每個訂閱者分別對其進行重新加密。有關郵件列表
|
|||
|
|
軟體和用於確保列表安全和數據保護的設置的詳細信息，請訪問:
|
|||
|
|
https://www.kernel.org/....
|
|||
|
|
|
|||
|
|
關鍵點
|
|||
|
|
^^^^^^
|
|||
|
|
|
|||
|
|
初次接觸見 :ref:`tw_Contact`. 對於特定於事件的郵件列表，密鑰和S/MIME證書通過
|
|||
|
|
特定列表發送的電子郵件傳遞給訂閱者。
|
|||
|
|
|
|||
|
|
訂閱事件特定列表
|
|||
|
|
^^^^^^^^^^^^^^^^
|
|||
|
|
|
|||
|
|
訂閱由響應小組處理。希望參與通信的披露方將潛在訂戶的列表發送給響應組，以便
|
|||
|
|
響應組可以驗證訂閱請求。
|
|||
|
|
|
|||
|
|
每個訂戶都需要通過電子郵件向響應小組發送訂閱請求。電子郵件必須使用訂閱伺服器
|
|||
|
|
的PGP密鑰或S/MIME證書籤名。如果使用PGP密鑰，則必須從公鑰伺服器獲得該密鑰，
|
|||
|
|
並且理想情況下該密鑰連接到Linux內核的PGP信任網。另請參見:
|
|||
|
|
https://www.kernel.org/signature.html.
|
|||
|
|
|
|||
|
|
響應小組驗證訂閱者，並將訂閱者添加到列表中。訂閱後，訂閱者將收到來自郵件列表
|
|||
|
|
的電子郵件，該郵件列表使用列表的PGP密鑰或列表的/MIME證書籤名。訂閱者的電子郵件
|
|||
|
|
客戶端可以從簽名中提取PGP密鑰或S/MIME證書，以便訂閱者可以向列表發送加密電子
|
|||
|
|
郵件。
|
|||
|
|
|