If you’re looking for a slightly higher level look, Unzip does it well:
http://unzip.dev/0x00c-ebpf/
A Beginner's Guide to eBPF
21–30 of 78 posts
Re: A Beginner's Guide to eBPF
#22Re: A Beginner's Guide to eBPF
#23If you’re looking for a slightly higher level look, Unzip does it well: http://unzip.dev/0x00c-ebpf/
Thanks for the shout-out!<3
Re: A Beginner's Guide to eBPF
#24I’m new to Linux kernel programming & eBPF (just started last week) and I’m having major troubles with eBPF verifier. I honestly feel like it would be easier for me to write a kernel module than eBPF code. I do wonder if this is the case for many people. It seems verifier is a bit unpredictable and makes eBPF programming quite painful.
Can confirm, it is quite painful.
The bpftools maintainers tell you to learn the bytecode format when you ask them what the errors mean, because they expect you to understand what the verifier means when it tells you "unknown scalar" on every single goddamn line of code.
Something like "ebpf coding rules, what to use and what not" would be very helpful.
All ebpf examples that are older than say, 3 months, already don't work anymore. Not even the official ones from the XDP tutorial project (and the libxdp maintainers because the kinda are splitting off a lot of headers into a separate xdp library as it seems).
Most userspace code still relies on the 5 years old bpf-helpers.h, which meanwhile is not supported anymore because it doesn't use the __helper methods from the kernel (they also refactored the kernel in the meantime, and force you to use e.g. __u128 instead of native data types).
Oh boi, did I underestimate what "bytecode vm" means when kernel developers talk about it.
Also, always use llvm, and remember to build two bpf files for each endianness, and use -g for debug symbols. Otherwise you will try to find out what the bpftool errors mean for days, because of shitty mailing list answers.
Re: A Beginner's Guide to eBPF
#25Something’s off here. I’m reasonably well read and literate on computer topics, I’ve worked in cyber security for over 5 years now, and extremely open-minded to new ideas — this reads at best like derivative marketing jargon and little in the way of technical.
The game changing idea behind eBPF is XDP in my opinion.
Lots of network drivers and NICs support offloading XDP programs ("xdp_prog") to the network controller's chipset, which results in zero CPU i/o interrupts if you e.g. use an XDP_DROP to block traffic.
Being able to block network traffic _before_ it reaches even kernelspace is a game changer.
Re: A Beginner's Guide to eBPF
#26[deleted]
Re: A Beginner's Guide to eBPF
#27[deleted]
[deleted]
Re: A Beginner's Guide to eBPF
#28I’m new to Linux kernel programming & eBPF (just started last week) and I’m having major troubles with eBPF verifier. I honestly feel like it would be easier for me to write a kernel module than eBPF code. I do wonder if this is the case for many people. It seems verifier is a bit unpredictable and makes eBPF programming quite painful.
It would be much easier to write a kernel module than an eBPF program. But the eBPF program is unlikely to panic your machine, and the kernel module is almost certain to.
Also In cloud environments, I would much rather trust an eBPF program, than a kernel module.
Re: A Beginner's Guide to eBPF
#29Earlier quoted context omitted.
Is a joke going over my head here, because the first sentence links to a document titled "what is eBPF?"
The joke is you have to give them all your information in a form to then download some B2B report... rather than add two sentences about what ePBF is
Seriously. I really don't know why people think that's acceptable. Who sees a website titled "A beginner's guide to X" that makes people hand over their data to even get "X" defined, and thinks "This looks good to me! Sign me up!"
Re: A Beginner's Guide to eBPF
#30I’m new to Linux kernel programming & eBPF (just started last week) and I’m having major troubles with eBPF verifier. I honestly feel like it would be easier for me to write a kernel module than eBPF code. I do wonder if this is the case for many people. It seems verifier is a bit unpredictable and makes eBPF programming quite painful.
Reading more about that… How does the verifier detect infinite loops anyway? Halting problem and all. It must use some rather crude heuristics, no?