4 ms·

Many things that you may have wanted to do with a kernel module can now be done more easily and safely with eBPF. https://ebpf.io/get-started/ https://ebpf.io/

Many things that you may have wanted to do with a kernel module can now be done more easily and safely with eBPF. https://ebpf.io/get-started/ https://ebpf.io/get-started/ Nevertheless, the OP is a classic guide and worth a read.

tetris11 3y ago
That's pretty tidy. Is there any noticeable overhead in listening to all kernel sockets and hooking in your code when it matches a packet filter, compared to just building it into the kernel?
- bjackman 3y ago
  It's pretty damm fast. Everything is JITed and there's codegen for the "trampoline" logic so that there aren't even indirect branches to get to the program code. The "overhead" comes from the fact that writing nontrivial BPF programs is quite hard. Getting programs to pass the verifier can become a bit of an art. This does tend to get easier if your production environment has few and recent kernel versions. And then of course this "overhead" totally pays for itself in terms of reliability. It's really hard to accidentally break machines with BPF, while a kernel module in your prod environment is a time bomb :D (Deliberately breaking machines with BPF is very easy though. This sometimes seems to surprise people but if your attacker gets CAP_BPF it's probably game over).
pcthrowaway 3y ago
> Nevertheless, the OP is a classic guide and worth a read. For anyone curious why a book published in 2023 is being called a "classic", it appears to be a republication (possible update) of https://tldp.org/LDP/lkmpg/2.6/lkmpg.pdf https://tldp.org/LDP/lkmpg/2.6/lkmpg.pdf from 2001 There are 2 new authors listed so I'm assuming the content has been refreshed
- laweijfmvo 3y ago
  I've probably written or dabbled with kernel modules three times in my life: first in college (~2010), second for a take-home interview question (~2015), and third as part of my job duties (~2020), and every time I do so I find that the APIs/best practices have changed. So I really hope there's a definitive guide that stays up to date until at least ~2025 when I next need it.

tetris11 3y ago

That's pretty tidy. Is there any noticeable overhead in listening to all kernel sockets and hooking in your code when it matches a packet filter, compared to just building it into the kernel?

bjackman 3y ago
It's pretty damm fast. Everything is JITed and there's codegen for the "trampoline" logic so that there aren't even indirect branches to get to the program code. The "overhead" comes from the fact that writing nontrivial BPF programs is quite hard. Getting programs to pass the verifier can become a bit of an art. This does tend to get easier if your production environment has few and recent kernel versions. And then of course this "overhead" totally pays for itself in terms of reliability. It's really hard to accidentally break machines with BPF, while a kernel module in your prod environment is a time bomb :D (Deliberately breaking machines with BPF is very easy though. This sometimes seems to surprise people but if your attacker gets CAP_BPF it's probably game over).

pcthrowaway 3y ago

> Nevertheless, the OP is a classic guide and worth a read. For anyone curious why a book published in 2023 is being called a "classic", it appears to be a republication (possible update) of https://tldp.org/LDP/lkmpg/2.6/lkmpg.pdf https://tldp.org/LDP/lkmpg/2.6/lkmpg.pdf from 2001 There are 2 new authors listed so I'm assuming the content has been refreshed

laweijfmvo 3y ago
I've probably written or dabbled with kernel modules three times in my life: first in college (~2010), second for a take-home interview question (~2015), and third as part of my job duties (~2020), and every time I do so I find that the APIs/best practices have changed. So I really hope there's a definitive guide that stays up to date until at least ~2025 when I next need it.