LLMs can easily already write eBPF code. Try it.

> tell me how you never actually developed an eBPF program without telling me you never actually developed an eBPF program

▲

nickysielicki 19 hours ago | parent [-]

Just try it. Here’s an example that I know it will work flawlessly for, because I used it for this: at $formerjob, all laptops come with a piece of malware called “connections”, which obnoxiously pops up at some point during the day (stealing window/mouse focus) and asks you some asinine survey question about morale on your team and/or the company values. There are a few good ways to solve this: apparmor/selinux (but this runs the risk of your config file conflicting with the rules shipped by IT), a simple bash script that runs pkill every 5 seconds (too slow and it still steals focus, too fast and your laptop fans start spinning), etc. A better way is to use a bpf hook on execve.

Ask an LLM to write a simple ebpf program which kills any program with a specific name/path. Even crappy local models can handle this with ease.

If you’re talking about more complicated map-based programs, you’re probably right that it will struggle a bit, but it will still figure it out. The eBPF api is not very different than any other C api at the end of the day. It will do fine without the standard library, if you ask it to.

▲

otabdeveloper4 11 hours ago | parent [-]

By eBPF I mean things like XDP network filters.

The issue here is the static formal validation the kernel does before loading your eBPF program.

(Even humans don't really know how it works. You need to use specific byte width types and access memory in specific patterns or the validation will fail.)

	▲	nickysielicki 5 hours ago \| parent [-]
		Respectfully, you don’t know what you’re talking about. 1. If you meant XDP, you should have said XDP, not eBPF. 2. The kernel does that validation on all ebpf code that it loads, regardless of whether XDP is involved. 3. Humans know how it works.