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