4 ms·

In my opinion Linux and eBPF is considerably better and more flexible when it comes to firewalling and deep packet inspection based blocking. The mentioned use

In my opinion Linux and eBPF is considerably better and more flexible when it comes to firewalling and deep packet inspection based blocking. The mentioned use case perfectly fits the eBPF XDP module's feature set, and could easily be mitigated with the LPM trie offered by the kernel. I wish that in those regards BSD maintainers would start to cooperate more with Linux, because everybody benefits from cross-kernel compatibility when it comes to eBPF. I always admired the BSD maintainers, back in the days they were very innovative but I always have the feeling that at some point when their innovations take off they just stop following up with it due to either very opinionated views or lack of interest. Especially with the ongoing eBPF community.

yjftsjthsd-h 3y ago
This presupposes that ebpf is obviously the one true solution and everything should use it. I would prefer that we avoid monocultures.
- cookiengineer 3y ago
  It's not a mono culture but the idea of true cross-platform APIs that could make supporting BSD kernels much much easier in both terms of development time and interoperability. > I would prefer that we avoid monocultures. Where were you to say "Stop the C and POSIX monoculture", because that's a pretty opinionated view on how to build kernels, too, you know. I'd prefer interoperability over having to implement everything myself all the time, any day.
  - yjftsjthsd-h 3y ago
    People do regularly point out that POSIX limits exploration of interesting ideas in computing, and a segment of the community is actively attempting to deprecate C. I think it's a continuum; I personally think being unix-like is a useful baseline without being too limiting, but the cost/benefit rapidly degrades after that. As a topical example, I'm glad that everything didn't adopt iptables, because pf seems to be more friendly to work with. I don't mind ebpf, but I wouldn't be surprised to see one of the BSDs leapfrog it.
    - cookiengineer 3y ago
      My point of view is always a little too much security focussed when it comes to kernel mod dev. I completely agree with embracing Rust and other memory safe languages. Hence why I think eBPF has huge potential due to their CORE abstractions that are very strict in terms of memory management and validation. But when the source code of the NSA's ebpf malware was leaked, I got concerned because currently there is no failsafe way to audit a running kernel. I think that the logical conclusion to this has to be something like a manifest file for each running kernel module, and a better feature-based sandbox for each module that is running or hooked (e.g. usb, network, filesystem, home folder etc). Similar to how Android's sandboxes are designed, but with a concept that is able to sandbox kernel mods, too. Seccomp sandboxes are not enough, and there is gonna be a decade of new ebpf malware ahead of us. I wish that rust got more traction, because that would at least solve all the pointer corruptions and overflows that can/are going wrong in module codebases.
gigatexal 3y ago
I disagree on the firewalling front. I mean sure eBPF and iptables likely scales well but for home or small business users until there’s a simple declarative syntax like PF that abstracts the need for small C programs to run as eBPF requires it won’t gain adoption or be used or advocated by many. I’ve never had to deep packet inspect so I’m not even sure there. The article just mentions that if state tables are exhausted packets start dropping. This is the case in every switch, too. It’s a common thing. Being able to increase this is a nice stop gap. It’s not a fatal flaw wrt to PF. Also for better or worse BSD being different is what makes it interesting. BSD devs and hackers are a fraction of what the Linux kernel and greater ecosystem have in terms of the all of K8s and other Linux foundation projects. But BSDs have been innovating within their community of hackers for years and they don’t need to just be a derivative of Linux. That being said the concepts of eBPF could be ported and the interface adopted could be interesting. If anyone pushed or funded that effort it might be the Netflix folks.
- 0dayz 3y ago
  >Also for better or worse BSD being different is what makes it interesting. BSD devs and hackers are a fraction of what the Linux kernel and greater ecosystem have in terms of the all of K8s and other Linux foundation projects. But BSDs have been innovating within their community of hackers for years and they don’t need to just be a derivative of Linux. I disagree, you can still be unique while having interoperability with the mainstream. Just take a look at netbsd, sure it's all about ofc it runs netbsd, but it's hidden feature is trying to be interoperable.
tete 3y ago
tl;dr: I think eBPF is great and that there are many things to criticize about the BSDs, but I think the claims about innovations taking off and BSD developers not cooperating are baseless. I'm sorry. There's much to criticize the BSDs for, but compared to Linux a lack of innovation simply isn't among them. From containers to capabilities, from networking to storage, from event handling to audio (and I am talking about the kernel side of things here) Linux runs in circles, re-inventing half-baked solutions that becomes yet another deprecated, yet still supported API/syscall a few years in. Also on the note of corporation. There has been more than one event where corporation was the intention and some Linux guy posted on some public mailing list about the OpenBSD developers will be sued. And when it comes to user space the situation is even more clear. But then again one has to admit that there are philosophical clashes, especially when it comes to OpenBSD. If you look at FreeBSD there's a lot more interaction. See OpenZFS. Here FreeBSD decided to corporate. At the same time, even though that is user space, Wayland and other projects are defined as "for Linux". I believe in general there's a lot more cooperation than you think. It's just that devs aren't really much into making everything some public ceremony. If you share a common fields, you might go to common events or send an email, jump into an IRC, Discord, etc. Especially given the history regarding licenses. People - on both sides (if you can even call it that) - now behave properly and talk things out directly instead of having mud fights. And if you look at the OpenBSDs Innovation page on their website, compare the list of Programs and subsystems as well as the list of Projects maintained by OpenBSD developers with what people think is great software or with software that's on your system and you don't even think about cause it never ever made problems. And then you have things like sndio which I've seen shipped with more than one game on Steam, because it just works and everyone doing proper updates (Android, RPM, etc.) using bsdiff (granted, that one is in fact older). The main thing where the BSDs sometimes lag behind (with exceptions such as Apple's ARM processors, etc.) is supporting each and every device of hardware. However, one has to say that your Thinkpad has a better chance of working properly out of the box than any Linux distribution I ever encountered. And while that worked decades ago, I currently don't manage to have any system properly handling audio input/output states. It either switches around in terms of muting, or it forgets that the headphones were connected, outputs to the wrong place, etc. To be fair that also does seem a problem with some other OSs, but on OpenBSD it's always correct. I mention this because it's one example of hardware actually working, and not being wonky. And I don't have to constantly be scared that the next driver version breaks stuff, or that an API is deprecated. Yes, Linux is absolutely excellent on keeping compatibility, but the sad state is that you'll end up with 10 APIs with different parts not working properly. And don't get me started with epoll vs kqueue. It's one great example of what I mean by half-baked solutions. Or think about how hacky setuid for processes on multi-threaded processes on Linux is. Setting owners of a thread instead of of the whole process? Every other OS gets that one right, but on Linux even big projects like Go struggle: https://github.com/golang/go/issues/1435 https://github.com/golang/go/issues/1435 Btw: I say that at someone who is a huge fan of eBPF, even though I have to admit that it really is a double-edged sword. It's not one of these "this is at least better than not having it in all situations" things, even though some people sadly act like it. And one thing that is great about the BSDs at a community level is that they don't jump on every hype train. I think if they did they'd probably be dead by now, because they are smaller and so building something, changing the whole system to support it properly only for the next big thing replacing it three years later doesn't work for them. So that's where the being opinionated probably stems from. They very strongly go towards something they know will still be there and sensible in 5-10 years. You can read that in nearly all popular "critical of something" posts. It's always about wild unfounded claims or re-inventing something that didn't work out.
chasil 3y ago
On the other hand, pf is cross-platform, running in Solaris and FreeBSD. That carries some weight. I have seen the Linux kernel migrate from ipfwadm to ipchains to iptables to nftables, and this has involved occasional reworking of some simple firewall rules from time to time. On those later occasions, I did admire pf.
- toast0 3y ago
  pf may be on all those platforms, but pf rules are not cross-platform, because different platforms have different rule syntax and different capabilities.
- keep_reading 3y ago
  pf is in MacOS too

yjftsjthsd-h 3y ago

This presupposes that ebpf is obviously the one true solution and everything should use it. I would prefer that we avoid monocultures.

cookiengineer 3y ago
It's not a mono culture but the idea of true cross-platform APIs that could make supporting BSD kernels much much easier in both terms of development time and interoperability. > I would prefer that we avoid monocultures. Where were you to say "Stop the C and POSIX monoculture", because that's a pretty opinionated view on how to build kernels, too, you know. I'd prefer interoperability over having to implement everything myself all the time, any day.
- yjftsjthsd-h 3y ago
  People do regularly point out that POSIX limits exploration of interesting ideas in computing, and a segment of the community is actively attempting to deprecate C. I think it's a continuum; I personally think being unix-like is a useful baseline without being too limiting, but the cost/benefit rapidly degrades after that. As a topical example, I'm glad that everything didn't adopt iptables, because pf seems to be more friendly to work with. I don't mind ebpf, but I wouldn't be surprised to see one of the BSDs leapfrog it.
  - cookiengineer 3y ago
    My point of view is always a little too much security focussed when it comes to kernel mod dev. I completely agree with embracing Rust and other memory safe languages. Hence why I think eBPF has huge potential due to their CORE abstractions that are very strict in terms of memory management and validation. But when the source code of the NSA's ebpf malware was leaked, I got concerned because currently there is no failsafe way to audit a running kernel. I think that the logical conclusion to this has to be something like a manifest file for each running kernel module, and a better feature-based sandbox for each module that is running or hooked (e.g. usb, network, filesystem, home folder etc). Similar to how Android's sandboxes are designed, but with a concept that is able to sandbox kernel mods, too. Seccomp sandboxes are not enough, and there is gonna be a decade of new ebpf malware ahead of us. I wish that rust got more traction, because that would at least solve all the pointer corruptions and overflows that can/are going wrong in module codebases.

gigatexal 3y ago

I disagree on the firewalling front. I mean sure eBPF and iptables likely scales well but for home or small business users until there’s a simple declarative syntax like PF that abstracts the need for small C programs to run as eBPF requires it won’t gain adoption or be used or advocated by many. I’ve never had to deep packet inspect so I’m not even sure there. The article just mentions that if state tables are exhausted packets start dropping. This is the case in every switch, too. It’s a common thing. Being able to increase this is a nice stop gap. It’s not a fatal flaw wrt to PF. Also for better or worse BSD being different is what makes it interesting. BSD devs and hackers are a fraction of what the Linux kernel and greater ecosystem have in terms of the all of K8s and other Linux foundation projects. But BSDs have been innovating within their community of hackers for years and they don’t need to just be a derivative of Linux. That being said the concepts of eBPF could be ported and the interface adopted could be interesting. If anyone pushed or funded that effort it might be the Netflix folks.

0dayz 3y ago
>Also for better or worse BSD being different is what makes it interesting. BSD devs and hackers are a fraction of what the Linux kernel and greater ecosystem have in terms of the all of K8s and other Linux foundation projects. But BSDs have been innovating within their community of hackers for years and they don’t need to just be a derivative of Linux. I disagree, you can still be unique while having interoperability with the mainstream. Just take a look at netbsd, sure it's all about ofc it runs netbsd, but it's hidden feature is trying to be interoperable.

tete 3y ago

tl;dr: I think eBPF is great and that there are many things to criticize about the BSDs, but I think the claims about innovations taking off and BSD developers not cooperating are baseless. I'm sorry. There's much to criticize the BSDs for, but compared to Linux a lack of innovation simply isn't among them. From containers to capabilities, from networking to storage, from event handling to audio (and I am talking about the kernel side of things here) Linux runs in circles, re-inventing half-baked solutions that becomes yet another deprecated, yet still supported API/syscall a few years in. Also on the note of corporation. There has been more than one event where corporation was the intention and some Linux guy posted on some public mailing list about the OpenBSD developers will be sued. And when it comes to user space the situation is even more clear. But then again one has to admit that there are philosophical clashes, especially when it comes to OpenBSD. If you look at FreeBSD there's a lot more interaction. See OpenZFS. Here FreeBSD decided to corporate. At the same time, even though that is user space, Wayland and other projects are defined as "for Linux". I believe in general there's a lot more cooperation than you think. It's just that devs aren't really much into making everything some public ceremony. If you share a common fields, you might go to common events or send an email, jump into an IRC, Discord, etc. Especially given the history regarding licenses. People - on both sides (if you can even call it that) - now behave properly and talk things out directly instead of having mud fights. And if you look at the OpenBSDs Innovation page on their website, compare the list of Programs and subsystems as well as the list of Projects maintained by OpenBSD developers with what people think is great software or with software that's on your system and you don't even think about cause it never ever made problems. And then you have things like sndio which I've seen shipped with more than one game on Steam, because it just works and everyone doing proper updates (Android, RPM, etc.) using bsdiff (granted, that one is in fact older). The main thing where the BSDs sometimes lag behind (with exceptions such as Apple's ARM processors, etc.) is supporting each and every device of hardware. However, one has to say that your Thinkpad has a better chance of working properly out of the box than any Linux distribution I ever encountered. And while that worked decades ago, I currently don't manage to have any system properly handling audio input/output states. It either switches around in terms of muting, or it forgets that the headphones were connected, outputs to the wrong place, etc. To be fair that also does seem a problem with some other OSs, but on OpenBSD it's always correct. I mention this because it's one example of hardware actually working, and not being wonky. And I don't have to constantly be scared that the next driver version breaks stuff, or that an API is deprecated. Yes, Linux is absolutely excellent on keeping compatibility, but the sad state is that you'll end up with 10 APIs with different parts not working properly. And don't get me started with epoll vs kqueue. It's one great example of what I mean by half-baked solutions. Or think about how hacky setuid for processes on multi-threaded processes on Linux is. Setting owners of a thread instead of of the whole process? Every other OS gets that one right, but on Linux even big projects like Go struggle: https://github.com/golang/go/issues/1435 https://github.com/golang/go/issues/1435 Btw: I say that at someone who is a huge fan of eBPF, even though I have to admit that it really is a double-edged sword. It's not one of these "this is at least better than not having it in all situations" things, even though some people sadly act like it. And one thing that is great about the BSDs at a community level is that they don't jump on every hype train. I think if they did they'd probably be dead by now, because they are smaller and so building something, changing the whole system to support it properly only for the next big thing replacing it three years later doesn't work for them. So that's where the being opinionated probably stems from. They very strongly go towards something they know will still be there and sensible in 5-10 years. You can read that in nearly all popular "critical of something" posts. It's always about wild unfounded claims or re-inventing something that didn't work out.

chasil 3y ago

On the other hand, pf is cross-platform, running in Solaris and FreeBSD. That carries some weight. I have seen the Linux kernel migrate from ipfwadm to ipchains to iptables to nftables, and this has involved occasional reworking of some simple firewall rules from time to time. On those later occasions, I did admire pf.

toast0 3y ago
pf may be on all those platforms, but pf rules are not cross-platform, because different platforms have different rule syntax and different capabilities.
keep_reading 3y ago
pf is in MacOS too