| RFC-0090：允許使用驅動程式共用程式庫 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 為驅動程式共用程式庫新增許可清單。 |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2021-03-30 |
| 審查日期 (年-月-日) | 2021-04-28 |
摘要
這項 RFC 建議驅動程式架構新增共用程式庫的明確允許清單，供驅動程式依附。Fuchsia 樹狀結構會在建構時檢查這份許可清單，Driver Manager 則會在執行階段檢查。如果驅動程式依附的共用程式庫不在允許清單中，系統就不會執行該驅動程式。
這項 RFC 是為了將驅動程式庫作者與驅動程式架構之間長期以來的非正式協議，驅動程式作者目前瞭解不應依附於無關的共用程式庫，但目前沒有明確的共用程式庫允許清單。
問題陳述和動機
Fuchsia 中的驅動程式是以共用程式庫的形式實作。驅動程式會載入驅動程式主機。 驅動程式主機代表單一程序，可容納多個驅動程式。驅動程式本身可以依附其他共用程式庫，這些程式庫也必須載入驅動程式主機。
由於驅動程式及其共用程式庫都存在於同一程序中，共用程式庫可能會以不明顯且未定義的方式發生衝突。樹狀結構外建構的驅動程式可能會嘗試連結至另一個驅動程式庫使用的相同共用程式庫，但版本較新或較舊。如果兩個共用程式庫中都有相同符號的多個實作項目，符號解析就會變得不確定。此外，共用程式庫中的全域變數可能會被視為相同驅動程式主機中驅動程式之間非預期的共用狀態。如果沒有允許清單，驅動程式可能會開始透過不支援的共用程式庫進行通訊。基於安全性和正確性考量，Driver Framework 必須禁止驅動程式使用不支援的共用程式庫。
這份 RFC 建議的解決方案是，為驅動程式提供建構時間和執行階段的共用程式庫允許清單。如果共用程式庫不在允許清單中，驅動程式就無法連結至該程式庫。這份許可清單上的所有共用程式庫都會由 Fuchsia 平台提供，而非由個別驅動程式提供。
如要長期解決這個問題，請使用命名空間動態連結器。有了這類連結器，每個驅動程式庫在程序中都會有自己的「命名空間」，驅動程式的共用程式庫也不會發生衝突。如果驅動程式架構有命名空間動態連結器，就不再需要共用程式庫允許清單。
立即採用的好處
驅動程式架構正在導入兩項新功能，需要嚴格的允許清單：樹狀結構外的驅動程式和驅動程式庫套件。這兩項功能都會從新位置載入驅動程式，因此系統如何處理驅動程式的共用程式庫會變得模稜兩可。明確規定驅動程式的共用程式庫會從 Fuchsia 平台載入，可減少系統模糊性，並確保每個驅動程式庫在執行階段取得相同版本的共用程式庫。如要將所有驅動程式的共用程式庫保留在 Fuchsia 映像檔中，必須先建立共用程式庫的允許清單。
設計
驅動程式架構會維護驅動程式可連結的共用程式庫清單。這份清單的初始內容，是驅動程式目前連結的所有共用程式庫。您可以新增或移除清單中的程式庫，但必須取得 Driver Framework 團隊的授權。
這份許可清單上的所有共用程式庫，都會由 Fuchsia 平台提供。許多這類共用程式庫會以啟動檔案系統項目形式存在於 ZBI 的 /boot/lib/，因此可由驅動程式在早期啟動時載入。驅動程式的載入器服務只會載入許可清單中的共用程式庫，不會載入個別驅動程式提供的程式庫。
如果共用程式庫不在允許清單中，驅動程式就無法連結至該程式庫。如果驅動程式庫嘗試連結至不在清單中的共用程式庫，驅動程式架構就會產生建構時間錯誤。如果載入的驅動程式庫嘗試存取不在清單上的共用程式庫，驅動程式管理員就會記錄執行階段錯誤。
新共用資料庫的考量條件
Driver Framework 團隊可視需要將新的共用程式庫加入許可清單。建立新的共用程式庫時，請考量下列事項：
- 程式庫大小。如果共享相片庫要儲存在 ZBI 中，必須有足夠空間。 如果程式庫會儲存在儲存空間中，這就比較不重要。
實作
系統會根據驅動程式目前使用的共用程式庫清單產生許可清單。 接著，系統會實作在建構時檢查許可清單的機制。之後，系統會實作在執行階段檢查許可清單的機制。由於初始清單會保留驅動程式目前使用的所有共用程式庫，因此不需要變更驅動程式庫。
您可以在 Driver Framework 中使用自訂 fuchsia.ldsvc.Loader 實作項目，完成執行階段實作。這項導入作業不需要對程式碼庫的其他區域進行架構變更。
效能
這項異動不會影響成效。
安全性考量
這項提案對安全性有正面影響。這項功能可讓驅動程式的共用程式庫使用情形更易於稽核，並減少因共用程式庫衝突而導致未定義行為的機率。
隱私權注意事項
這項做法可能會對隱私權帶來正面影響，因為這樣一來，驅動程式之間共用狀態的介面就會減少。
測試
我們會先實作建構時間檢查，也就是主要測試樹狀結構是否正確建構。目前沒有樹狀結構外的驅動程式，因此如果樹狀結構建構正確，所有驅動程式都會符合共用程式庫允許清單。
實作建構時間檢查後，系統會實作執行階段檢查，以支援日後的樹外驅動程式。這會包含整合測試。
說明文件
這份 RFC 是我們決定建立許可清單的說明文件。
允許清單的詳細資料將新增至 fuchsia.dev 網站的驅動程式庫教學課程。 包括要求和核准許可清單變更的程序。
缺點、替代方案和未知事項
缺點是如果我們有命名空間限定動態連結器，就不需要這個許可清單。如果該連結器存在，我們就能重新評估並可能移除許可清單。
允許清單會限制驅動程式庫可連結的共用程式庫數量，但可能無法確保共用程式庫是相同版本。樹狀結構外的驅動程式可能會嘗試以允許清單中的新版共用程式庫為基礎建構，但系統在啟動檔案系統中使用舊版程式庫時，可能會在執行階段失敗。實作允許清單後，可能需要後續作業，確保樹狀結構外的驅動程式是根據相同版本建構。
另一個缺點是，驅動程式庫擁有者可能會透過靜態連結程式庫，回應共用程式庫允許清單。使用靜態連結程式庫會增加驅動程式的程式碼大小。這是這種做法的必要副作用，雖然令人遺憾，但無法避免。如前所述，這個問題的長期解決方案是命名空間動態連結器，可讓驅動程式使用共用程式庫，不必加入允許清單。
既有技術和參考資料
Zircon 建構版本原本有驅動程式的共用程式庫許可清單。為簡化整合程序，我們在 Build Unification 期間移除了這份允許清單。我們一直打算重新實作這項功能，但直到現在才將其列為優先事項。
Driver Manager 目前有共用程式庫允許清單的執行階段實作項目，但從未啟用。目前已透過核心指令列選項「devmgr.devhost.strict-linking」啟用該功能。為實作許可清單，這項實作方式將會更新。