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
_______________________________________________
freebsd-pf@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
