Le 29/03/2019 à 22:10, Brian Buhrow a écrit :
... And, prey tell, why is it harder to maintain a modern version of PF than NPF? ...
It is about the _fourth_ time you ask this question, and for the fourth time I am going to provide the exact same answer. PF has a legacy design that makes it difficult to import in MP-safe kernels like NetBSD or FreeBSD. NPF is already MP-safe and well integrated in the NetBSD kernel, and that's why it is a lot easier to work on. Is it clear now, or do you want to ask a fifth time? Again, if it was as easy you as think it is, we woud likely have maintained it. The reality is that no one is willing to maintain PF.
At the risk of being extremely rude, although that is not my intention, if as much effort had been put into improving the functionality of NPF as has been put into the effort to get pf removed, I dare say, NPF would now be up to PF in functionality and the conversation would be easier to have.
If the effort hadn't been split on three firewalls in the last 10 years, but rather had been focused on only one, don't you think NPF would now be featureful? The fragmented effort that has gone into fixing here and there crazy bugs in PF and IPF, just because random people (like you) wanted their outdated firewall not to collapse, is precisely what has brought us to the current state, that is, three half-baked firewalls, none of which is 100% functional or featureful. I'm even talking from experience here; last year I was looking at network- related PRs, and I found a PR from 2010 where a guy had reported that a single TCP packet could crash the kernel under PF. It turned out that our version of PF had a signedness bug that could cause a length check to pass, which caused a fatal memory corruption. Checking the guy's github, he even had written in 2010 an exploit for it. So for 8 years, the vuln had been sitting in our Gnats with a public exploit, and strictly no one giving a fuck about it. I proceeded to write a reproducer, fix the vuln, then pull it up, then write a security advisory for it. All of that is an awful waste of time and energy, for everybody. Perpetuating this crazy status quo is not going to make the situation any better, it will just make us continue splitting efforts. If we already manage to go from three firewalls to only two, it's a good progress, and again, it reduces the maintenance burden on the kernel. In the case of PF, I've already said it in the internal discussion (but not on tech-kern), if we wanted to import a new version, it would likely be better to remove the one we have, and make a clean import from scratch. In any case, this proposal (about removing PF) is not illegitimate or stupid, and it makes sense, given the awful state of PF. If you want to use outdated firewalls that haven't received security fixes, you can as well follow the NetBSD-6 branch, or older.
And, once done, all those features would have to be maintained going forward,
No, NPF is homegrown, each feature added doesn't need to be regularly maintained, contrary to PF.
not to mention that there would be absolutely no testing outside of the NetBSD environment with NPF.
As a matter of fact this is incorrect, NPF works on Linux too, there have been tests/development made on CentOS. I also have a vague memory of NPF being embedded in DPDK. So no, NPF is definitely not NetBSD-specific, and has received testing outside.
