本頁面由 Cloud Translation API 翻譯而成。

RFC-0117 - 元件模糊架構

RFC-0117：元件模糊化架構
狀態	已接受
領域	測試
說明	Fuchsia 原生的跨程序模糊化架構。
問題	24740 年
毛皮變化	529348
作者	aarongreen@google.com
審查人員	abarth@google.com anmittal@google.com crjohns@google.com jsankey@google.com jeremymanson@google.com mvanotti@google.com satsukiu@google.com shayba@google.com shrike@google.com
提交日期 (年-月-日)	2021-05-24
審查日期 (年-月-日)	2021-07-28

編輯此 RFC

編輯 RFC 中繼資料

摘要

引導式模糊測試能有效減少錯誤及增加錯誤使用者對平台的信心，但目前沒有可用的模糊架構這項作業可以在 Fuchsia 定義的多種程序邊界內進行模糊化元件拓撲。本文件針對這類能在不同程序之間共用涵蓋率及測試輸入內容的架構並在測試領域中，讓元件更容易進行模糊化處理一般設定

提振精神

計畫測試可用來呈現錯誤是否存在，但絕不會顯示缺一不可！

--Edsger W.Dijkstra

引導式漏洞檢查是利用產生的資料：

模糊測試會產生一些測試輸入資料，並用來測試目標軟體。
如果測試結果失敗，模糊器便會記錄輸入並結束。
目標軟體會產生經過模糊處理工具收集的意見回饋。
模糊工具會使用回應產生其他測試輸入內容，並重複執行。

引導式模糊處理功能非常適合用來找出與專案需求無關 (因此通常是未測試)。透過自動執行也能提升開發人員的這些部分的信任度系統中的安全性、正確性和/或穩定性 考量重點

引導式漏洞檢查架構可用以下分類說明：
模糊分類

引擎：指定目標通用意見回饋循環。
- 語料庫管理：維護一組模糊輸入內容 (例如 corpus)。記錄新的輸入內容並修改現有輸入內容 (例如合併)。
  - 種子語料庫是一組手工初始輸入內容。
  - 「即時語料庫」是一組持續更新的產生的輸入內容。
- Mutators：一組異動策略和確定性來源虛擬隨機性，用於從語料庫建立新輸入。
- 回饋分析：根據意見回饋處理輸入內容。
- 管理介面：與使用者互動，以協調工作流程：
  - 透過特定輸入內容執行目標，例如執行單一 模糊測試。
  - 模糊目標，也就是執行模糊跑步訓練
  - 分析或處理指定語料庫。
  - 回應偵測到的錯誤和/或處理。
目標：要模糊的特定目標領域。
- 輸入處理：將單次執行作業的模糊輸入內容對應至程式碼處於測試狀態 (例如透過特定函式、I/O 管道等等
- 收集意見回饋：觀察輸入內容帶來的行為。5 月收集硬體或軟體追蹤、程式碼涵蓋率資料、時間等
- 錯誤偵測：判斷輸入內容何時導致錯誤。收集並記錄測試成果，例如：輸入內容、記錄檔、回溯追蹤記錄等

有些面向可能需要 OS 和/或 OS 的特定支援例如收集意見回饋和偵測錯誤目前開啟 Fuchsia 是唯一支援最全面的模糊化架構 libFuzzer，是透過預先建構的 clang 工具鍊提供編譯器執行階段。無論您是在 sanitizer_common 執行階段用於收集程式碼涵蓋率意見回饋，以及 libFuzzer 本身以偵測例外狀況。還有一組 GN 範本和主機工具，可讓開發人員快速為 Fuchsia 的圖書館開發模糊工具。

但與 Linux 不同， Fuchsia 中最基本的可執行單位而非程式庫使用現有的引導式漏洞檢查架構進行模糊測試反而造成困擾範圍較廣 (例如單一程序中的 libFuzzer)，或過於廣泛 (例如 TriforceAFL)。

一個適用於 Fuchsia 中模糊元件的理想架構具備以下功能：

整合現有的持續模糊化基礎架構，例如 ClusterFuzz。
這種模組化做法能利用各平台通用的其餘部分模糊架構，例如變化策略
高效能的跨程序程式碼涵蓋率機制。
與現有的 Fuchsia 工作流程整合，例如 ffx。
能隔離測試中元件和/或提供模擬元件
未修改的目標元件來源。
穩健且靈活的方法，可分析執行及偵測錯誤。
開發人員案例，類似 Fuchsia 的其他測試方式。

設計

這項設計會嘗試：

用慣用的語氣。
重複使用現有的導入方式。

整體而言，這項設計會運用測試執行元件架構，並新增：

用於驅動漏洞的 fuzzer_engine。
這個 ffx 外掛程式和模糊管理工具，可用於與及管理模糊化器互動。
將 fuzzer_engine 連結至模糊管理工具的 fuzz_test_runner。

元件模糊化架構設計

本文件中的本節內容大致依照控制流程分門別類。即開頭是人類或機器人，想執行模糊的任務或工作可能難以辨識讀者應該知道這一節會說明各項概念。

「`ffx fuzz`」主機工具

使用者 (包括真人和機器人) 透過 ffx 外掛程式。這個外掛程式將能與透過以下方式使用 fuzz_manager 服務：

fuchsia.fuzzer.Manager 通訊協定。
資料移轉通訊協定。

ffx fuzz 的子指令會鏡射 fx fuzz 的項目，例如：

analyze：回報指定語料庫和/或字典的涵蓋範圍資訊。
check：查看一或多個模糊測試器的狀態。
coverage：產生測試的涵蓋範圍報表。
list：列出目前版本中的可用模糊測試器。
repro：重播測試單元，重現模糊結果。
start：啟動特定的模糊測試器。
stop：停止特定模糊測試器。
update：更新模糊語料庫的 BUILD.gn 檔案。

模糊管理程式

執行元件提供兩項重要功能：

這項產品可讓您輕鬆建立複雜但密封的測試領域，並推動測試和可自訂的測試執行器整合。
可收集重要診斷資料，例如記錄檔和反向追蹤。

此外，執行一次模糊測試時，可自然地使用元件測試架構：程式碼會使用指定的測試輸入內容可視為已通過或失敗，具體取決於發生。

不過，模糊測試與其他形式的測試不同，與持續模糊與連續測試：

測試輸入並非已知優先順序。
- 測試輸入的結果是由模糊的結果產生。
- ClusterFuzz 等持續模糊化基礎架構會使模糊語句的許多片段的測試輸入內容就進行模糊處理。
模糊測試執行是開放式程序。模糊測試永遠不會「通過」，它們只會「通過」呼叫失敗或提早停止
- 這也就是必須提供包含詳細資料的隨選狀態通常並非由其他測試提供，例如執行速度、總和收集的意見回饋、記憶體用量等
- 這個狀態必須持續提供給人類或模糊不清監控模糊測試執行作業的基礎架構機器人
模糊測試結果比通過/失敗更豐富。
- 失敗時，輸出內容必須包括觸發的輸入內容和任何相關的記錄檔和回溯追蹤記錄
- 提前終止服務時，輸出內容可能包含累積的意見回饋，建議參數 (例如字典)。
模糊領域可用於多種不同的工作流程， 基礎架構選擇連續執行，例如「聽了一陣子，如果找到錯誤後，將其清除、合併及壓縮語料庫。」以測試套件呈現每個步驟會導致大量工作擷取作業只用來在下個步驟還原狀態

擴充測試執行元件架構即可解決其中部分問題，例如：該資料來源就能提供結構化輸出內容不過，對所有模糊需求也會為其他不需要的測試新增重要功能具體做法是指示 Kubernetes 建立並維護一或多個代表這些 Pod 的物件因此，設計會新增一個 fuzz_manager，符合下列條件：

透過 ffx 為使用者提供管理介面。
與 test_manager 互動，以便在模糊領域內啟動模糊測試器執行元件架構。
為模糊工具提供 fuchsia.fuzzer.manager.Harness 反向連線和服務使用者要求
提供資料移轉通訊協定，以便將資料插入或插入從模糊測試中擷取資料

接著，測試執行元件架構的修改如下：

已新增 fuzz_test_runner。這個執行元件是以 elf_test_runner，用於啟動 fuzzer_engine，並將模糊網址傳遞給這個函式。
已修改 test_manager，以便轉送 fuchsia.fuzzer.manager.Harness 能力對 fuzz_test_runner 的要求這項能力「不會」轉送至測試，也「不會」則不受影響
fuzz_test_runner 會為 fuchsia.fuzzer.Controller 通訊協定。這會以啟動程序安裝一端處理 fuzzer_engine，並使用 fuchsia.fuzzer.manager.Harness 將另一個函式傳遞到 fuzz_manager。

模糊引擎

fuzzer_engine 是模糊領域的元件。在模糊分類，就會：

實作 fuchsia.fuzzer.Controller 通訊協定，以提供 管理介面。
建立並使用儲存空間能力來管理每個語料庫。
從語料庫「替換」輸入內容，建立新的測試輸入內容。(例如連結針對 libMutagen)。
Uses 是 Adapter 能力，可傳送要處理的新輸入內容。
Exposes 用於檢測遠端的 fuchsia.fuzzer.ProcessProxy 能力如要提供收集的意見回饋 回報錯誤。
分析意見回饋。

如果系統將模糊作業視為一系列不同輸入內容的測試，則在於讓模糊引擎為每個模型例項化全新的測試領域例如讓測試「執行器」連續執行每項模糊測試 run。這種方法的主要問題在於「意見回饋分析」功能的效能和異動迴圈模糊品質與處理量有直接關係迴圈的速度必須非常快：提供意見回饋及分析意見回饋」應該按照微秒的順序。

因此，模糊引擎就包含在測試領域中類似用於測試複雜拓撲的測試驅動程式庫程式。由事件配對共同管理的共用 VMO 會用於轉移測試模糊目標配接器的輸入內容檢測遠端程序，盡可能縮短延遲時間。

模糊引擎是由 fuzz_test_runner 啟動。跑酷遊戲非常快與現有 elf_test_runner 類似，但新增了一個重要步驟：這會建立 fuchsia.fuzzer.Controller 通訊協定的管道組合。這項服務在 fuzzer_engine 中安裝此組合的其中一端，做為啟動控制代碼。這項服務使用 fuchsia.fuzz.manager.Harness 將另一個資料傳遞至 fuzz_manager 能力是由 test_manager 轉送這麼做可讓「test_manager」：僅為 fuzz_test_runner 和模糊工具提供 Harness 能力而不是所有測試啟動

目標轉接器

模糊目標轉接程式會執行輸入處理角色模糊分類。透過上述的共用 VMO 和事件配對，會採用模糊引擎產生的測試輸入內容與目標領域檢測遠端處理程序的互動例如模糊不清

這些互動是由模糊內容的作者提供，一般來說，這句話通常是「寫作模糊器」。

模糊作者可以提供自訂的模糊目標實作方式或是使用我們提供的 Scaffold

可能的變壓器 Scaffold 範例包括：

llvm_fuzzer_adapter：預期作者能實作 LLVM 的模糊目標函式。
- 針對 C/C++，作者會實作：
```
extern "C" int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size);
```
- 針對 Rust，作者會使用 #[fuzz] proc_macro 屬性實作方法。
- 以 Go 來說，作者實作：
```
func Fuzz(s []byte);
```
realm_builder_adapter：除了 LLVM 模糊目標函式外，作者實作的方法可以修改提供的 RealmBuilder。轉接器會為這個函式提供預設建構工具，並將結果用於建構要模糊的元件領域作者只要新增其他路徑、功能、模擬等：
```
pub trait FuzzedRealmBuilder {
  fn extend(builder : &mut RealmBuilder);
}
```
libfuzzer_adapter：和 llvm_fuzzer_adapter 的預期類似，但是元件資訊清單省略模糊引擎，公開 Controller 能力本身，以及直接連結至 libFuzzer。這個有顯著不同的元件拓撲搭配 libFuzzer 這個架構中的 libFuzzer
honggfuzz-persistent-adapter：讓模糊作者能夠執行：
```
extern HF_ITER(uint8_t** buf, size_t* len);
```
目前不支援 honggfuzz 本身，但模糊目標因此都能與這個架構整合

請注意，目標轉接器可以，而且也應該連結至遠端程式庫還能與工具中的遠端程序搭配使用目標。

檢測遠端處理程序

為了收集意見回饋並偵測錯誤，目標內的所有程序需要添加額外儀表板 (例如 SanitizerCoverage)。若是在樹狀結構內建構的模糊化器，可透過工具鍊變化版本，可將 flags 和 deps 套用到 GN 目標的依附元件必要標記，例如-fsanitize-coverage=inline-8bit-counters, 接受樹狀結構外編譯。

此外，這些程序也需要 fuchsia.fuzzer.ProcessProxy 用戶端。上述相同的工具鍊變化版本可能會自動新增依附元件連結，可連結樹狀結構內模糊工具和遠端程式庫的程序。

遠端程式庫針對模糊分類提供以下功能：

透過回呼收集意見回饋，例如 __sanitizer_cov_inline_8bit_counters_init。
與 fuzzer_engine 的 ProcessProxy 的早期啟動連線。
可偵測錯誤的背景執行緒，例如來監控例外狀況記憶體用量等

樹狀結構外模糊做法則可提供自己的用戶端導入項目。新增 fuchsia.fuzzer.ProcessProxy FIDL 介面和遠端程式庫實作為 SDK 提供方便的樹狀結構外模糊字詞撰寫功能。

最後，必要的編譯時間修改僅適用於 LLVM 轉換 IR。所有其他修改作業只需要連結時間。這麼做可讓服務供應商提供「模糊化即服務」功能願意為其提供元件的 LLVM 位元碼，無須取得原始碼。

元件拓撲

我們將以上所有內容整合在一起，模糊元件拓撲包括：

core：系統根元件。
fuzz_manager：在根領域和主機工具之間的橋接。
test_manager：與執行元件架構相同。
target_fuzzer：模糊的領域進入點。
fuzzer_engine：無目標的模糊化驅動程式庫。
target_adapter：含有使用者輸入內容的目標特定元件來處理程式碼
instrumented_target：元件模糊不清。

adapter 和 target 元件可能有額外的子項，例如模擬和目標領域均模糊不清

上述各部分的互動可以如下圖所示：
模糊架構拓撲

FIDL 介面

這個架構會新增兩個 FIDL 程式庫：一個用來與 fuzz_manager，另一個則用於與模糊工具本身互動。

`fuchsia.fuzzer.manager`

fuchsia.fuzzer.manager 定義的類型包括：

LaunchError：可延伸的 enum，列出與發現項目和發現項目相關的錯誤也就是啟動漏洞

fuchsia.fuzzer.manager 定義的通訊協定包括：

fuchsia.fuzzer.manager.Coordinator：fuzz_manager 透過以下方式向使用者放送： ffx。包括啟動模糊和 fuchsia.fuzzer.Controller，以及停止模糊測試的方法。
fuchsia.fuzzer.manager.Harness：由 fuzz_manager 提供給 fuzz_test_runner (透過靜態路由到 core 和 test_manager)。執行元件會使用這個通訊協定將管道的其中一端傳送給管理員用於 fuchsia.fuzzer.Controller 通訊協定

`fuchsia.fuzzer`

fuchsia.fuzzer 定義的類型包括：

Options：具有設定執行作業的參數的可擴充 table，錯誤偵測系統等
Feedback：彈性的 union，代表目標意見回饋，例如代碼涵蓋率、追蹤記錄、時間等
Status：可擴充的 table，其中包含各種模糊指標，例如總數涵蓋範圍、速度等
FuzzerError：可延伸的 enum，列出錯誤類別，例如那些 ClusterFuzz 識別出。

fuchsia.fuzzer 定義的通訊協定包括：

fuchsia.fuzzer.Controller：由 fuzzer_engine 提供，並傳遞至透過 fuzz_test_runner 傳送 fuzz_manager。由 fuzz_manager 透過 Proxy 傳送以便傳達給使用者包含將輸入內容轉移至或構件的方法並執行模糊化的工作流程，例如輸入最小化、語料庫合併和正常模糊化
fuchsia.fuzzer.CorpusReader：透過「fuchsia.fuzzer.Controller」請款。用於從特定種子或即時語料庫取得輸入內容。
fuchsia.fuzzer.CorpusWriter：透過「fuchsia.fuzzer.Controller」請款。用於將輸入內容新增至特定種子或活體語料庫。
fuchsia.fuzzer.Adapter：由fuzzer_engine 開發人員提供的 target_adapter。包括註冊以便協調事件配對，以及用於傳送測試輸入內容的共用 VMO。
fuchsia.fuzzer.ProcessProxy：由各個 fuzzer_engine 提供模擬領域中的檢測過程。包含註冊負責協調事件配對，並註冊用於提供意見回饋的共用 VMO。

建構公用程式

這個架構為開發人員提供 fuchsia_fuzzer_package GN 範本。這麼做可讓他們：

自動加入 fuzzer_engine。
製作可由工具使用的中繼資料，例如種子的位置語料庫
使用非模糊工具鍊時，建構整合測試 (而非模糊測試) 按照「測試」一節的說明選取變化版本。
針對受測試的整合項目，重複使用建構規則測試。

這個架構也包含元件資訊清單資料分割，模糊內容需要的常見元素，例如fuzzer_engine 及其功能和 fuzz_test_runner 等。模糊工具的元件資訊清單包含：

預設的模糊資料分割。
目標配接器元件的網址。
遭到模糊化的元件資訊清單的網址。這通常應該是可透過相關整合測試重複使用

這些建構公用程式可協助您進行模糊開發提供類似整合測試開發體驗的經驗。比較：
測試及模糊開發程序

實作

實作計畫非常簡單：開發與單元測試個人進行一連串變更的類別，然後組合衍生測試衍生的整合測試「Testing」一節所述的 libFuzzer。

語言

fuzzer_engine 和 remote_library 是在 C++ 中實作，它們的慣用語言：

fuzzer_engine 和 remote_library 都必須與其他 C 整合 ABI，例如libMutagen、SanitizerCoverage 等
大多數的 remote_library 功能發生在「main之前和 exit之後」即建構及/或載入 LLVM 模組時，atexit 處理常式或在發生嚴重例外狀況時執行。因此，架構需要明確控制 ELF 執行檔的細微細節生命週期

其他部分，例如realm_builder_adapter 是以 Rust 編寫。

資料移轉通訊協定

在某些情況下，使用者需要能夠提供任意擷取的資料量，包括：

提供特定測試輸入內容，以便執行、清理或最小化。
將模糊語料庫與開發人員主機或多個資料庫中的語言同步 ClusterFuzz 執行個體。
擷取觸發錯誤的測試輸入內容。

為了將維護負擔降至最低，建議使用 overnet。然而，每次傳輸作業可能會超過 Zircon 管道的單一 FIDL 訊息。而是應使用 Controller 通訊協定包含多種方法，可提供 zx_socket 物件，模糊引擎會將資料串流至 VMO 和/或本機儲存的檔案。

資料以最少的通訊協定進行串流，以讀取或寫入具名序列位元組。通訊協定「不是」FIDL，因為傳送的資料可能會超過 FIDL 訊息的長度上限。即使已命名位元組序列在概念上相當於以下的 FIDL 結構：

struct NamedByteSequence {
  uint32 name_length;
  uint32 size;
  bytes:name_length name;
  bytes:size data;
};

堆疊展開

目前，libFuzzer 採用 LLVM 的解開器，並假設該程式是從在觸發信號的執行緒上執行的 POSIX 信號處理常式。適用對象 Fuchsia 需要用複雜的方法來處理包括修改當機的執行緒堆疊及插入返回追蹤保存組裝彈跳床以「復活」就會產生解開器中的執行緒。

如果 libFuzzer 沒有處理錯誤，則不需要採取以上步驟。處理各種類型的錯誤，何者最方便有效，例如：

例外狀況是由模糊引擎處理，且該引擎接收從自己的帳號代碼建立模糊測試執行元件的例外狀況管道進行測試工作。
逾時也是由模糊引擎管理。
Sanitizer 回呼和 OOM 是由遠端程式庫處理，並會通知你程式碼

成效

這項作業不會在生產系統上執行，因此不會影響任何運送代碼的效能。雖然包含模糊工具鍊變化版本對建立 Fuchsia 的成效有輕微影響架構就會重複使用現有的變化版本，且不會造成任何新的影響。

同樣地，在未檢測版本上透過模糊測試產生單元測試反映現行做法，因此不會產生。

對模糊結果而言，測量毛茸茸腦的重要指標品質是每單位時間的涵蓋率，只要評估其他指標：

在固定時間內，模糊測試工具的總涵蓋範圍。
在特定時間內執行的執行作業總數。

ClusterFuzz 會監控並發布每個漏洞的指標資訊主頁

人體工學

人體工學是這項設計的重要面向，其影響取決於也就是開發人員採用的 AI 技術

此架構會嘗試以幾種方式盡可能簡化模糊作業。這項服務可讓開發人員：

您可用熟悉且靈活的方式寫出模糊工具，詳情請參閱目標轉接器一節。
請使用現有的 GN 模糊範本系列設計模糊測試器。
透過熟悉的工作流程執行模糊測試程序。這是刻意使用 ffx fuzz 的情況 (與 fx fuzz 相似)。
取得可做為行動依據的結果。藉由整合 ClusterFuzz 錯誤回報會自動加上符號化的回溯追蹤記錄和重現指示。

回溯相容性

現有的 libFuzzer 模糊工具會實作 fuzz 目標函式。變更者：提供 libFuzzer 專用的 fuzz 目標配接器，而這些模糊工具就會即可在不修改原始碼的情況下，以這個架構運作。

安全性考量

這個架構不會用於運送產品設定。裝置內建的模糊設定中，裝置之間的通訊會使用 Kubernetes 提供的現有驗證和安全通訊功能 overnet和ffx。

模糊的輸出內容可能會有安全性考量，例如，測試輸入內容可運用的記憶體毀損問題這些疑慮「必須」由模糊工具處理操作人員 (人為或模糊基礎架構) 可運用的錯誤報告 (例如修正標籤、防範未經授權的錯誤) 揭露事項等等)。

隱私權注意事項

考量隱私權影響時，我們不會假設模糊運算子可處理模糊輸出內容。這些輸出結果包含符號化記錄檔、造成錯誤的輸入內容、產生的字典和產生的語料庫系統已將記錄假設為不含使用者資料，且密切關注隱私權疑慮其餘輸出內容衍生出來的資料因此，要確保模糊的輸入內容不受使用者資料影響，足以讓模糊的輸出使用無使用者資料。

您可透過三種方式將輸入內容新增至模糊語料庫：

如同種子輸入。應在原始碼存放區中簽入種子語料庫。禁止將使用者資料納入來源存放區的一般限制或
以手動方式為使用語料庫新增內容。
- 這大多是由模糊的基礎架構完成，例如 ClusterFuzz，因為其「交叉輪詢」模糊處理工具產生的輸入內容和其他執行個體在這個情況下，其他執行個體不會包含使用者以及新增的輸入內容
- 此外，人工運算子也可以透過 ffx 新增輸入內容。當你在。
為使用中語料庫產生的新增項目。這些輸入的變數現有輸入內容這些輸入內容不含使用者資料，因此產生的輸入內容某些輸入內容可能只會與某些使用者資料進行比對例如：以便產生有效的使用者名稱。不過，在這個例子中使用者資料沒有明顯的關聯。

不會將其他資料納入語料庫中，即使模糊線不是密封的 (而且非確定性！)，而且會使用測試領域所暴露來源的資料。架構不會將該資料視為測試輸入的一部分，也不會儲存。

最糟的情況就是模糊不清的功能，設計為刻意設計非密封，並使用暴露的功能來「從」測試領域傳送資料傳送到某些驗證 PII 的服務，例如傳回使用者名稱是否為有效。如此一來企圖混亂和測試架構試圖促進文化的單純。由於外部 Service 未經檢測，因此這優於隨機猜測。

此外，實務上，模糊不清。他們不會搭配使用者資料在產品設定中執行，但僅限在本機上開發模糊工具和 ClusterFuzz

測試

模糊引擎、目標轉接器程式庫和遠端程式庫都是單元並使用一般做法進行測試 (例如 GoogleTest、#[cfg(test)]、等)。此外，整合測試會使用預設的 ELF 測試執行元件來執行以及一系列有專門目標的範例目標的模糊化工作流程，來自編譯器-rt 的適用子集。

對於以此架構編寫的模糊化器，架構將採用相同的 GN 模糊範本目前支援的方法：建構時 未檢測版本中的模糊工具，將由測試取代引擎驅動程式庫直接執行種子語料庫中的每個輸入內容。這可緩解「bit-rot」確保所有模糊測試程式都能建構及執行也能做為尤其是模糊作者在在修正系統發現的瑕疵時新增輸入內容。

說明文件

模糊文件樹狀結構將更新為具體的使用新 GN 範本的範例其他預定說明文件異動 (例如程式碼研究室等) 也應反映這個架構。

缺點和替代方案

提議的方法可能的缺點包括：

效能降低的風險，而實作會緊密減輕模仿高效能模糊的模糊部分。
維護負擔，減少無須維護的費用不自然整合，例如POSIX 模擬。
耦合風險，例如：測試執行器架構可能會變更日後進行這項設計時還是有可能因為這樣的設計而無法使用如果這個問題日後會成為一個問題，只要在測試時更多 test_manager 功能直接整合至 fuzz_manager，例如：擁有後者會直接建立獨立的測試運作範圍

缺點我們探討的主題

程式庫模糊只有 libFuzzer。

libFuzzer 新增了足夠的 Fuchsia 支援功能，用於打造模糊工具在 Fuchsia 的幫助下。執行這些元件後，您就能透過 BigQuery 找出數百個錯誤但事實上，Google AI 也持續下去

同時，這些項目受限於程式庫結構的單一程序。由於元件是 Fuchsia 中可執行軟體的單位，與 FIDL 進行廣泛通訊，這可讓您 Fuchsia 代碼「unfuzzable」這種做法

傳統 libFuzzer

程序中 FIDL 模糊化。

Chrome 等專案曾透過執行用戶端和整合多個伺服器執行緒這需要同時修改和用戶端，並透過新的非標準設定執行。可重複使用但他們往往對元件生命週期的無彈性假設和/或根據語言繫結重新實作

簡而言之，應用程式封閉互動元件許多元件都具有小型的拓撲。收件者無論如何，只要執行或模擬整個封閉電源，複雜性、負擔和效能

這個方法已適用於 Fuchsia，但從未見過至少包含在上述限制中，因此廣泛採用。

處理中的 FIDL 模糊測試

單一服務 FIDL 模糊化功能。

設計跨程序 FIDL 模糊化架構的初始嘗試視為單一用戶端和服務在本設計中，libFuzzer 連結了 libFuzzer 對於服務，而用戶端會維護為簡易的 Proxy。變更者：在用戶端和伺服器之間保留 FIDL 介面時，目標較常見的設定及減少需要重新實作的程式碼

然而，這並不能解決元件關閉的問題因此相較於處理中的 FIDL 模糊化作業，幾乎沒有什麼好處。

單一服務 FIDL 模糊化功能

支援跨程序模糊化的 LibFuzzer。

一般來說，重複使用程式碼與重新實作相比，有幾項優點程式碼通常較為「成熟」、效能更好，錯誤也更少成本較低，維護成本也比較低因此嘗試擴充 libFuzzer，而不是設計和以及模糊化架構新的編譯器執行階段 clang_rt.fuzzer-remote.a 會執行以下操作做為遠端程式庫，而 libFuzzer 本身可以用作引擎。這兩個編譯器執行階段都會使用一組 OS 專屬的 IPC 傳輸程式庫，透過 Proxy 將方法呼叫傳送至其他程序。

與 libFuzzer 的維護人員共同進行了一連串變更並發布以供審查。此外，我們同時為 Linux 和 Linux 平台開發 IPC 傳輸程式庫的實作紫紅色。維護人員明確要求支援 Linux 持續測試，且已再次送交審查。

在 Linux 中，共用記憶體是以匿名對應檔案的形式建立，也就是透過 memfd_create，而信號只是透過 Unix 傳送的訊息。網域通訊端。這些通訊端也用來轉移共用記憶體檔案描述元，即透過 sendmsg 和 recvmsg。
在 Fuchsia 上，共用記憶體是使用 VMO 實作，透過及透過 FIDL 訊息交換資料的方式，與設計資訊

很遺憾，在延長審查期間，這個做法並不適合但由於處理過程的關係，此後 libFuzzer 的維護人員越來越擔心自己需要修改讓 libFuzzer 以非當初設計的方式運作最後，團隊決定無限期延後他們提出的變更提案。