最近筆者遇到這樣一個相對比較疑難的事件，某個在Linux下運行的殺毒軟體啟動后在，某些情況下CPU占用率會持續升高，而且在交易量較高的情況下極易復現，而奇怪的是我們之前已經對于殺毒軟體的CPU使用率進行了上限限定，但是出現這樣例外事件表明殺毒軟體并沒有執行之前設定的資源占用控制策略，CPU使用率始終持續例外偏高，
分析下來這個事件還是很有借鑒意義的，由于此事件涉及一些敏感資訊，因此具體不便公開的細節也就不透露了，僅把可以公開的情況梳理一下，供各位讀者參考，首先我們先明確一下鉤子（hook）函式的概念，簡單來講這就是一類改變其它函式行為的函式，舉個簡單的例子，我每次進入會議室的時候都是直接推開門然后進入的，但是現在我在進入門之前要先向向會議室主持人申請，得到許可才能進入，那么向主持人申請的動作就被attatch到了進入會議室這個動作上了，整個程序就可以簡單的理解為hook，
我們知道在Linux下想改變系統的行為，需要代碼運行的內核態，比如kprobe,fsnotify等機制，提供了root用戶hook到內核代碼的權限，并最終將自己的代碼段attach到內核呼叫中，
CPU使用率過高的原因分析
經確認這款殺毒軟體的CPU占用率控制模型如下圖，其守護模塊會定時判斷agent資源使用情況，如果超標則將釋放掃描模塊使用的CPU與記憶體資源，
但是具體分析下來這樣的機制在IO頻繁的系統上存在缺陷，具體原因掃描模塊在內核態下執行時下無法釋放CPU資源，分析程序如下：
經確認殺毒軟體agent在行為監測時，在行程將檔案加載到記憶體前，會使用hook技術對于open等系統呼叫進行attach，確定加載的檔案不含惡意代碼后，才允許行程加載該檔案，因此在Linux內核找到系統呼叫的attatch機制的相關代碼進行分析，
1.系統呼叫中sys_open函式使用fsnotify機制對于attach注入到sys_open函式的行程進行回呼通知，(具體代碼位置在kernel/open.c）
2.attach到sys_open的代碼執行程序始終是處于內核態中的，同時Linux的fsnotify機制也會加內核鎖，在內核鎖解鎖前該行程無法釋放CPU，不能被打斷，(具體代碼位置在kernel/fsnotify.c）
殺毒軟體掃描模塊attach內核函式的機制與fsnotify類似，因此其掃描模塊在進行行為檢測時會在內核態執行且不能被打斷，而在系統中原本就有大量IO操作的情況下，守護模塊將失效，
在POC測驗時，該殺毒軟體在檔案掃描時其CPU占用率始終不高，這其中的原因是由于在掃描檔案時該殺毒軟體全部運行于用戶態下，不存在內核態運行的情況，因此守護模塊可正常調節CPU使用情況，
解決方案淺析
先說一下實測結論在加入attach延時操作后，IO吞吐量巨幅下降，經訪照該殺毒軟體的機制進行實測模擬，在內核sys_open函式attach加入延時操作，觀察對于系統IO的影響，
在加入將內核sys_open延時一倍的操作后，我在華為的在鯤鵬4C/8G的平臺實測上，每秒鐘檔案打開、關閉檔案操作的次數，由每秒867次的鋒值下降到了72次，出現了90%以上的下降，這可能與內核鎖的雪崩效應有關，
經確認在之前的版本之所以沒有出現問題，是由于當守護行程在確認CPU調節失效后會對自身agent進行整體自毀操作（modelu_exit)，因此不會觸發類似于CPU占用率持續升高的案例，那么針對這樣的機制具體的解決方案如下：
- 對于內核態代碼執行，加入全域并發數限制，對于所有執行在內核態的掃描執行緒，進行全域并發鎖限制，具體并發數的設定還需要進行進一步測驗后得出結果，在鯤鵬4C/8G的平臺上測驗最大并發數設定為4基本不會對系統正常呼叫產生影響，建議先將系統CPU個數設定為最大并發數，進行測驗，
- 對于對于內核態代碼執行加入每秒執行次數限制，對于所有執行在內核態的掃描執行緒，進行全域的執行次數限制，加入執行令牌，每秒執行次數不應該大于最大IO數量的10%，在此方案下也可避免對于系統正常呼叫的影響，
- 加入掃描任務調度機制：避免在內核態執行耗時的掃描任務，只是快速收到系統的open呼叫指令后，將相關的掃描任務加入除錯佇列，就立刻回傳，在用戶態統一執行掃描任務，也可避免由于代碼長時間運行于內核態造成的問題，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/252628.html
標籤：AI