| RFC-0118：映像檔組合的 SWD 政策 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 短期變更以便在映像檔組合時套用 SWD 政策。 |
| 問題 | |
| 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年/月) | 2021-06-28 |
| 審查日期 (年/月) | 2021-07-28 |
摘要
這項 RFC 提議突破一項限制，藉由定義清楚易懂和範圍的政策，讓軟體推送 (SWD) 政策設定的可見度、理解和擴充性變得更容易。如此一來，所有開發人員都能瞭解哪些軟體可以在搭載 Fuchsia 的裝置上執行，而且不會意外推送安全性較低的設定。
在目前的提案中，目前的提案應以目前的形式存在，直到以子組件為基礎的產品組裝，針對不同產品用途提供更明確的政策為止。由於本提案的中介工作已順利完成，因此可更輕鬆地轉換至系統組合樣式設定。
提振精神
SWD 設定是強制執行通過驗證執行作業的關鍵。目前，SWD 設定會分割成多個彼此互動的設定檔和套件，以判斷裝置上的實際 SWD 設定。這個 RFC 旨在降低瞭解產品的 SWD 狀態的複雜度。此外，新增非常理解且精心設計的政策，也讓新產品和子類變得更簡單又安全，這樣也能減輕系統套用正確設定時的負擔。
設計
本 RFC 目前會提議三項 SWD 政策。目標是使用語意 (而非以產品為核心) 的命名方式，使 SWD 政策設定更加完善。
如有需要，我們可能會新增更多政策，但這組政策應該比產品和建構變化版本的成長還小。
政策定義
僅限基礎元件
所有可執行程式碼都必須直接驗證 (基礎程式碼)。所有可設定的 SWD 限制都會設為預設安全狀態：不允許存放區的動態設定，且會啟用執行限制，這意味著只有基礎和許可的元件可供解析和執行。
本機動態設定
只有在使用者俱備實體存取權 (例如開發人員) 時，才能允許存放區的動態設定和手動驗證程式碼 (宇宙套件/暫時元件)。
無限制
程式碼的執行性或瀏覽權限沒有限制。這是最寬鬆的 SWD 設定，允許外寫程式碼和動態設定，同時也會停用執行限制。
政策表格
| POLICY_NAME | enable_dynamic_configuration | persisted_repos_dir | disable_executability_restrictions |
|---|---|---|---|
| base_components_only | 關閉 | 關閉 | 關閉 |
| local_dynamic_config | 開啟 | 關閉 | 關閉 |
| 無限制 | 開啟 | 開啟 | 開啟 |
實作
這個 RFC 建議在映像檔組合層級實作這項操作。由於 SWD 設定需要同時在 base_packages 和 system_image_deps 中設定值，因此提案是修改個別的群組目標，在以 policy_labels 建構引數定義的 GN 群組中加入新的依附元件。該引數是一種字典，可用來儲存組合圖片組合鍵/值組合 (本例為 swd) 及其各自的政策標籤。
這有助於我們確保特定建構一律只定義一項 SWD 政策設定。
舉例來說，假設在 //build/security/policies_swd.gni 中定義政策：
policies_swd = [
{
name = "local_dynamic_config"
base_package_deps = [ /* ... */ ]
system_image_deps = [ /* ... */ ]
bootfs_deps = [ /* ... */ ]
},
{
name = "foo"
// ...
},
]
產品擁有者可在產品定義檔案中執行以下操作：
import("//build/images/policy.gni") # defines policy_labels = {} arg.
policy_labels.swd = "local_dynamic_config"
policy_labels.foo = "bar"
在圖片組合步驟中：
group("base_packages") {
testonly = base_cache_packages_testonly
visibility = [ ":*" ]
public_deps = [
// ...
]
// Addition for this proposal
deps = []
foreach (policy, policies_swd) {
if (policy.name == policy_labels.swd) {
deps += policy.base_package_deps
}
}
}
請注意，這無法完全解決祖系 GNI 檔案的產品定義沿用問題。但可以簡化 SWD 政策的設定和可稽核性。
效能
這項異動不會影響成效。
人體工學
這項變更透過抽離配置設定，讓 SWD 設定由單一建構引數控制，因此可透過更簡便的方式瞭解及稽核裝置上的 SWD 狀態。
回溯相容性
這項變更不會影響回溯相容性，變更應以方便還原的方式結構化。
安全性考量
這項變更可以改善 SWD 設定狀態的簡易性、擴充性和易讀性，從而判斷哪些軟體可在 Fuchsia 裝置上執行。這會導致開發人員提供設定不安全的產品，進而直接改善我們的安全防護機制。這也能減少設定空間，並讓產品擁有者能夠更輕鬆地稽核。
隱私權注意事項
這項異動不會影響隱私權，或與使用者資料互動。
測試
系統會測試這項變更，確保在這項變更發布後的建構作業具備預期的 SWD 政策設定。方法是手動確認輸出版本有 (或沒有) 預期的檔案 (適用於 disable_executability_restrictions) 以及變更前後 (適用於 enable_dynamic_configuration 和 persisted_repos_dir) 的設定資料套件。
說明文件
日後會新增其他說明文件，定義 SWD 政策設定。
缺點、替代方案和未知
這項異動旨在提供短期解決方案，直到平台子組合存在為止，讓我們能夠更精細地控制建構程序。這項工作會在處理中的子組件 (fxr/553664) 和結構化設定 (fxr/549661) 中擷取。
這項變更的主要警告是，將套件/依附元件納入產品定義之外。
調查的替代方案如下：
不進行任何變更
我們可以繼續在目前環境中運作，每項產品都可以修改本身的設定，而且每項產品都會持續沿用其祖系的聯集。
然而，隨著 Fuchsia 產品數量快速成長，我們提出此提案是為了主動改進 SWD 設定機制，以便在產品套用不正確 SWD 狀態時出現可能出現的事件，進而反倒 Fuchsia 平台的核心安全假設。
修改產品定義
這與目前的設定類似，但我們要在產品定義的沿用樹狀結構中明確定義各項設定，而是在各層級定義各項設定。這項決定無法實行，因為這套解決方案讓他們無法輕易瞭解每個旋鈕開發人員在開發人員上的成就，也無法根據持續發展的產品組合進行擴充。這也包含額外的缺點：只要變更樹狀結構的根層級/祖系層級，就必須變更所有子項層級，才能取消設定或重設相關聯的元件。
在建構驗證時斷言
我們可以卸載問題，判斷建構是否使用正確的設定進行建構驗證，進而斷言每個版本關聯的正確依附元件。這解決了以下問題：確保建構的映像檔具有正確設定，但無法解決有聲/顯示設定問題，也不會改善理解特定設定中 SWD 堆疊行為時，免責情形。
修改/縮減 SWD 配置設定
我們調查了是否能夠修改 SWD 邏輯，以減少要變更為單一值的設定數量。遺憾的是，由於 SWD 堆疊是在多個套件與 zbi 的多個元件中實作，且所有設定均分散設定，因此我們認為這無法實現。