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

摘要

這項 RFC 提案旨在提供權宜之計，定義易於理解且範圍明確的政策，讓所有開發人員都能瞭解在執行 Fuchsia 的裝置上可執行和不可執行的軟體，並確保不會意外運送安全性較低的設定，進而提升軟體交付 (SWD) 政策設定的可見度、理解程度和可擴充性。

目前的提案預計會維持現狀，直到子組件式產品組裝功能推出，屆時就能針對不同產品用途制定更明確的政策。這項提案中的中介作業可簡化系統組裝樣式設定的轉換程序，因為集中套用 SWD 政策的作業已完成。

提振精神

SWD 設定是強制執行已驗證執行的必要條件。目前，SWD 設定會分散在多個設定檔和套件中，這些檔案和套件會相互作用，以決定裝置上的實際 SWD 設定。這項 RFC 的目標是降低瞭解產品 SWD 狀態的複雜度。加入經過充分瞭解且經過審慎考慮的政策，也能簡化並確保新增產品和變種版本的流程，減輕確保套用正確設定的負擔。

設計

目前，這項 RFC 提議了三項 SWD 政策。他們希望以語意而非產品導向的命名方式，正式制定 SWD 政策設定。這些政策會套用至產品定義，以更全面的方式定義 SWD 狀態，且產品負責人會選取其中一項可用政策，而非調整各項設定。

我們可能會視需要新增更多政策，但預計這組政策的數量遠少於產品和建構變體的成長量。

政策定義

僅限基本元件

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

本機動態設定

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

無限制

程式碼的執行或顯示方式不受任何限制。這是最寬鬆的 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 政策設定。

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

這項變更是短期解決方案，等到平台子組件推出後，我們就能更精細地控管建構程序。這項工作會記錄在子組件 (fxr/553664) 和結構化設定 (fxr/549661) 的進行中 RFCS 中。

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

調查的替代方案包括：

不進行任何變更

我們可能會繼續處於目前的環境，也就是每個產品都能修改自己的設定，且每個產品會繼續從祖先的聯集隨機繼承。

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

修改產品定義

這與目前做法類似，但我們會在每個層級定義設定，而不是在產品定義的繼承樹狀結構中隨機定義各種設定。這項做法不可行，因為開發人員必須知道每個旋鈕的功能，而且無法因應不斷增加的產品。此外，樹狀結構根層級/祖先層級的任何變更，都必須變更所有子層級，才能取消設定或重設相關聯的元件，這也是額外的缺點。

在建構驗證時間進行判斷

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

修改/減少 SWD 設定組合

我們調查是否能修改 SWD 邏輯，將要變更的設定數量減少至單一值。很遺憾，由於 SWD 堆疊是在多個套件和 zbi 的多個元件中實作，且設定分散在所有元件中，因此這項要求被認為不可行。