RFC-0218：IOBuffer：適合有效率的 IO 共用記憶體物件

摘要

我們提出了全新的 IOBuffer 核心基元，以提高安全性、便利性 和分散式 IO 使用案例的 和選用的核心中介作業

提振精神

大多數 Fuchsia 作業系統都在使用者空間中實作， 並分散儲存在多個通訊程序與元件中這個 刻意設計的設計選擇通常涉及更多程序和執行緒，而不是 單體系統中的對等實作 類神經網路會直接在單體式核心中實作雖然 這種分散式方法對安全性、開發、 以及可更新的功能，這項重要差別在於許多作業都需要 富希西亞的處理序間通訊 (IPC) 單體式核心此外，採用現有的 Fuchsia 管道與通訊端，可執行 IPC 基元涉及多個系統呼叫、模式切換、執行緒躍點和資料 完成端對端作業。這種負擔可能會產生 對通訊和 IO 工作負載而言尤其重要 大量資料、高頻率和/或低延遲作業

原則上，共用記憶體能夠避免這部分或全部 同時保有 Fuchsia 使用者空間區隔的優點 模型不過，原始共用記憶體有一些限制 可靠且可靠的通訊管道 涉及多個客戶、信任程度或可靠性有所差異，或 共用資源

以下列舉幾個挑戰：

• 安全性和正確性：直接存取共用記憶體通訊模式 都難以應對濫用或濫用行為的彈性 可能會產生重大負擔重要的是，系統呼叫 也可驗證任意記憶體存取行為
• 同步處理：直接存取記憶體，適用於有限的同步 是架構記憶體模型以外的機制
• 生命週期與工作階段：記憶體存取範圍難以判斷 並運用現有的基石強制執行

這個提案是個務實的做法，可以解決這些問題和其他挑戰 運用 Zircon 對等互連物件模型，提升工作階段管理效率 使用核心做為受信任的中介平台，履行義務。

相關人員

講師：

• cpu@google.com

審查者：

• adanis@google.com
• rashaeqbal@google.com
• fmeawad@google.com
• gmtr@google.com
• maniscalco@google.com
• johngro@google.com
• abarth@google.com
• cpu@google.com

諮詢：

• miguelfrde@google.com
• puneetha@google.com
• mseaborn@google.com
• mcgrathr@google.com
• quiche@google.com
• mvanotti@google.com
• brunodalbo@google.com

社交功能：

RFC 經過了 Fuchsia Performance 的設計審查和疊代 「診斷」和「Zircon Performance Tools」WG。

設計

IOBuffer (IOB) 設計推出了一種新的記憶體物件類型，以提升效率 服務、通訊和分散式 IO新物件會封裝多個記憶體 擁有不同屬性和角色的單一連貫實體 實用的生命週期管理、存取權控管，以及核心中介作業。

IOB 是與兩個端點的對等互連物件組合。這個端點 類似的生命週期管理和信號與其他對等物件一樣，例如 管道、通訊端、FF 和事件組合除了存取權控管之外 每個記憶體區域的存取權 分別為各個端點設定 資源。

可設定的核心系統支援更進階的安全性屬性 作業，其中記憶體存取會由系統代表使用者執行 核心 Synel sys 呼叫，核心擔任信任的中介者 會遵循要求的存取權規則採用中介服務的營運方式會增加 穩固可靠，同時降低端對端的負擔 具備多種通訊基元

生命週期管理、記憶體區域封裝、 可設定的存取權控管機制，核心中介服務作業則支援 各種共用記憶體通訊及 IO 模式，且更加安全 方便且方便的特徵是來自於其他獨立模型的類似結構 如需儲存大量結構化物件 建議使用 Cloud Bigtable

目標

此提案具有以下高階目標：

• 減少記憶體配置數量，以縮小單體系統的效能落差。 以及排程的通訊和 IO 負擔。
• 簡化共用記憶體生命週期管理和同步處理作業。
• 必要時，強制執行高強度的安全性不變。
• 為日後的核心介面和使用者介面介面提供基礎。

端點

每個 IOB 都有兩個端點：Ep0 和 Ep1。IOB 端點帳號代碼可能會重複 並由多個程序共用基礎記憶體物件 前提是至少有一個端點帳號代碼，並提供類似的 IOB 與其他對等物件的生命週期語意。

記憶體區域

IOB 會封裝一或多個記憶體區域的集合， 獨立財產和存取權控管，支援各個區域的預期目標 角色。例如不同區域 鍵/值儲存庫、用戶端協調、狀態管理 資料酬載傳輸

存取權控管

在 IOB 期間，系統會為每個端點和區域組合設定記憶體存取 建立。每個端點可能都會獲得不同區域的不同存取權限。 發生以下情況時，區域存取權控管機制會與端點的控制權限結合 驗證作業該作業的有效權利可能比較嚴格 ，但不得超過帳號代碼權利許可上限。

記憶體存取權也可以透過核心中介 沒有對應。

下表列出與瀏覽器相關的三種存取權控管類型 區域。您可以設定對應 (使用者) 和中介服務 (核心) 存取權控管。 端點則來自於控制點 啟動該作業。

有效存取 eRn 和 eWn，供地圖或中介服務作業使用 端點 Epn 的計算方法如下：

中介存取控制與方向

使用者與核心的存取權控管機制之間有細微差異： 控制讀取或寫入權限，而後者是在 邏輯或方向性例如：由核心協調的讀取作業 可能包括更新區域中的簿記資料結構 從緩衝區讀取大量資料就此情況來說，唯讀存取權沒有 會讓核心無法更新簿記，而是只會指出 邏輯讀取作業和相關的簿記更新則在允許範圍內。

範例

以下示意圖描述的 IOB 具有三個記憶體區域， 邏輯函式。這些端點 Ep0 和 Ep1 有邏輯地指派給伺服器 和客戶帳戶角色

1. 區域 0「控制組」：
   • Ep0：RW 對應存取權。
   • 第 1 集：RO 對應存取權。
   • 用途：伺服器會在這個區域中寫入不可分割變數來發布狀態 來協調用戶端的活動。
2. 區域 1「字串地圖」：
   • Ep0：RO 對應存取權。
   • 第 1 集：採用中介服務的 WO 存取權。
   • 用途：用戶端會使用核心中介作業將字串內部化。 伺服器會透過對應關係，解譯不受鎖定。由於 用戶端存取權僅限於中介服務，因此用戶端不得竄改字串 並排除潛在檢查時間 可能存在危險。
3. 區域 2「資料環形緩衝區」：
   • Ep0：RW 對應存取權。
   • 第 1 集：RW 對應存取權。
   • 用途：用戶端和伺服器都可透過對應方式直接存取這個區域 接受協議的通訊協定，並接受潛在的完整性問題。

創作

您可以透過呼叫 zx_iob_create 以及一組選項來建立 IOB。

zx_status_t zx_iob_create(uint64_t options,
                          const zx_iob_region_t* regions,
                          uint32_t region_count,
                          zx_handle_t* ep0_out,
                          zx_handle_t* ep1_out);

參數

• options 保留給日後的擴充功能使用。

• regions 是 zx_iob_region_t 區域說明陣列的指標。

• region_count：指定區域陣列中的元素數量。

• ep0_out、ep1_out 是 IOB 端點

區域說明

區域的幾何圖形和設定由 zx_iob_region_t 指定 區域的說明結構基本結構包含 並套用至所有區域類型

struct zx_iob_region_t {
  uint32_t type;
  uint32_t access;
  uint64_t size;
  zx_iob_discipline_t discipline;
  union {
    zx_iob_region_private_t private_region;
    uint8_t max_extension[4 * 8];
  };
};

• type 會指定支援該區域的地區與記憶體物件類型。

  • 類型 0：私人區域。
  • 類型 1+：保留供日後使用。

• access 會指定每個端點的存取權控管修飾符。回憶 存取主體「可以」指定有效的存取位元組合 支援安全性或正確性屬性

  • 位元 0：Ep0 的 uR0 對應。
  • 位元 1：Ep0 的 uW0 對應。在某些系統上可能暗示 uR0。
  • 位元 2：kR0 透過中介服務存取 Ep0 的權限。
  • 位元 3：kW0 透過中介服務存取 Ep0 的權限。
  • 位元 4：Ep1 的 uR1 對應。
  • 位元 5：Ep1 的 uW1 對應。在某些系統上可能暗示 uR1。
  • 位元 6：kR1 提供 Ep1 的中介服務存取機制。
  • 位元 7：kW1 透過中介服務存取 Ep1 的權限。
  • [8..31]：保留供日後使用。

• 「size」是要求的區域大小，以位元組為單位。系統會將大小四捨五入 最多可達系統頁面大小邊界使用「zx_object_get_info」搭配主題 ZX_INFO_IOB_REGIONS 用來決定區域的實際大小。

• discipline 會指定要使用的記憶體存取規範 核心中介作業」。

區域類型 0：私人

指定由 IOB 擁有的私人記憶體物件支援的區域。 這個記憶體物件只能透過對下列項目執行、 和自有的 IOB

struct zx_iob_region_private_t {
  uint64_t options;
};

• options。

區域類型 1+：預留供日後使用

日後的擴充功能可能會包含共用區域類型，其中相同的記憶體物件 由多個 IOB 共用，以支援高效率的多虛擬服務專員協調作業。

對應

呼叫 zx_vmar_map_iob 對應 IOB 的記憶體區域。這場通話 和 zx_vmar_map 有類似的語意。

zx_status_t zx_vmar_map_iob(zx_handle_t vmar,
                            zx_vm_option_t options,
                            size_t vmar_offset,
                            zx_handle_t ep,
                            uint32_t region_index,
                            uint64_t region_offset,
                            size_t region_len,
                            zx_vaddr_t* addr_out);

參數

• vmar 是 VMAR 控制代碼，用於對應區域。
• options 等同於 zx_vmar_map 的 options 參數。只有 支援下列選項
• vmar_offset 等同於 zx_vmar_map 的 vmar_offset 參數。
• ep 是包含要對應的區域的端點。
• region_index 是要對應的記憶體區域索引。
• region_offset 等同於 zx_vmar_map 的 vmo_offset 參數。
• region_len 等同於 zx_vmar_map 的 len 參數。
• addr_out 是傳回參數的虛擬地址。

支援的選項：

• ZX_VM_SPECIFIC
• ZX_VM_SPECIFIC_OVERWRITE
• ZX_VM_OFFSET_IS_UPPER_LIMIT
• ZX_VM_PERM_READ
• ZX_VM_PERM_WRITE
• ZX_VM_MAP_RANGE

其他保留選項供日後使用，並傳回 ZX_ERR_INVALID_ARGS (如果 。

對應私人區域的功能與對應無法調整大小的對應功能相同 VMO。如果對應超出結尾的結尾，則傳回 ZX_ERR_BUFFER_TOO_SMALL 系統不會設定記憶體物件和 ZX_VM_ALLOW_FAULTS

最佳做法包含 region_offset 和 region_len 參數 對應 API。這項最佳做法的動機包括：

• 支援攔截對應呼叫的消毒液。使用明確範圍 可簡化追蹤活躍地圖區域的追蹤作業。
• 支援沙箱機制，明確管理位址空間放置作業， 區域覆寫
• 更廣泛來說，避免在使用 ZX_VM_SPECIFIC_OVERWRITE。

VMAR 作業

對應區域通常支援 VMAR 作業，例如 zx_vmar_protect。 zx_vmar_op_range，zx_vmar_destroy。某個區域的存取準則「可能」修改 或限制這類作業

物件資訊查詢

IOB 支援透過 zx_object_get_info。傳回的詳細資料包括 這些記憶體物件，用於驗證和安全用途。

主題 ZX_INFO_IOB

傳回整個 IOB 執行個體的相關資訊。

struct zx_iob_info_t {
  uint64_t options;
  uint32_t region_count;
  uint8_t padding1[4];
};

成員

• options 是傳遞至 zx_iob_create 的 options 參數值。
• region_count 是 IOB 中的區域數量。

主題 ZX_INFO_IOB_REGIONS

以 IOB 陣列形式，傳回各區域的相關資訊 zx_iob_region_info_t 區域說明元素。

struct zx_iob_region_info_t {
  zx_iob_region_t region;
  zx_koid_t koid;
};

• 「region」是區域說明，含有可能更換的存取位元。
• koid 是基礎記憶體物件的 Kid。

系統會替換存取修飾符位元，讓 Ep0 存取位元會反映 對進行查詢和 Ep1 位元的存取表示 讓另一個端點能夠決定 而且不用知道建立時的 Ep0 和 Ep1 控制代碼為何。

主題 ZX_INFO_PROCESS_VMOS

為了與現有的記憶體歸因機制保持不變，記憶體物件 如同本主題的一般 VMO，我們會照常計算支援的 IOB 區域，包括 觸及率和對應之間可連性。

如果是私人區域類型，備用記憶體物件會獲派不同的 KOID 並根據預設使用所屬 IOB 的名稱。多產科 可覆寫或修改私人區域的預設名稱。

透過中介服務存取

IOB 支援可設定核心中介存取權，以便存取記憶體區域。採用中介服務 存取功能可提供較嚴格的資料完整性和其他不變性資料 透過核心做為信任的中介平台，提供直接存取的資訊。核心 保證遵守記憶體區域的指定存取規則 存取紀律

透過中介服務讀取、寫入和均等...

中介服務作業會由 IOB 讀取、寫入和輔助系統呼叫執行， 。存取領域可能會定義新的 IOB 系統呼叫或超載，前提是要使用 語意一致性我們通常的目標是定義幾個可重複使用的系統呼叫 適合各種用途

權限

根據預設，IOB 具備下列權限：

• ZX_RIGHTS_BASIC = (ZX_RIGHT_TRANSFER | ZX_RIGHT_DUPLICATE | ZX_RIGHT_WAIT |ZX_RIGHT_INSPECT)
• ZX_RIGHTS_IO = (ZX_RIGHT_READ | ZX_RIGHT_WRITE)
• ZX_RIGHTS_PROPERTY
• ZX_RIGHTS_MAP
• ZX_RIGHTS_SIGNAL
• ZX_RIGHTS_SIGNAL_PEER

屬性

IOB 支援 ZX_PROP_NAME 提供診斷和歸因資訊。

IOB 可能支援區域存取類別定義的額外屬性。

訊號

IOB 支援對等點和使用者信號，提醒使用者註意顯著狀況。未來 擴充功能可能會定義可設定的信號。

ZX_IOB_PEER_CLOSED

ZX_IOB_PEER_CLOSED在最後一個參照 Google 會再發布其他端點對從 端點仍會計為此目的參照

ZX_USER_SIGNAL_*

使用者可能會提高 ZX_USER_SIGNAL_* 來表示顯著條件。

核心中介存取主題

為方便進行中介作業，核心必須瞭解如何正確存取 記憶體區域區域的記憶體存取規則和設定 稱為存取規範，其中可能包括：

• 簿記的位置和格式。
• 覆寫/失敗政策。
• 浮水印和逾時設定。
• 記憶體順序和圍欄需求。

學科說明

您必須使用可延伸說明結構， 32 位元標題，用於指定說明的類型和格式。

#define ZX_IOB_DISCIPLINE_TYPE_NONE (0)

struct zx_iob_discipline_t {
  uint32_t type;
  union {
    uint8_t max_extension[4 * 15];
  };
};

未來 RFC 中可能會定義的紀律，包括：

• 生產者 / 消費性圓環緩衝區
• ID / Blob 地圖
• 鍵 / 值存放區
• 散佈圖 / 收集記憶體複製
• 目錄項目快取

實作

初始實作是支援追蹤和記錄的基礎步驟 以更全面、準確的方式回答顧客問題 並與顧客自然流暢地對話以下章節提供個案研究，說明 提供已定義的 IOB 功能和可能解決的擴充功能 用途需求

系統事件追蹤

IOB 旨在提供基礎架構，以打造更安全、更有效率的系統 支援下列項目追蹤事件：

• 移動工作階段協調、中繼資料和事件，降低執行階段負擔 只收集到 IOB 區域，不必調度 和管道處理序間通訊 (IPC)
• 透過以下方式，啟用 FDIO 和 FIDL 等低階設施的檢測作業： 消除 IOB 核心 API 以外的依附元件。
• 允許核心安全地收回追蹤事件，藉此提升穩定性 緩衝區，以避免嚴重的 OOM 條件與 RFC 0181：無鎖定的可捨棄 VMO。

系統追蹤 IOB 可使用的設定如下：

• 角色：
  • Ep0：Trace Manager
  • 第 1 集：追蹤服務供應商
• 區域 0：追蹤類別 Bit Vector
  • 類型：私人
  • 存取：
  • Ep0：uR0、uW0 (R/W)
  • 第 1 集：uR1 (RO)
  • 學科：無
  • 用途：uint64_t 位元向量陣列，代表啟用的追蹤功能 類別
• 地區 1：追蹤記錄類別
  • 類型：私人
  • 存取：
  • Ep0：uR0、uW0 (R/W)
  • Ep1：kW1 (透過中介功能新增項目)
  • 學問：Future id/blob 配置器紀元。
  • 用途：依序顯示 ID/字串對應，代表每個各類別位元的數量 追蹤服務供應商使用的追蹤類別
• 區域 2：內部化字串
  • 類型：私人
  • 存取：
  • Ep0：uR0、uW0 (R/W)
  • Ep1：kW1 (透過中介功能新增項目)
  • 學問：Future id/blob 配置器紀元。
  • 用途：依序 ID/字串對應，代表內部化字串 追蹤事件名稱以及其他經常參照的名稱。
• 區域 3：低費率 / 靜態中繼資料
  • 類型：私人
  • 存取：
  • Ep0：uR0、uW0 (R/W)
  • 第 1 集：uR1、uW1 (R/W)
  • 學問：未來多重生產者/單一消費者環形緩衝區紀元。
  • 用途：針對低速率 / 靜態追蹤事件 (例如： 執行緒名稱。這些事件通常需要正確解讀 其他追蹤記錄事件。
• 區域 4：高頻率追蹤記錄事件
  • 類型：私人
  • 存取：
  • Ep0：uR0、uW0 (R/W)
  • 第 1 集：uR1、uW1 (R/W)
  • 學問：未來多重生產者/單一消費者環形緩衝區紀元。
  • 用途：適用於高速率追蹤記錄事件的無鎖定環形緩衝區。能容忍資料 循環緩衝區模式下的損失

記錄系統

IOB 旨在提供基礎架構，以打造更安全、更有效率的系統 方法如下：

• 區隔不同元件和/或嚴重性等級的記錄，防止 跨元件和跨嚴重性記錄滾動週期
• 避免處理未主動觀察到的記錄。
• 避免使用調度執行緒來處理嚴重性變更。
• 個別元件 (記憶體) 資源管理與可靠度。

涉及以下演員：

1. 記錄生產者：輸出記錄的元件。
2. Log Manager (Archivist)：將所有生產端的記錄轉送至所有取用端。
3. 記錄用戶：連線至記錄管理員，並讀取合併的記錄串流。

系統記錄 IOB 可使用的設定如下：

• 角色：
  • Ep0：Log Manager (Archivist)
  • Ep1：記錄產生者 (部分元件)
• 區域 0：控制
  • 類型：私人
  • 存取：
  • Ep0：uR0、uW0 (R/W)
  • 第 1 集：uR1 (RO)
  • 學科：無
  • 用量：儲存執行階段設定，例如最低嚴重性。可能也 儲存記錄環形緩衝區大小上限的資訊， 會視記憶體管理需求而定
• 區域 1：字串資料表
  • 類型：私人
  • 存取：
  • 劇集：uR0 (RO)
  • 第 1 集：kW1 (WO)
  • 學問：Future id/blob 配置器紀元。
  • 用途：依序 ID/字串對應，代表內部化字串 經常參照的記錄檔字串、標記、索引鍵、中繼資料
• 區域 2：記錄環形緩衝區
  • 類型：私人
  • 存取：
  • Ep0：uR0、uW0 (R/W) (寫入 R/W/C 指標，傳輸時寫入) 計數器)
  • 第 1 集：kW1 (WO)
  • 學問：未來多重生產者/單一消費者環形緩衝區紀元。
  • 用法：用於記錄記錄的無鎖定環形緩衝區。可以容忍 環狀緩衝區模式我們預計從 以便讓生產端和直接從管理員讀取可能會在 前移至直接存取 則為生產端。

導入步驟

實作程序必須完成一系列開發步驟：

1. 在 @next 屬性下方加入 IOB 介面：
   • 實作基本 IOB 調度工具。
   • 實作系統呼叫和常見的驗證。
2. 設計以 IOB 為基礎的追蹤和記錄原型，以及必要的 IOB 擴充功能 在分支版本中
3. 為必要的擴充功能編寫及評估 RFC。
4. 請導入擴充功能並移除 @next 屬性。
5. 重新在 IOB 上追蹤和記錄，並將現有用戶端軟傳輸到 存取全新介面

成效

要確認效能改善程度，您可以比較端對端延遲時間並 取代及移除目前的 追蹤/記錄實作。持續性的基準測試可能包含緩衝區記憶體 來源 (VM 負擔)、主要作業的延遲/並行測試，以及 配置測試，驗證穩定狀態的記憶體消耗屬性。

人體工學

IOB 在設計上比 VMO、活動 和處理類似功能所需的處理序間通訊 (IPC) 物件生命週期 IOB 端點的一致性也比 因此比起檔案 與 VMO 互動

回溯相容性

IOB 只會影響 FIDL 檔案來源相容性和 ABI 線格式 為語言導入新的處理常式類型，以提升相容性，但 會影響回溯相容性

安全性考量

共用記憶體的用途始終具備安全性的可能性 安全漏洞大多數 IOB 用途不會帶來共用 VMO 帶來的新危害 也不會有衝突。然而，IOB 確實降低了某些錯誤的風險，因為 制定更完善的權限和記憶體存取生命週期規則

將 Elision 和檢查時間複製到使用障礙

共用記憶體使用案例中，有個重要的軟體錯誤類別 也就是檢查時間造成的危害 (TOCTOU)。缺點是 競爭狀況是因「檢查某狀態」與「使用 這樣狀態可能會在檢查和使用之間失效 結果。

如要避免開放式共用記憶體用途中的 TOCTOU 危害 而且經常需要將資料從共用記憶體區域 避免在驗證期間或驗證完成後修改即使在 時，請務必小心謹慎，以免違反複製規定，因為編譯器可能會 除非將副本最佳化，並直接在共用記憶體區域中運作 採用特定介入措施

核心中介作業可以藉由 保證核心遵循中繼資料更新和酬載的規則 傳輸及記憶體順序舉例來說，使用環形緩衝區時 這個原則保證核心不會覆寫記錄內容 直到取用端確認環狀緩衝區表示安全無虞 簿記，避免在驗證前複製有效負載。

儘管如此，使用者仍須確保 防止記憶體順序與原子 (或語言特定的對等項目) 最佳化所造成的正確風險為減輕使用者的負擔 Fuchsia SDK 包含支援語言的程式庫， 為每個已定義的領域建立正確的存取常式學科規格 也會包含足夠的詳細資料，以安全正確地應用 存取規則

隱私權注意事項

除了既有的隱私權考量，IOB 並未導入新的隱私權注意事項 IPC 和共用記憶體使用案例則適用。系統的初始用途 事件追蹤和記錄將繼續履行相同的隱私權義務。

測試

測試項目包括：

• IOB 核心測試。
• 用於驗證新型別處理類型驗證的 FIDL 一致性測試。
• 擴大 Fuchsia 追蹤系統測試以納入 IOB 專屬 功能。
• 擴大系統記錄測試以包含 IOB 專屬功能。

現有的追蹤和記錄測試並非依賴基礎模型 實作詳細資料仍可繼續運作並傳遞。

說明文件

說明文件更新內容包括：

• Syscall 參考資料。
• 核心概念。
• FIDL 處理常式類型。

缺點、替代方案和未知

本提案的成本相對較低，因為 建構於現有的虛擬記憶體和對等互連調度工具。 以非對稱式存取權為核心，且核心區域則有獨特功能 存取和取消地圖關閉功能

既有藝術品和參考資料

• Fuchsia 追蹤系統
• Fuchsia 追蹤格式
• RFC 0181：無鎖定的可捨棄 VMO
• 實作無鎖定的 R/W 環形緩衝區