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

摘要

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

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

提振精神

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

設計

目前，這項 RFC 提議了三項 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 的多個元件中實作，且設定分散在所有元件中，因此這項要求被認為不可行。