RFC-0184：系統 Netstack 的 POSIX 相容性

RFC-0184：系統網路堆疊的 POSIX 相容性
狀態已接受
領域
  • 外幣 ABI 相容性
  • 網路堆疊
說明

說明在 Fuchsia 上支援 POSIX 類網路 API 的政策。
問題
更小鳥
作者
審查人員
提交日期 (年月分)2022-07-15
審查日期 (年-月-日)2022-08-17

編輯這個 RFC

編輯 RFC 中繼資料

摘要

Fuchsia 的目標是透過 fdio 和系統網路堆疊，向元件公開與 POSIX 相容的網路 API。同時也支援其他 POSIX 導向作業系統常見的非 POSIX 功能。

提振精神

Fuchsia 現有的系統網路堆疊是以針對 Linux 相容性為目標的核心建構而成。由於預計在實際執行時替換這個網路堆疊，因此相容性問題不斷發生。本提案會要求任何系統網路堆疊指定類似 POSIX 的 API，讓這些工作休息片刻。

POSIX 網路介面說明元件存取網路資源的標準方式。支援 Fuchsia 元件的 POSIX 網路子集，可讓您輕鬆 1) 在 Fuchsia 上重複使用現有程式碼，以及 2) 使用熟悉的 API，為 Fuchsia 編寫新的程式碼。

相關人員

誰有權規範這份 RFC？(本節為選用，但建議提供)。

講師：

hjfreyer@google.com

審查者：

  • abarth@google.com (RFC-0082 作者)
  • brunodalbo@google.com (網路堆疊)
  • dhobsd@google.com (網路政策)

諮詢時間：

brunodalbo@google.com, hanjh@google.com, hjfreyer@google.com, martinjeffrey@google.com, nickbrow@google.com, tamird@google.com, wildenhain@google.com

社會化：

這個 RFC 已通過網路堆疊團隊的設計審查，

設計

本文件中的關鍵字「必須」、「不得」、「必要」、「應」、「不應」、「應該」、「不應該」、「建議」、「可能」和「選用」等關鍵字均以 IETF RFC 2119 中所述的方式解釋。

在 Fuchsia 裝置上，系統網路堆疊會公開多項 fuchsia.posix.socket FIDL 服務來為元件提供網路功能。雖然 FIDL 感知元件可以指定這些元件，但我們不建議使用這種直接使用。相反地，專為 POSIX 系統編寫的元件呼叫 fdio 相容性程式庫中的 API 應該連結，以便將 libc 系統呼叫轉譯為 FIDL 服務呼叫。

Fuchsia 的 fdio 程式庫可做為 POSIX 有限子集的轉譯層，提供給適當的 FIDL 服務。針對網路功能，fdio 提供多項 POSIX 呼叫的實作方式，包括 socket、setsockopt 和 getsockopt、read、write、send、recv 等。總體上，如果實作附有 fdio 的 FIDL 服務，就能提供這些和其他呼叫的完整實作。

本文的目標是定義決定 POSIX 或對等互連系統定義網路功能的時機，而非提供完整的系統呼叫清單。預期 fdio 和網路堆疊會視需要實作系統呼叫和選項，主要用於第一方 Fuchsia 程式碼，之後其他應用程式有此需求。使用 fdio 提供的系統呼叫即可實作的 POSIX 函式不屬於本文件的討論範圍。

請注意，雖然本提案要求 Fuchsia 提供與 POSIX 相容的網路介面，但並不需要使用介面。特別是，未來規範或開發要與 POSIX 一起實作的 Fuchsia-first API 之後，沒有任何其他項目遭到排除。

實作

現有的 fdio 程式庫和系統網路堆疊已提供與 POSIX 相容的介面。本提案旨在編纂這項非正式決策，以與類似 POSIX 的作業系統保持一致，並引導未來在網路堆疊和 fdio 程式庫中進行開發作業。變更系統網路堆疊和 fdio 時，應考量以下三項原則：

POSIX 法規遵循

Fuchsia 的系統網路堆疊和 fdio 程式庫旨在為 POSIX 指定的網路 API 提供相容性。以 POSIX 網路 API 為目標的元件在與 fdio 連結時，應可正常運作，並轉送適當的通訊端建立功能。

與同業系統的相容性

POSIX 規格會導致某些互動的行為未定義，因此以 POSIX 介面編寫的元件通常預期這些互動，並將特定作業系統或作業系統系列的行為納入考量。當這個行為在多個類似 POSIX 的作業系統中定義明確且一致的時，Fukusia 的網路子系統「應該」符合該行為 (但在少數情況下，除非以下所述)。當對等系統的行為不一致時，Fchsia 不保證會比對任何特定對等系統的行為。

助長分歧行為

Fuchsia 網路子系統可能需要實作與對等系統不同的行為。出現這類分歧時

  • 同業系統的行為不一致
  • 如果實作與對等互連系統一致的行為，可能會導致安全性風險
  • 由於 Fauchsia 的架構限制，難以實作一致的行為。

在這種情況下，散播的動機一定要有良好動機、記錄良好且經過充分測試。此外，元件必須能夠輕易觀察行為差異 (例如傳回錯誤的 POSIX 系統呼叫)。

已知限制

POSIX 會利用數個全域 ID 空間，包括 UID、GID、PID 和檔案路徑。其中許多 ID 會與內建支援一起用於限制 POSIX 類系統上網路作業的存取。這些因素包括但不限於：

  • 在同一個位址上有 SO_REUSEPORT 和 SO_REUSEADDR 的繫結通訊端，只限於以相同 UID 執行的元件繫結。
  • 在 Linux 上，只有使用 CAP_NET_RAW 執行的應用程式才能清除 SO_BINDTODEVICE 通訊端選項。
  • 在 Linux 上，建立原始 IP 通訊端的功能僅限於使用 CAP_NET_RAW 執行的應用程式。
  • 在 Linux 上，將通訊端繫結至低編號通訊埠時，應用程式必須具備 CAP_NET_BIND_SERVICE (但在近期的 macOS 版本中屬於非必要的作業)。

盡可能在 Fuchsia 上支援這些行為，但前提是要能將其功能對應至 Fuchsia 概念，且可能需要許可，以滿足 Fuchsia 的架構限制。舉例來說，類似 POSIX 的系統會使用程序的 UID 來限定通訊埠共用權限。Fuchsia 沒有 UID，因此元件需要明確採取動作來啟用通訊埠共用功能，這可能是透過 fdio 的額外呼叫。

效能

在正式支援 POSIX 網路介面的過程中，Fuchsia 的網路子系統將提供 API 的高效能實作。Fuchsia 網路堆疊和 fdio 已有可以執行 POSIX 介面的重要基準化工具。這項功能會用於評估效能改善情形及偵測迴歸問題。

人體工學

Fuchsia 以 POSIX 為指定目標，這是應用程式廣為人知且常見的介面，可讓開發人員輕鬆移植現有的程式碼，並提供熟悉的介面來編寫新程式碼。雖然部分 POSIX 概念無法直接對應至 Fuchsia (例如 UID)，但絕大多數的網路概念都是如此。將熟悉的網路介面設為目標，將大幅改善開發程式碼並移植至 Fuchsia 的體驗。

回溯相容性

本提案並非反映準則的變更，只是將面面俱到的編製。由於並未導入任何變更，因此對回溯相容性的考量降到最低。

安全性考量

這個 RFC 結合了現有的非正式原則，因此沒有任何新的安全考量。此外，針對提供 POSIX 相容 API 的承諾，並未預先拋棄未來各元件的隔離或網路堆疊分割以解決安全性問題。

隱私權注意事項

本提案僅構成對已使用的 POSIX API 的支援，因此並未導入新的隱私權考量。

測試

Fuchsia 系統網路堆疊測試使用現有的相容性套件進行測試，該套件會檢查 POSIX 和 Linux 是否一致 (不過後者為便利性，不暗示 Linux 行為的隱含保證)。這個測試套件會對系統的預期行為編碼，以回應 POSIX 呼叫，有助於避免迴歸和未來的功能開發。Fuchsia 的網路子系統與 POSIX 或類似 POSIX 系統之間的意圖行為差異，會在測試套件中編碼並記錄。已知的非預期差異也會經過編碼及記錄，並標記在 Fuchsia 的錯誤追蹤系統中。這項整合等級測試加上系統網路堆疊內部的現有單元測試，可為 POSIX 相容性提供足夠的涵蓋範圍。

說明文件

這個提案需要另外兩個文件元素：

  1. 瞭解如何使用 fdio API 與系統網路堆疊通訊
  2. 列出 Fuchsia netstack/fdio 與類似 POSIX/POSIX 的系統行為之間的差異。

缺點、替代項目和未知

本提案必須承諾在 Fuchsia 系統網路堆疊和 fdio 程式庫中，實作大量的 POSIX 和對等行為。由於本提案將現有方案正式化，因此許多功能已經存在。本提案承諾讓 Fuchsia 擴充現有 API 介面，並長期支援該介面。

雖然 POSIX 是眾所周知的標準，但在設計上不支援 Fuchsia 的功能或豐富的 IPC 規格機制，如要支援與 POSIX 型系統的相容性，就必須為元件提供有限的介面 (同步系統呼叫、不類型的檔案描述元)，並將這些概念編入 Fuchsia 原始版本。此外，如果對 Fuchsia 元件採用類似 POSIX 的介面，可能也會阻礙開發實用的 Fuchsia 優先網路 API。

而 Fuchsia 進一步推動了 POSIX 相容性，突顯的是 Fuchsia 優先的 API。由於已編寫大量的 Fuchsia 系統服務程式碼，用於針對類似 POSIX 的 API，因此似乎合乎常規且短視。

就未知情況而言，主要預期類別是 POSIX 支援不夠完整的實作領域，以及 Fuchsia 相較於同類作業系統造成的行為不相容。需要處理這些問題，並記錄為執行個體發生或發現的情況。

優先藝術與參考資料

  • POSIX 2017 規格列出了與 POSIX 相容系統的需求。
  • RFC-0082 說明 Fuchsia 在 Fuchsia 上執行未經修改的 Linux 程式的目標。
  • gVisor 專案的網路程式碼是現有 Fuuchsia 系統網路堆疊的核心。

附錄：導入決策個案研究

POSIX 的 setsockopt 函式提供一個方法，可讓程式碼在通訊端上設定會影響其行為的選項。POSIX 定義了數個選項旗標，但符合規定的系統可以新增自己的自訂標記。SO_REUSEPORT 選項是相當常用的選項，設定後會允許在相同位址與通訊埠上使用 bind 通訊端。由於其語意在多個系統 (包括 FreeBSD、macOS 和其他 BSD 衍生程式) 中定義明確且一致的語意，因此 Fuchsia 的網路堆疊可讓元件在 UDP 通訊端上設定 SO_REUSEPORT 選項。

Linux 和 BSD 衍生出的 SO_REUSEPORT 實作的其中一個差異，在於 Linux 規定通訊端與相同位址的繫結，屬於具有相同使用者 ID 的處理程序。由於 Fuchsia 的架構會排除類似的使用者 ID 概念，因此這項限制不會在 Fuchsia 中實作。

此外，在 Linux 實作 SO_REUSEPORT 時，行為可能會不一致，實際情況取決於是否在通訊端上設定選項，然後在呼叫 bind 後清除，或完全不在通訊端上設定。依賴隱藏的系統狀態和定義不當的行為，據此做出決定不要模擬 Linux 的行為。

詳情請參閱 https://fxbug.dev/42051599。