RFC-0118：圖片組合的 SWD 政策

摘要

本 RFC 提出了一種暫時性解決方案，可透過定義易於理解且範圍明確的政策，讓任何開發人員都能瞭解哪些軟體可以在執行 Fuchsia 的裝置上執行，哪些軟體無法執行，並確保他們不會意外發布安全性較低的設定。

在以子組件為基礎的產品組合允許針對不同產品用途定義更明確的政策之前，目前的提案將維持現有形式。由於已完成將 SWD 政策應用集中化的工作，因此本提案中的中介作業可讓您更輕鬆地轉換至系統組合式設定。

提振精神

強制執行驗證作業時，SWD 設定是不可或缺的要素。目前，SWD 設定會分散在多個設定檔和套件中，這些檔案和套件會彼此互動，以決定裝置上的實際 SWD 設定。此 RFC 旨在降低瞭解產品 SWD 狀態的複雜度。加入可確實理解且經過深思熟慮的政策，也能讓新增產品和變化版本更簡單、更安全，減輕確保正確套用設定的負擔。

設計

目前，這項 RFC 提出了三項 SWD 政策。他們的目標是透過語意而非產品導向的命名，將 SWD 政策設定正式化。這些政策會套用至產品定義，以便以更全面的方式定義 SWD 狀態，並

我們可能會視需求新增更多政策，但這套政策的數量預計會遠低於產品和版本變化版本的數量。

政策定義

僅限基本元件

所有可執行的程式碼都必須直接驗證 (在基礎層)。所有可設定的 SWD 限制都會設為預設安全狀態：不允許快取的動態設定，且執行限制已開啟，也就是說，只有基本和許可清單元件可解析及執行。

本機動態設定

允許動態設定存放區，並手動解析間接驗證的程式碼 (Universe 套件/暫時性元件)，但前提是使用者必須有實體存取權 (例如開發人員)。

無限制

程式碼的可執行性或可見性沒有任何限制。這是最寬鬆的 SWD 設定，可允許外部程式碼和動態設定，並停用可執行性限制。

政策表

實作

本 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 政策設定。

缺點、替代方案和未知事項

這項異動是短期解決方案，直到平台子組件可讓我們更精細地控管建構程序為止。這項工作已納入子組件的待處理 RFC (fxr/553664) 和結構化設定 (fxr/549661)。

這項變更的主要注意事項是，這會將套件/相依項目的納入方式從產品定義中抽象化。

我們調查的替代方案包括：

不進行任何變更

我們可以繼續使用目前的環境，讓每項產品都能修改自己的設定，並繼續隨機繼承其祖系的聯合體。

不過，隨著 Fuchsia 產品的數量迅速增加，我們提出這項提案，希望能主動改善 SWD 設定機制，避免產品套用錯誤的 SWD 狀態，進而破壞 Fuchsia 平台的核心安全假設。

修改產品定義

這與目前的做法類似，但我們會在各層級定義設定，而非在產品定義的繼承樹狀結構中隨機定義各種設定。我們判定這項做法不可行，因為這會讓開發人員負責瞭解每個旋鈕的功能，而且無法擴展至不斷增加的產品組合。這也帶來了額外的缺點，也就是對樹狀結構的根/祖系層級進行任何變更時，必須變更所有子層級，才能取消設定或重設相關聯的元件。

在建構驗證期間斷言

我們可以將判斷版本是否使用正確設定的問題，轉移至版本驗證，以便斷言每個版本都與正確的依附元件相關聯。這可解決確保已建構映像檔具有正確設定的問題，但無法解決可聽度/可視度問題，也無法改善在特定設定下瞭解 SWD 堆疊行為的人體工學。

修改/減少 SWD 設定

我們調查是否可以修改 SWD 邏輯，以減少變更設定的次數，並將其縮減至單一值。很遺憾，這項做法被視為不可行，因為 SWD 堆疊是在多個套件和 zbi 的多個元件中實作，且設定分散在所有元件中。