Re: Removing PF

[Maxime Villard <max%m00nbsd.net@localhost>]

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.