Update to PF from OpenBSD 6.5

[Kristof Provost]

On 20 Aug 2019, at 11:36, Tom Marcoen wrote:
> Hey all,
>
> I'm quite new to FreeBSD so appologies if this is a stupid question.
>
> Is there a good reason for not upgrading PF to the version from 
> OpenBSD
> 6.5?
There are several reasons why updating pf is a non-trivial problem.

 From an e-mail I sent on this subject in April:

It’s a good goal, but there are three major issues along the way to 
importing the latest OpenBSD version. (And I’m sure a whole bunch of 
smaller ones.)

Those are:

  - scalability
  - syntax
  - vimage

The scalability issue is the obvious difference: OpenBSD’s pf is still 
very much single-core oriented, whereas the FreeBSD pf version can cope 
with multiple cores (somewhat) and is significantly faster on multicore 
hardware. Our version is by no means perfect, but it’s much faster 
than OpenBSD’s version. Much of the imperfections we have now is there 
because pf was designed in a giant locked kernel in the first place. 
Multi-core scalability was not part of its original design.

Adopting OpenBSDs pf would mean redoing all of the locking work Gleb did 
years ago. Given the differences in OpenBSD’s pf (e.g. they keep 
states in a tree, not a hash table) it’s not a matter of replaying the 
previous work on a new pf version. This is a from the ground up 
introduction of fine grained locking in a code base that assumes a 
single giant lock. As I understand it the OpenBSD people are working on 
the problem as well, but I’ve not seen any diffs yet. If they’ve 
made significant progress we may be able to base our work on theirs.
I don’t think it’d be acceptable to not have this, as it’d mean a 
very large performance regression.

For reference, before I did the pfsync work we essentially had a 
single-threaded pf when pfsync was enabled. On my test hardware this 
meant a throughput of ~1.1Mpps, rather than the ~3.9Mpps without pfsync. 
I’d expect OpenBSDs pf to perform at around that ~1.1Mpps number 
without locking work.

The second issue is one of syntax, and that’s what I assume is the 
main reason people want OpenBSDs pf. We’re still on an older iteration 
of the pf syntax, but changing that would inevitably mean breaking old 
configurations. That might be acceptable on a major version update (i.e. 
going into 13), but would mean the new work could never be backported.
That’s probably the only way forward though. I’m playing with 
importing the ‘match’ keyword and not breaking the ‘scrub’ 
syntax at the same time, but it’s a non-trivial problem, and that’s 
only one of the steps along the way.

Finally there’s vimage. That’s a FreeBSD-only feature, so naturally 
OpenBSDs pf is not aware of this. I expect that to be relatively easy to 
add back in, but it’s another obstacle. As vimage is what lets us have 
the pf tests we’ve got now I’d be very reluctant to let it go. 
It’s a supported feature in 12.0, so users will start to rely on it as 
well.

TL;DR: It’s possible, but *hard*. Expect is to be many person-months 
of effort, and there’s no way it’s going to be a smooth ride.

One thing I’ve thought of trying, and that might be an interesting 
stepping stone, is to create a port (/usr/ports/net/opf or whatever) of 
OpenBSD’s pf. In that version it’d be acceptable to not fix any of 
the above issues. It’d still give users to option of getting the new 
syntax. I’d expect this to be a relatively straightforward exercise.
In principle there’s nothing to stop us from doing that same work in 
base, but we’re **NOT** going to import a fourth firewall. We’re 
just not.

> Currently it seems to be at the version from OpenBSD 4.1.
>
That’s so simplistic as to be outright wrong.
We’ve not done wholesale imports from OpenBSD in a long time, yes, but 
FreeBSD’s pf is maintained, and regularly gets new features and bug 
fixes. Fixes even flow in both directions between OpenBSD and FreeBSD.

Regards,
Kristof