在 Kernel 模塊中存儲每個進程的數據/在 sys_enter 和 sys_exit 探針之間傳遞數據

Question

賞金將在 6 天后到期。 此問題的答案有資格獲得+100聲望賞金。 anroesti想讓更多人關注這個問題。

不一定需要熟悉Linux Kernel Tracepoints 的工作原理來幫助解決這個問題，這正是引發這個問題的原因。 本質上，我正在尋找一種方法來存儲 kernel 模塊的每個進程數據，而不修改 Linux 源（例如struct task_struct ），理想情況下不使用鎖。 這是我的具體問題：

我有一個 kernel 模塊，它連接到sys_enter （此處為x86_64 、 aarch64定義）和sys_exit （ x86_64 、 aarch64 ）跟蹤點。 對於發出的每個系統調用，我需要在進入探測器和退出探測器之間傳遞一些數據。

我考慮過的一些事情：我可以...

• ...使用一個全局變量——但它將在不同 CPU 上並發執行的系統調用之間共享，從而造成競爭。
• ...使用一個來自 PID（發出系統調用的進程）的全局 map 到我的數據，連同鎖——但這將不必要地要求在每個系統調用中所有 CPU 之間進行同步。 我想避免這種情況，因為數據對於每個發出的系統調用都是“本地的”，所以我覺得應該有一種方法可以將其保存在本地並且不會增加昂貴的同步。
• ...使用每個 CPU 的全局變量——但是（據我了解）一個進程可能會在系統調用執行期間移動到另一個 CPU，從而使這種方法不正確。
• ... kmalloc在每個系統調用條目上為我的自定義數據分配一些 memory，然后通過破壞struct pt_regs中的一個寄存器（入口和出口探針都接收到指向所述結構的指針）將地址傳遞給該 memory - 但是那么對於不觸發退出探測的系統調用（例如永遠不會返回的sys_exit ），我將出現 memory 泄漏。

對於如何改進這些想法以解決我列出的問題的任何建議，或者我沒有想到的任何完全不同的想法，我都持開放態度。

Answer 1

為了安全起見，我會使用啟用 RCU 的哈希表。

正如您所說，第一個選項實際上不可行。

第三個要求您跟蹤哪個進程正在使用哪個 CPU，這似乎沒有必要。

第四個選項的泄漏問題可能可以以某種方式解決，但是在每個系統調用上分配 memory 會引入嚴重的延遲。 當然，訪問哈希表也會降低系統速度，但它不會為每個系統調用觸發 memory 分配，所以我認為危害較小。

另外，我在這里可能是錯的，但是如果您假設只有進程創建/銷毀才會對表本身進行更改（不是每個條目中的數據，而是每行的位置和 hash 值），那么您甚至可能不會必須在每個系統調用上同步，但僅限於那些會導致進程創建/銷毀的系統調用。