RFC-0149：不需要 FIDL 編碼驗證

RFC-0149：不強制進行 FIDL 編碼驗證
狀態已接受
區域
  • FIDL
說明

不需要在 FIDL 編碼期間進行驗證。不過，在解碼期間仍會進行驗證，且在編碼期間邊框間距必須設為零。
變更
作者
審查人員
提交日期 (年/月)2021-11-19
審查日期 (年/月)2022-01-22

編輯此 RFC

編輯 RFC 中繼資料

摘要

不需要在 FIDL 編碼期間進行驗證。不過，在解碼期間仍會進行驗證，且在編碼期間邊框間距必須設為零。

提振精神

這個 RFC 的動機是減少設計限制，目前繫結必須在編碼期間通過驗證。這並不表示繫結必定會變更其行為，只是較不受限。事實上，在大部分情況下，這些 RFC 不太可能因此改變。

即便如此，在編碼期間也有許多原因會導致不執行驗證作業：

  • 編碼期間的效能，驗證作業會產生額外的負擔。舉例來說，具有結構編碼的快速路徑，如果結構中有需要驗證的列舉欄位，就無法從多個繫結縮減至 memcpy。對 HLCPP 繫結而言，效能影響特別重要，後者會引導進行兩次編碼的物件，一次進行編碼作業，一次驗證一次 (但可能會透過重新設計繫結的方式避免這種情況)。

  • 程式碼大小：驗證邏輯會增加程式碼大小。對於會產生程式碼或使用巨集的繫結而言，這個程式碼大小的增加最為重要，因為驗證邏輯會在輸出內容中多次重複。

相關人員

講師：pascallouis

審查人員：pascallouis、yifeit、mkember

顧問：

阿薩斯拉夫斯基

社群媒體化：

這份 RFC 發布於 FEC 討論郵寄清單。

設計

  • 繫結「可能」或「不一定」在編碼期間驗證 FIDL 物件。更精確來說，不再需要以保證物件在解碼期間一律通過驗證的方式對物件進行編碼。

  • 繫結必須確保在編碼後將邊框間距位元組為零。然而，編碼器本身不必加上邊框間距，例如能保證程式設計語言，可以完全零邊框間距。

  • 繫結「必須」在解碼期間驗證 FIDL 物件。

實作

這項 RFC 無法立即交付，繫結目前驗證 FIDL 物件且可能會繼續。不過，日後的繫結將可以放寬驗證檢查。

效能

效能影響的用途非常廣泛，且專屬於繫結。以下列舉驗證對效能的影響：

  • 在 Rust 中，使用 15 uint8s 和 1 個布林值的結構編碼是採用布林值驗證的 3.2 倍 (52ns) 較不驗證。如果結構包含 254 uint8s 和 1 個布林值，速度就會是 21 倍 (844ns)。不過在 LLCPP 中，同一個結構需要極少量的效能成本。系統會選擇這個測試案例，因為在許多繫結中，結構、陣列或向量主體中的單一布林值或列舉會導致 memcpy 最佳化作業無法進行最佳化。

  • 在 LLCPP 中，256 列舉的陣列編碼速度慢 2.2 倍 (2.6us)，在 Rust 中，Rust 的編碼速度變慢 1.2 倍 (192ns)，在有列舉驗證的情況下，速度較慢 9x (1.1us)。

  • 驗證後，HLCPP 物件編碼的速度慢 1 到 5 倍。16 元素資料表的編碼速度是 1.7 倍 (400ns)，而訊息標頭則慢 1.3 倍 (37ns)。

這些測量結果來自搭載 Intel Core i5-7300U CPU @ 2.60GHz 的機器。請注意，此為微型基準，實際效能可能有所不同。

用於這些基準的 CL：

人體工學

繫結人體工學應該沒有任何影響。但是，對於某些可能影響使用者的失敗模式，繫結期間停用驗證的繫結將不再快速「失敗」。

回溯相容性

這應該不會影響回溯相容性。

安全性考量

邊框間距位元組過去已零而非驗證，且會持續零。這點非常重要，因為 FIDL 物件可以在舊的配置之上配置，如果將記憶體複製到線，就會造成資料外洩。就大部分其他類型的驗證而言，外洩風險的風險較低。

驗證作業主要分為兩種類別。

值限制

  • Bool、Enum、Bit：驗證可確保支援這些類型的整數在預期範圍內。

  • Float - 浮點驗證目前並非規格的一部分，但繫結可能仍會執行部分驗證，特別是防止 NaN 值。

  • UTF-8 - FIDL 字串是酬載中採用 UTF-8 資料的向量。驗證可確保它們是 UTF-8。

這些類型的欄位通常是由使用者透過繫結 API 指派。驗證可確保使用者透過 API 提供有效輸入內容，而且不會發生其他形式的非預期錯誤更改值，例如記憶體毀損。請注意，在處理物件的任何階段中，可能發生記憶體毀損錯誤，而且在某種情況下 (例如 Bool 驗證) 可能會任意擷取到記憶體毀損錯誤。

  • 大小限制 - 特定物件 (例如資料表) 的大小設有限制。

傳輸時必須遵守特定的大小限制，例如管道傳輸的 64k 訊息大小上限，可避免訊息大小無限大量增加。因此，在觸及解碼器之前，通常不是需要解決的立即疑慮。

州/省錯誤

  • 非選用類型視為選用 - 主要是缺少酬載的非選用類型。

  • 信封內嵌位元 - 信封有欄位，指出資料是否應以內嵌方式儲存。您可能會遇到一個大小小於 4 位元組的信封，但應該以內嵌方式儲存，但缺少內嵌位元標記。

  • 向量缺少，但計數不為零：在編碼期間不應發生此情況。

如果在接觸解碼器前未察覺，這些措施都會造成嚴重的負面後果。這些漏洞通常是 FIDL 實作中的內部問題，可透過其他方式保證能夠修正。

結語

雖然會有需要考慮的安全疑慮，但這些疑慮通常能在解碼端攔截，而非編碼，因為它們具有低資訊外洩風險的風險。

隱私權注意事項

這不會影響隱私權。

測試

一般而言，測試需求會因為 RFC 而減少。

說明文件

FIDL 繫結規格需要更新，才能解決這個問題。

缺點、替代方案和未知

唯有在更多限制和彈性之間，這通常需要取捨。 驗證時，限制越多可以大幅增加的安全性優勢，靈活性則有助於改善效能和程式碼大小。這個 RFC 認為，安全性優點並不會太明顯，而 FIDL 應考慮移除這項要求。

移除規定後，繫結即可選擇保留或移除現有的編碼端驗證。實際上，繫結最終會盡可能移除這項驗證，但部分繫結可能會繼續在偵錯模式下進行驗證，以便提早找出問題。

先前的圖片和參考資料

無