Porting pf from current OpenBSD to FreeBSD

[Kristof Provost]

On 16 Jan 2020, at 16:25, Алексей Прокопчук wrote:
> Now I'm trying to port the current pf from OpenBSD to current FreeBSD. 
> As a separate module this time, without any changes in the FreeBSD 
> kernel code.
>
That’s one of the better ways of trying to update our pf, yes.
I wrote a more extensive e-mail about this a while ago 
(https://lists.freebsd.org/pipermail/freebsd-pf/2019-April/009094.html), 
but briefly, there are three main areas of concern for a pf update.

  - performance: OpenBSD’s version is still limited to running on one 
core at a time.
  - vnet: OpenBSD has no direct equivalent
  - syntax differences would break existing rulesets

The last one of those is not a concern for your project right now.
VNET support is also optional, and all in all relatively straightforward 
to add afterwards.
The performance aspect of it isI’d worry about that only once you’ve 
gotten an OpenBSD pf working though. Many users will be satisfied with 
the performance of OpenBSD’s version.

When we’ve vaguely discussed this the suggestion was to treat this as 
a port, rather than as something that’d go into the base system. (We 
don’t want to add a fourth firewall, after all!). Still, that 
doesn’t affect this project too much.

> There are quite lot of inconsistencies - counters, tasks, crypto, 
> routing domains, mbuf, inpcb and others.
> In your opinion, what is the best way to solve the inconsistencies 
> with the current kernel?
>
That is an excellent question I do not have an immediate answer to.

> In case of inpcb I've created a structure containing the inpcb itself 
> and additional members, which are OpenBSD - specific.

My recollection is that we really only need the inpcb for the user 
matching code. For a first version you might be able to get away with 
just disabling that feature. In any case, I don’t expect we use many 
fields from the inpcb.

> In case of routing domains I've decided to always use the default 
> value 0 and make a function stub rtable_l2(), which returns 0 in all 
> cases.

A good initial shortcut. I’m not familiar enough with rtables to say 
for sure, but aren’t they somewhat comparable to our fibs?

> In case of the tasks I intend to use tasqueue "swi" for the enqueue 
> task.
>
Yeah, that’s what the FreeBSD pf version does too.

> I have almost no experience in the development of the FreeBSD kernel, 
> perhaps you could give me the cue as to where I'm making mistakes.
>
Do you have an in-progress tree somewhere?

Best regards,
Kristof