題幹與適用場景
如果要把一個 eBPF 觀測程式部署到不同發行版和核心版本，你會如何解釋 verifier 在保護什麼、如何排查載入失敗，以及如何設計可驗證的相容性矩陣？
這道題適合平台工程、Linux、SRE、安全和系統設計職位。它考察核心邊界、靜態驗證、使用者態載入生命週期和發布紀律。eBPF 程式會在附著到核心掛鉤前經過 verifier；通過驗證不代表業務邏輯正確，也不代表所有核心、權限、helper、map 和 BTF 環境都相容。
面試官考察點
- 是否能區分 verifier 的安全約束與業務結果正確性。
- 是否理解暫存器型別、指標邊界、堆疊初始化、迴圈和 helper 能力檢查。
- 是否描述 libbpf 的 open、load、attach、teardown 生命週期。
- 是否用 BTF、CO-RE、特性偵測和核心矩陣處理版本差異。
- 是否為 verifier 日誌、權限、map 資源和附著失敗設計排錯路徑。
- 是否知道 eBPF 仍受核心漏洞、helper 語意和觀測開銷影響。
30 秒回答框架
「verifier 在程式執行前進行靜態檢查，證明控制流可終止、記憶體存取有界、暫存器和指標型別合法，並限制可呼叫的 helper；它不能證明指標含義正確。部署時我把物件開啟、載入、驗證、附著和拆除分成可觀測階段，用 verifier 日誌定位問題。透過 BTF/CO-RE、特性偵測和按核心、架構、權限的 CI 矩陣確認相容，失敗時保留使用者態降級或不附著，而不是強行繞過檢查。」
分步深入解答
第一步：劃定 eBPF 的安全邊界
eBPF 程式執行在核心提供的受控環境中，不能任意讀寫核心記憶體或呼叫未授權函式。verifier 會沿控制流追蹤暫存器、堆疊、map 指標和封包指標狀態，拒絕無法證明安全的路徑。它是安全門檻，不是完整形式化證明，也不替應用檢查採樣邏輯、隱私和資源成本。
先說明程式類型和附著點：tracepoint、kprobe、cgroup、XDP 等上下文擁有不同輸入、helper 和返回值約束。同一份源碼換到不同程式類型，可能因為上下文或能力不同而無法載入。
第二步：理解 verifier 常見拒絕原因
未初始化暫存器、堆疊越界、未檢查的空指標、封包邊界不足、無法證明的迴圈、helper 參數錯誤和不可接受的指標算術都會導致拒絕。查看日誌時先找第一處狀態失效，不要只修最後一行提示。
/* 偽程式碼：先檢查邊界，再讀取封包欄位 */
if (cursor + sizeof(struct header) > data_end)
return DROP;
struct header *h = cursor;
return handle(h->kind);程式應保持路徑簡單、邊界檢查靠近讀取點，並把複雜解析拆成可驗證的小函式。迴圈要有明確上界；map lookup 返回值要先判空；指標型別轉換必須符合目前上下文允許的規則。
第三步：解釋 libbpf 生命週期
使用者態 loader 先 open BPF object，發現程式、map 和全域變數；load 階段建立 map、處理重定位並請求核心 verifier；attach 階段把程式掛到掛鉤；teardown 階段解除附著並釋放資源。每個階段都要記錄物件名稱、程式類型、核心版本、錯誤碼和 verifier 日誌。
載入成功不等於附著成功。權限、鎖定記憶體上限、缺少 BTF、hook 不存在、map 數量和 ring buffer 資源都可能在不同階段失敗。啟動器應讓失敗階段可見，並在部分程式成功時明確哪些能力已啟用。
第四步：設計 map、事件和資源上限
map 是核心與使用者態共享狀態的主要機制。先選擇 hash、array、per-CPU、ring buffer 等型別，再定義 key、value、更新並行、生命週期和容量。高頻事件應有採樣、批次讀取和丟棄計數，不能讓觀測程式反過來耗盡核心資源。
把敏感欄位在核心側最小化，必要時只傳雜湊、類別或計數。使用者態消費執行緒要處理 ring buffer 溢出、重啟和版本變化；遺失事件應被明確計數，不能當作零事件。
第五步：處理 BTF、CO-RE 與版本相容
BTF 提供型別元資料，幫助 loader 和工具理解程式、map 和核心符號。CO-RE 讓程式按型別重定位，減少為每個核心重新編譯的需要，但它不能消除所有差異。helper、kfunc、程式類型、架構、編譯器和權限仍要逐項偵測。
相容性矩陣至少覆蓋發行版、核心版本、架構、BTF 是否存在、特性開關、容器權限和目標 hook。CI 在真實或虛擬核心上執行編譯、verifier load、attach、事件回放和 teardown；只通過編譯不算相容。
第六步：建立排錯、降級和發布流程
排錯順序可以是：確認核心與權限，再看程式類型和 hook，收集完整 verifier log，檢查 BTF 與 helper，最後驗證 map 資源和使用者態消費。將失敗歸類為源碼安全、能力缺失、權限設定、執行時資源或業務邏輯，便於選擇修復動作。
生產發布先在影子節點或少量主機附著，監控 CPU、記憶體、事件遺失、verifier 拒絕、核心日誌和目標指標。無法載入時，使用者態服務繼續提供原有路徑，觀測能力降級為既有 metrics 或日誌。保留上一版本物件和 detach 操作，確保回退不依賴新程式。
資訊增益與邊界
eBPF 的關鍵增益是把「核心可程式化」約束在可驗證、可觀測的載入流程中。verifier 證明的是一組安全屬性，不是程式意圖；CO-RE 提高可攜性，但不保證跨版本成功。面試中應同時談安全、相容、資源和業務正確性。
高品質示範回答
「我會先說明程式類型和附著點，因為上下文決定輸入、返回值和 helper 能力。verifier 在執行前沿控制流追蹤暫存器、堆疊、map 和封包指標，拒絕未初始化暫存器、越界、未判空、無界迴圈和非法 helper 參數。通過 verifier 只表示這些路徑可安全執行，不表示採樣邏輯或業務指標正確。
使用者態以 libbpf 把 open、load、attach 和 teardown 分成可觀測階段。load 失敗先保存完整 verifier log，區分源碼安全問題、缺少 helper、BTF、權限和資源限制。部署使用 BTF/CO-RE 減少重新編譯，但仍按發行版、核心、架構、hook、權限和特性建立真實核心矩陣，測試編譯、load、attach、事件回放和拆除。
我會限制 map 容量和事件速率，記錄遺失計數，敏感欄位在核心側最小化。生產採用影子節點和小比例灰度，監控 CPU、記憶體、事件遺失和核心日誌；載入失敗時保留原有 metrics 或日誌路徑，回退到上一版本並執行 detach。這樣既利用 eBPF 的觀測能力，也不把 verifier 或 CO-RE 誤解成絕對安全和絕對相容。」
常見錯誤
- 把 verifier 當業務正確性證明 → 它不檢查指標含義和隱私 → 另做回放、採樣與資料稽核。
- 只看編譯是否成功 → load、attach、權限和 BTF 仍可能失敗 → 在真實核心矩陣執行全生命週期測試。
- 看到日誌最後一行就改程式碼 → 根因通常是更早的狀態失效 → 從第一處暫存器或邊界錯誤開始定位。
- 無上限地寫 map 和事件 → 觀測程式會耗盡核心資源 → 限制容量、採樣並記錄遺失。
- 認為 CO-RE 消除了版本差異 → helper、hook、權限和架構仍不同 → 特性偵測與降級。
- 沒有使用者態回退 → eBPF 載入失敗會影響主業務 → 保持原有 metrics、日誌和 detach 路徑。
追問及應對
verifier 說指標可能為空，如何修復？
在使用返回指標前沿所有控制流顯式檢查空值，並保持檢查與解引用靠近。若分支複雜，拆成較小函式並重新查看 verifier 狀態，不用不安全的強制轉型掩蓋問題。
同一程式在一個核心能載入，另一個核心失敗怎麼辦？
比較程式類型、helper、kfunc、BTF、架構、設定、權限和 verifier 日誌，確認實際能力而非只比較版本號。透過特性偵測選擇替代路徑，將結果加入相容性矩陣和發布門檻。
如何保證事件遺失不會被誤判為系統正常？
在核心側和使用者態都記錄遺失、環形緩衝區溢出和消費者重啟計數，並把採樣率、遺失率和觀測覆蓋寫入指標。沒有完整事件時，面板應顯示不確定狀態，而不是零值。
verifier 通過後還需要安全評審嗎？
需要。評審程式權限、資料最小化、使用者態 loader、升級和回退、核心漏洞暴露面及資源上限。verifier 是必要門檻，不能取代威脅建模和執行時監控。