14 ms·
This makes me wonder: what's the worst of side effects if I were to disable eBPF via, say, modifying the boot arguments for the kernel in something like /etc/de
by MrWiffles 4y ago
This makes me wonder: what's the worst of side effects if I were to disable eBPF via, say, modifying the boot arguments for the kernel in something like /etc/default/grub.conf?
Please correct me if I'm wrong here (I likely am), but isn't the fundamental design of eBPF engineered to allow injection of code into the kernel pertaining to MORE than just network-level stuff? Sure we see it at the network level primarily right now, but what's stopping that from being used for all kinds of things?
Short of very specific server-side applications, I see that as all risk, and little-to-no reward, so I'd like it disabled, especially on my personal workstation. Thing is, I know next to jack $#!t about eBPF, so I'm not sure what'll happen to my network (or other stuff?) if I just throw down and do that.
Any thoughts? Feasible? Bad idea(TM)?
- amrb 4y agoSounds like a good weekend project, investigate the effects of disabling ebpf.
- pabs3 4y agoIIRC systemd uses eBPF for some of its sandboxing/security features, so probably some of your services would be more vulnerable to exploits. There are other tools that use eBPF to mitigate specific Linux kernel vulnerabilities, or to do Linux kernel observation/tracing. https://isovalent.com/blog/post/2022-05-16-tetragon/ https://isovalent.com/blog/post/2022-05-16-tetragon/
- crtxcr 4y agoTo clarify: systemd uses seccomp to filter system calls. Seccomp employs the older BPF, but not eBPF. There was some work done to make seccomp use eBPF, but so far nothing is merged. eBPF is used in systemd's firewall code though, which allows filtering the IP addresses a service can contact. If this feature is not needed, eBPF can probably be disabled without impacting the other sandboxing features of systemd.