Little snitch alternatives how to#
Little snitch alternatives verification#

There's also an ongoing migration of all projects (?) to xdp-tools, which seems to be redundant in terms of bpf related topics, but also has only a couple examples that somehow work The libbpf repo contain also examples that won't compile. If you don't have the old headers, you'll find a lot of issues that show you the specific git hash where the 'bpf-helpers.h' file was still inside the kernel codebase. The BCC tools (bpf compiler collection) are still using examples that can't compile on an up-to-date kernel. There's a lot of limitations that are documented _nowhere_ on the internet, and seemingly all developers are supposed to know them by reading the bpftool codebase itself!? Who's the audience for using the bpftool then? Developers of the bpftool itself?

Little snitch alternatives how to#

The bpftool maintainer is kind of unfriendly, he's telling you to read a book about the bytecode format if your code doesn't compile and you're asking about examples on how to use pointers inside a BPF codebase because it seems to enforce specific rules in terms of what kind of method (_always_static) are allowed to modify or allocate memory. If you miss them, good luck getting a better error message out of the kernel while loading the module.

Little snitch alternatives verification#

have to use if pointer < size(packet) around it), which only happen in the verification process and can only be shown using the bpftool. Anything pointer related that eBPF verifier itself doesn't support will lead to 'unknown scalar' errors which are actually out of bounds errors most of the time (e.g. If you forget that '-g' flag you're totally fucked. Took me a while to figure out what 'unknown scalar' really means. Compiling eBPF via clang to the bpf bytecode format without debug symbols will make every following error message down the line utterly useless. I mean, it's a virtual bytecode format for a reason, right!?

In my personal opinion a bytecode format for both little endian (bpfel) and big endian (bpfeb) machines is kinda unnecessary. Loading an eBPF module without the CAP_BPF (and in some cases without the CAP_NET_ADMIN which you need for XDP) capabilities will generate a 'unknown/invalid memory access' error which is super useless as an error message. It's like maintainers decided to make this as hard as possible out of pettiness and 'they have to use C APIs instead' or something. The whole BPF verifier and development process is so botched, it's ridiculous.