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