花了一些時間，瞭解了一下ebpf 的功能、程式碼、for windows 使用，

看了一下相關的邏輯，

目前個人感覺是，不宜應用到我們自己的專案中，

以下所說”指令碼“，均指”開發人員修改的規則檔案，形式是gnuc 程式碼“。

優勢：速度快，各種速度都快

開發：一套框架，直接用到死

修改規則：開發人員直接使用C語言來按照格式寫指令碼，然後使用特定的編譯器來編譯指令碼，之後，將指令碼下發給客戶端之後，客戶端可以再處理編譯好的指令碼邏輯，把它插入到自己的邏輯中，以實現邏輯的熱更新，

缺點：

為了提高規則匹配效率，實際上開發的邏輯是在驅動層直接執行的，這就直接導致一個問題，就是萬一寫規則的時候隨便寫錯點什麼，結果可能就是BSOD。

規則要求用C語言來寫，難度極高。且語法為GNUC 語法，相對我們 VC 開發並不友善。就編譯器而言，僅能使用LLVM編譯，GCC都不行，因為實際上編譯出來的是 BPF 平臺的偽碼，LLVM 通過定製平臺來實現針對 BPF 平臺來編譯，其他編譯器目前無新增此功能。

LLVM 編譯時，各種命令需要手敲，整套工具鏈都不友好。

內部邏輯複雜，由於LLVM編譯出來的檔案是elf格式的檔案，所以針對”指令碼“編譯出來的也是elf檔案，需要在我們專案中整合一個elf解析器，來解析對應的elf 檔案。有點類似”從dll 中扣 shellcode“ 的意思，但是這個 shellcode 是在客戶端上載入規則的時候現扣的。

它需要極專業的人，來使用特定的語言來開發一套基於C語言的程式碼，相關語法延續C語言，但是內部關鍵字、函式等全部使用bpf支援的，需要大量學習練習bpf 相關開發。體現在學習、使用的角度上，人力成本及後續的使用成本非常高。維護成本可能很低，但是依然會有，一些特定的功能需要定製化在引擎內部開發，很類似於給lua引擎提供介面，供指令碼使用。

這東西本質上和一套核心級指令碼沒有區別，僅僅是因為它的出現較早，即1992年，那時候還沒有什麼比較成熟好用的指令碼，lua 是1993年才出現的。如果站在指令碼的角度上的話，我們有更多選擇，有更多更成熟的指令碼解決方案，不一定要使用它。難道僅因為它名氣很大麼。

雖然有針對性的工具BCC（https://raw.githubusercontent.com/windywolf/example/master/eBPF/bccsample.py）能方便地處理相關編譯、偽碼提取等功能，但是BCC是 Python 做的，也只能做一些簡單的工作，無法從根本上解決整套架構的使用問題。

它內部維護的資料，繫結方式為 key => value 對的邏輯繫結，是精確繫結，沒有模糊查詢的功能針對我們的需求，有些水土不服。

以上缺點，大多數情況下，都不算缺點，但是對我們來說，成本太高。

雖然可以將其移植到上層，供上層使用，但是如果是這樣的話，那我們用其他任意一種成熟的語言都可以解決問題啊 。

綜上：

此解決方案看似很好，但是專業性，要求太高，成本太高，可以做完，但是做完之後，後續改動成本也非常高。

若僅從結構上看，其整體架構與lua沒有本質區別，內部依然是一套vm執行各種相關指令，僅僅是將lua的 op_code 變成了 bpf 的 op_code 。

現有可參照專案為 ebpf for windows 。編譯環境很費勁。

如果有時間，或者有需要，這玩意可以做一個組內分享，但是感覺，其實沒啥必要，如果真的撈乾的說，這玩意其實很簡單，就是程式碼亂七八糟，又沒有比較詳細的資料，看起來比較累。

在個人的角度看：

它是一個時代的產物，在1992年那個時代，驅動開發不易，且linux核心是個標準的巨集核心框架，如果要對其中一個驅動模組做修改，那麼實際上是需要有一整套核心原始碼的，雖然不用重新編譯一整套核心原始碼，但是依舊開發不易，編譯不易，又沒有比較好的指令碼框架可供使用，bpf框架在那個時代出現，解決了大問題，這毫不稀奇。之前如果需要改驅動邏輯，要大學linux核心，還需要整體核心重編，在這個環境下，bpf框架支援了在外部修改邏輯，指令碼式的直接插入，在不改程式碼的情況下，修改其相關內部邏輯，這個技術在當時那個年代絕對是非常超前的。

（想一想，多執行緒技術在1990年左右，Win3.0年代，都是個很超前的技術，但是現在來看，不會多執行緒能找到工作麼。）

但是到了windows上，windows是標準的微核心框架，編譯相對容易，開發也不復雜，至少有微軟做後盾。如果需要改邏輯，直接改程式碼就好了。我直接重編一個驅動模組，就可以了。我完全不需要增加一個XXXX來增加我的風險。

我個人看ebpf 的程式碼，也不過3天多，所以有些地方可能說的不準確、不客觀，但是我幹認為大體應該就是這樣了。

或許我可以用它來代替lua。