| RFC-0206：淘汰 stash | |
|---|---|
| 狀態 | 已接受 |
| 領域 |
|
| 說明 | 淘汰存儲服務，並遷移用戶端以使用儲存空間能力 |
| 問題 | |
| 更小鳥 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年月分) | 2022-12-08 |
| 審查日期 (年-月-日) | 2022-01-13 |
摘要
虛線服務未受維護，目前的實作項目不提供最初建立來提供的屬性。這個 RFC 提議淘汰掉落資料。我們會先將使用 stash 的用戶端遷移至 Fuchsia 的標準永久儲存空間功能，然後刪除提供穩定服務的三個元件。
提振精神
Stash 是簡單的持續性服務，最初是由需要在啟動程序早期存取永久可變動狀態的平台元件使用，通常是在軟體更新前存取。
如下所述，其中有三種不同的穩定通訊協定變化版本。所有變數都使用相同的基礎 FIDL 通訊協定，並以相同的二進位檔實作。本文件使用「stash」一詞涵蓋所有這些變體。
每次 Fuchsia 如果在軟體更新前讀取永久的可變動狀態，就可能有機會讓攻擊者保有存取權：如果攻擊者在先前的電源週期中能夠完全掌控裝置，就必須假設他們能夠將任意資料寫入裝置的永久可變動狀態。如果程式碼路徑中的安全漏洞，讀取了可變動的資料，這類攻擊者控制的資料就可能會在下一個重新開機時利用系統。如果在啟動程序初期發生讀取作業，則後果可能會更嚴重，攻擊者或許能阻止軟體更新發生，進而避免安全漏洞修補。
Stash 的用意是提供簡單安全的永久可變動儲存空間，供早期啟動使用，藉此降低上述情況的風險。資料表原本應有三種屬性：
- 最小 - Stash 應使用比完整儲存空間堆疊更小且更簡單的程式碼集，讓實作更容易審查，並降低錯誤的風險。
- 易於使用 - Stash 應可供用戶端使用，降低他們在與永久可變動狀態整合時發生錯誤的風險。
- 安全 - 由於穩定性的存在來提升系統安全性，因此本身的設計和實作不應造成新的安全性問題。
目前 Stash 無法提供下列大部分屬性：
- 極簡 - Stash 以 FIDL 伺服器的形式實作，在標準檔案系統頂端 (zxcrypt 上的 fxfs 或 minfs)。虛設常式比標準儲存空間堆疊簡單許多。理論上，日後可在不變更 FIDL 介面的情況下遷移至較簡易的儲存空間實作，但目前沒有任何計畫。
- 易於使用 - Stash 的主要用途是達成這項目標。其 FIDL 介面公開了具有少量資料類型的簡易鍵/值範例。這可讓用戶端程式碼保持精簡，並降低發生用戶端程式碼錯誤的可能性。因為必須處理回溯相容性、交易寫入和 FIDL 錯誤，這會造成一些複雜性，且用戶端仍需要編寫自己的輔助程式庫 (例如 wlan)。
- 安全 - 虛設假設的元件架構的設計會提供用戶端身分，讓 FIDL 伺服器能夠識別其用戶端。元件架構並不提供用戶端身分，而且未來也沒有計畫推出這個類型。這表示不同的虛線用戶端可以讀取及寫入彼此的資料，而通訊協定則會依賴典型的系統來避免這種情況。
雖然斷層最初是為了支援「早期啟動」元件，但還沒有正式定義 Fuchsia 的早期啟動階段，或列出哪些元件屬於「早期啟動」的清單。幾個 Stash 的用戶端不會在啟動程序早期啟動，而且所有現有用戶端都不會在啟動程序期間啟動。
自 2020 年起，Fchsia 管理了複雜的重複和隔離系統，以解決上述安全性問題 (請參閱 https://fxbug.dev/42124367)。
- 已定義三種不同的 FIDL 虛設通訊協定：
fuchsia.stash.Store、fuchsia.stash.Store2和fuchsia.stash.SecureStore。 - 這裡有三個不同的虛設元件，每個元件都是以獨立程序執行，且提供不同的通訊協定。
- 我們會仔細將 Stash 用戶端指派給三種通訊協定中的其中之一，並評估共用管道的用戶端，以確保他們能接受彼此讀取或寫入彼此資料的風險。
- 存在 BUILD 瀏覽權限清單，以防止在未經安全性審查的情況下新增新的 Stash 用戶端。
這種情況導致持續混淆和工程成本，但其效能和安全性財產不足。
相關人員
講師：
- Hjfreyer
審查者：
- atait (DHCP)
- brunodalbo (網路堆疊)
- ecstone (遷移)
- 埃及鎊 (Scenic)
- Jamuraa (藍牙)
- nmcracken (WLAN)
- Palmer (安全性)
- senj (Omaha Client)
- paulfaria (設定服務)
諮詢時間：
- 矽膠, wittrock, shayba, cgonyeo, erahm, mnck, jfsulliv
社會化：
這個 RFC 的早期草稿是由所有受影響客戶的利害關係人共同製定而成。
設計
我們想要淘汰除錯功能，並將大部分現有用戶端遷移至其他元件所使用的「資料」儲存空間功能。儲存空間功能是透過標準檔案系統 API 存取。對於大部分的元件而言，此遷移作業涉及使用序列化程式庫，將元件的永久資料結構轉換為元件寫入磁碟的位元組串流。讀取永久資料涉及讀取磁碟中的檔案，然後使用相同的程式庫去序列化，並填入元件的永久資料結構。
風景並未將虛線用於原定用途 (詳情請參閱 https://fxbug.dev/42173164)，而我們會將其用途遷移至結構化設定開發人員覆寫。
您最好將早期啟動的元件受攻擊面降到最低，且可能影響軟體更新是否成功。目前依賴 Stash 的網路和 SWD 元件在使用資料儲存空間能力時，應審慎評估，但是我們不會針對這些元件另外保留一組儲存空間存取要求。安全地將資料保存至儲存空間能力的最佳做法包括：
- 盡量減少保留的資料量。
- 使用範圍狹窄且明確定義的資料類型。
- 使用通過安全審查的序列化程式庫來封裝和解壓縮資料。
我們可以透過以下方式，根據想要的壓制屬性評估這項設計：
- 最小 - 整體複雜性與狀況類似：仍在使用序列化程式庫 (雖然用量從共同位置移至每個用戶端)。Fxfs (或 minfs 和 zxcrypt) 仍然存在。日後，採用較簡便的檔案系統仍可恢復提供儲存空間能力，不過這可能需要用戶端進行變更。
- 易於使用 - 易用性與現狀類似：用戶端必須與序列化程式庫互動，並執行基本的檔案系統作業，而非管理 FIDL 連線、交易和失敗。目前有許多使用儲存空間能力保留 Fuchsia 元件狀態的實作項目，且可以重複使用這些實作項目。
- 安全性 - 提升安全性：設計可保證元件之間隔離。我們使用已經過安全性審查且已用於實際工作環境的現有 Fuchsia 技術。
此外，此設計改善了其他幾項屬性：
- 由於我們移除三個元件執行個體，因此資源使用率較低
- 更容易將磁碟使用率歸因於使用元件
實作
如果接受這項提案，我們將清楚記錄隱形元件和所有免責通訊協定，做為淘汰項目。
接著我們會與這七個受影響的用戶端元件合作，共同商定遷移作業的計畫和大概時間表。在某些情況下，團隊的打算停止遷移 (例如 https://fxbug.dev/42172963)，而其他情況下，信任的平台服務團隊也可以協助進行遷移作業。這個 RFC 不會指定完成遷移作業的期限。
如果元件將重要資料儲存在「stash」中，則需要先進石版才能完成遷移作業 (也就是每部裝置在軟體升級程序期間必須通過的軟體版本)。在這個步驟的石頭發布階段，元件將能夠從收藏或儲存空間能力讀取其持續狀態，但會寫入儲存空間能力。通過此步驟石能確保在元件移除要讀取收藏的程式碼之前，資料已遷移至儲存空間能力。
我們與 Stash 用戶端合作規劃遷移作業時，致力盡可能減少必要的平台步進石發布作業數量。
當特定 stash 通訊協定的所有用戶端都完成遷移作業後，該通訊協定及其存續服務執行個體就會遭到刪除。系統會刪除保留二進位檔和最後一個通訊協定。
效能
本提案會刪除三個元件執行個體，藉此減少磁碟、記憶體和 CPU 使用率。
安全性考量
本提案透過保證早期啟動元件無法再讀取及寫入彼此的持續狀態，並且消除目前尚未維護的程式碼，藉此提升 Fuchsia 的安全性。
隱私權注意事項
本提案不會變更所收集和儲存的使用者資料組合。 由於早期啟動元件遭駭，無法再讀取其他元件儲存的 PII 資料，因此隱私做法稍有改善。
測試
現有的端對端測試和整合測試涵蓋使用 Stash 的儲存和擷取永久可變動狀態。這些測試也涵蓋使用基本儲存空間能力儲存與擷取此狀態狀態的測試。每個 Stash 用戶端都應新增整合測試，以驗證從暫存資料遷移至儲存空間能力。
說明文件
遷移作業完成後，系統會刪除現有收藏的說明文件。
考慮替代方案
替代方法 1：使用新的「基本」儲存空間能力
目前的提案建議使用現有的「資料」儲存空間能力，相同的解決方案是建立新的「基本」儲存空間，僅供早期啟動元件使用。
使用獨立的儲存空間能力可讓我們追蹤最終使用較簡單儲存解決方案的元件。使用「基本」儲存空間能力的元件遵循一系列最佳做法，可降低複雜度、降低錯誤風險，並簡化遷移至未來替代後端的作業。最佳做法包括：
- 使用核准的序列化程式庫來封裝及解壓縮資料。例如針對 Rust 元件的 serde
- 一次更新檔案內容。例如寫入暫存檔案，然後將暫存檔案重新命名為最終路徑
- 不要建立子目錄
- 請勿建立大於 X KB 的檔案
- 請勿建立超過 Y 個檔案
其中許多最佳做法都納入了簡化做法，我們得以在替代檔案系統中做出改善，藉此支援「基本」儲存空間能力。舉例來說，如果用戶端未使用目錄，則較不方便遷移至不支援目錄的簡易檔案系統。
資安團隊會維護一份清單，列出被視為「提前啟動」的元件。自動化工具會驗證這些元件是否只使用「基本」儲存空間能力，並在可行的情況下驗證其使用檔案系統的方式是否符合最佳做法。
這項解決方案的初始實作方式非常簡單：可由現有「data」fxfs 或 minfs 分區上的新子目錄支援「basic」。不過，要維持一致的「早期啟動」定義並建構工具，以便在這些早期啟動元件中強制執行資料持續模式，使用過程和工具成本可能相當可觀。
Fuchsia 不打算實作較簡單的檔案系統，藉此支援「基本」儲存空間能力。如果不使用不同的檔案系統，透過相同實作來維護兩組不同的用戶端組合，支出資源將無法帶來極大優勢，因此未能選擇這項解決方案。
替代方法 2：編寫早期可變動狀態的專屬用戶端程式庫
目前的提案建議使用現有的成熟程式庫，將可變動的持續狀態序列化。另一種做法是以各種目標語言編寫新的用戶端程式庫 (目前為 Rust 和 Go，未來可能會使用 C++)。
專用的用戶端程式庫可以輕鬆強制執行最佳做法，且比 serde 等現有一般用途序列化程式庫更小，也更容易使用。然而，設計及實作這些新的程式庫將大幅增加本提案的工程成本。現有用戶端會透過不同包裝函式來使用 Stash 來達成不同目的，因此單一用戶端程式庫可能無法滿足所有用戶端的預期。Stash 目前沒有人力，因此如果致力於設計及實作新用戶端程式庫，可能會導致遷移時間延遲一季。