RFC-0064：Box <Knox>

RFC-0064：Box <Knox>
狀態已遭拒
領域
  • FIDL
說明

導入透過與 FIDL 訊息相關聯的輔助 VMO 傳輸大型結構化資料物件的機制。
作者
提交日期 (年-月-日)2018-09-27
審查日期 (年-月-日)2020-06-17

編輯此 RFC

編輯 RFC 中繼資料

拒絕原因

透過 FIDL 在對等體之間傳輸大型郵件很重要。 以及開發人員目前面臨的難題，以及目前的 FIDL 缺乏狀況。 搭配使用管道限制，以便輕鬆定義 會超過這些限制的訊息 (視執行階段行為而定)，以及 由於視窗大小複雜 (例如「最大化」 分頁) 來簡化應用程式中的這個問題 程式碼 (至少大規模)。解決方案必須由 FIDL 提供。

簡單來說，FIDL 需要為圖書館作者提供一種方式 通訊協定階段限制 (例如嚴格限制 Zircon 管道的位元組數和帳號代碼)，以及 FIDL 開發人員 必須能夠仰賴繫結來實作可能會交換 大型訊息。

這個 RFC 中有許多理想的原料，可做為 請特別注意以下幾點：

  • 問題陳述和動機。
  • 開始使用靜態驗證，以保證 滿足通訊協定限制，或是選擇採用 並套用相應繫結(可能必須額外支付費用)
  • 仰賴不同值類型與資源類型來加以區分。 便利/效能方面的取捨

不過，即使發生上述情況，這個 RFC 仍會因為下列原因遭到拒絕：

  • 訊息方式也就是位元組和帳號代碼從對等點傳輸至另一個節點的 與傳輸格式問題無關，因此不能修改線 格式。
  • 導入 box<T> 標記法有助於識別訊息中的地點 例如拳擊次數等精細機制 在訊息中 (幾乎) 任意位置的行為。相反地 建議在方法層級提供註解 即簡略說明機制，只在網站使用，而非聲明 網站。
  • 隨著 FIDL 逐漸通用，針對 Zircon 管道 我們必須考量 且有其限制例如我們期望將 FIDL 擴充為 Zircon 資產的大小限制則不同，並且不允許有帳號代碼。 這會進一步顯示方法層級註解 (而非以類型為中心) 的檢視畫面 註解)。

現今，為了在應用程式中解決這個問題，我們採用 fuchsia.mem/Data 類型，代表資料的聯集。 內嵌或 VMO 中對任何要求和/或回應採取這種做法 使用語法糖 (與錯誤時相同) 搭配繫結 支援服務，就是目前這項主題的後續主要競爭者。

摘要

加入透過 與 FIDL 訊息相關聯的輔助 VMO。

提振精神

FIDL 訊息的大小上限 會在程序之間透過 Zircon 管道傳輸，如 ZX_CHANNEL_MAX_MSG_BYTES.在本文撰寫期間， 包含 FIDL 標頭在內，上限為 64 KB。

雖然限制對許多應用程式來說已足夠，但偶爾 傳送大型物件這讓 FIDL API 面臨挑戰 因為他們必須設計替代的方法 物件，例如：

  • 分頁：傳送物件集合 (通常是向量) 時 透過批次方式提供物件，而不是一次一次提交所有物件。
    • 只要個別物件小於限制，也可使用 (將標頭和其他欄位納入考量)。
    • 開發人員決定如何封裝物件有點困難 有效率地整理為郵件，避免超出上限 目前沒有用來估算 FIDL 訊息大小的 API 逐步建構這個元件
  • VMO 封裝：而不是在 FIDL 內傳輸大型物件 請將訊息複製到 VMO 中通常以 fuchsia.mem/Buffer。
    • 適合位元組向量 (blob)。
    • 結構化資料物件有點麻煩，因為開發人員負責 叫用序列化/去序列化作業。
    • 需要專業人士來緩解共用記憶體帶來的安全威脅。

如果不預期這個問題是執行階段不穩定的主要原因，

我們認為 FIDL 應提供內建、安全和靜態的 且且高效傳輸大型資料物件的機制。

設計

概要

方塊是一個容器，用來存放您可能 可能需要處理的可能大型資料物件 當郵件總大小 (包含標頭) 超過大範圍時，波紋。 則 Zircon 頻道的數量上限1。

方塊只會保存資料物件；無法容納含有 帳號代碼2。

在設計時間中，FIDL 通訊協定作者。

  • 當預期資料物件預期會傳送訊息時，就會將資料物件封裝至方塊內 包含這些物件可能會超過管道限制

在編譯時間時，FIDL 編譯器...

  • 剖析宣告
  • 靜態驗證每個方塊中是否只包含資料物件 (無控點)
  • 靜態驗證每個 FIDL 訊息的可能大小上限 不得超過管道限制 (強制使用靜態郵件大小 模式))
    • 會假設向量和字串的寬度與邊界相符
    • 假設可延伸的聯集和結構體 (資料表) 與 可能有
    • 拒絕遞迴結構，除非遞迴作業按箱子破損

在編譯時間時，每個 FIDL 程式碼產生器...

  • 產生的程式碼足以將裝箱資料序列化及還原序列化

在 runtime 為 FIDL 編碼器。

  • 將各種盒裝和盒子裝箱盡可能放入郵件內文中 其他離線物件
  • 裝入所有不符合 VMO 的裝箱物件

runtime 為 FIDL 解碼器。

  • 存取含有裝箱物件的 VMO (如有) 之前，請確定 具備 VMO 的唯一控制代碼 (VMO 未共用)
  • 從訊息內文和 VMO 擷取裝箱物件

語言詳細資料

我們推出全新的內建 FIDL 類型，稱為 box<T>。T 會指定 要放入箱中的物件類型

  • T 必須是非直接或間接包含的參照類型 控制代碼
  • T 不得為原始類型。
  • T 可以是選用類型。

新的類型 box<T> 可用於任何參照類型，例如 結構體、 可接受「聯集」、「向量」和「字串」。

方塊類型範例

  • box<string>
    • 包含不受限字串的方塊
  • box<int>
    • 錯誤：方塊不得包含原始類型的物件
  • box<vector<T>:100>
    • 方塊中有 T 限制向量的方塊
  • box<vector<T>>
    • 內含無界限 T 物件向量的方塊
  • vector<box<T>>:100
    • 盒裝 T 物件的限定向量。
  • box<string:100>
    • 包含受限字串的方塊
  • box<string>
    • 包含不受限字串的方塊
  • box<MyStruct>
    • 方塊裡有
  • box<MyStruct?>
    • 內含選用結構的方塊
  • box<MyStruct>?
    • 錯誤：方塊不可為選用

宣告範例

interface Database {
    // OK
    1: SelectTop(string:1000 query) -> (box<Record> record);

    // ERROR: reply may exceed message size limit
    // consider wrapping large objects in a box<>,
    // "Record" size is unbounded
    2: BadSelectTop(string:1000 query) -> (Record record);

    // OK
    3: SelectAll(string:1000 query) -> (box<vector<Record>> records);

    // ERROR: reply may exceed message size limit
    // consider wrapping large objects in a box<>,
    // "vector<Record>" size is unbounded
    4: BadSelectAll(string:1000 query) -> (vector<Record> records);
};

struct Record {
    string name;
    string address;
};

線材格式

(本節內容不完整。)

提案 1：在深度優先遍歷期間，執行了所有方塊的序列化作業 則先按照 未使用函式，直到空間用盡為止，然後計算剩餘的物件大小 裝箱物件、分配單一 VMO，以及從 好

提案 2：就像想法 1，但將每個方框都放在自己的 VMO 中， 但可能會變得更加限制

提案 3：也許我們應該完全丟出盒子，到處做點東西 包括註解等方法的層級[Huge]

繫結

(本節內容不完整。)

強化型 VMO 即時通訊呼叫

(本節內容不完整。)

提案 1：定義「不可共用」標記，確認 VMO 只有一個帳號代碼 不會與其他 VMO 共用任何頁面，而且未對應，因此可以將這個標記傳送至 zx_vmo_read/write/map 等

提案 2：定義新的系統呼叫，檢查 VMO 是否未共用

提案 3：確實檢查 VMO 的反向快照 (如果 VMO 已完成) 未共用 (應為免人工管理)

提案 4：在 VMO 上尋找並改用 View

執行策略

(本節內容不完整。)

人體工學

(本節內容不完整。)

說明文件和範例

(本節內容不完整。)

回溯相容性

除了提供轉移大型資料物件的機制外， 也有助於解決靜態安全疑慮。

目前，嘗試傳送超過管道的 FIDL 訊息的程式 限制會在執行階段失敗，造成系統不穩定。一旦方塊正確 ，應可導入靜態郵件大小強制執行 ，我們就保證編譯時間沒有 會超過管道限制這些額外內容 FIDL 通訊協定作者已把盒子移至盒子裡。

不過，一次啟用靜態郵件大小的強制執行設定可能會導致現有郵件大小 並妨礙遷移工作

建議採取下列做法來解決這個問題：

  • 一開始，請在寬容模式中啟用靜態郵件大小檢查功能。
    • FIDL 編譯器應在管道時檢查訊息大小，並發出警告 可能超出上限建議 FIDL 通訊協定作者 就改用方塊了
  • 繼續進行遷移。
  • 完成後，請在強制執行模式中啟用靜態郵件大小檢查功能。
    • FIDL 編譯器應檢查訊息大小，並在管道時發出錯誤 可能超出上限暫停編譯。

成效

(本節內容不完整。)

安全性

將現有的臨時機制替換為 FIDL 語言繫結，我們有機會提高整體安全性 紀實

舉例來說，FIDL 語言繫結可確保含有盒裝的 VMO 僅有一名擁有者嘗試存取其內容。這個 可解決常見的共用記憶體威脅，例如：

  • VMO 的供應商在用戶端存取資料時修改了資料。
  • VMO 的供應商變更存取 VMO 時的大小 用戶端或以其他方式引發用戶端錯誤。

相反地，導入這項功能可能會提高大型資料集的使用率 進而提高其他威脅的可能性，例如：

  • VMO 的供應商向用戶端傳送大量回覆，導致用戶端 在還原序列化時配置大量堆積

測試

(本節內容不完整。)

缺點、替代方案與不明

(本節內容不完整。)

既有作品和參考資料

(本節內容不完整。)

編輯器附註：已拒絕 RFC-0062：方法不可能，但建議使用 禁止所有可能超出通訊協定限制的方法。重複 基於靜態分析的限制，導致無法擷取 執行階段行為以正確分頁訊息，或手動「裝箱」具體做法是指示 Kubernetes 建立並維護 一或多個代表這些 Pod 的物件

  1. 假設，系統可能會透過其他拳擊管道傳送 FIDL 可能適合不同的大自然實作方式超出範圍 對於這個提案 ↩

  2. 編註：這個 RFC 是在 2018 中編寫而成，因此 值類型和資源實際上是 FIDL 語言的一部分，請參閱 RFC-0057。↩