pf: Introduce a new vnet loader tunable net.pf.default_to_drop

[zlei]

Summary

7f7ef494f11d introduced a compile time option PF_DEFAULT_TO_DROP to make the pf(4) default rule to drop. While this change exposes a vnet loader tunable net.pf.default_to_drop so that users can change the default rule without re-compiling the pf(4) module.

MFC after: 2 weeks
Relnotes: yes

Test Plan

# kldload -nq pf
# kenv net.pf.default_to_drop=1
# jail -ic vnet persist
1
# jexec 1 sysctl net.pf.default_to_drop
net.pf.default_to_drop=1
# jexec 1 pfctl -e
# jexec 1 ping -c1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
ping: sendto: Permission denied

[kp]

That seems mostly reasonable. I wonder if it should be a tunable or a per-vnet sysctl. (The latter might also need a bit more work so the new setting is taken into account, perhaps when we load a new ruleset?)

My only other and more important concern is that PF_DEFAULT_TO_DROP is less tested, and I know of at least one bug related to it: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237477

We may also want to see if that new tunable should be documented in one of the pf man pages.

[zlei]

1. Make net.pf.default_to_drop a vnet loader tunable, this depends on D39638 and D40127
2. Update the man doc

[zlei]

In D39866#907517, @kp wrote:

That seems mostly reasonable. I wonder if it should be a tunable or a per-vnet sysctl. (The latter might also need a bit more work so the new setting is taken into account, perhaps when we load a new ruleset?)

It is now a vnet loader tunable.

My only other and more important concern is that PF_DEFAULT_TO_DROP is less tested, and I know of at least one bug related to it: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237477

That's true.

We may also want to see if that new tunable should be documented in one of the pf man pages.

Done!

[zlei]

Hi @kp, sorry for excessively late response.

Although I marked this feature depends on D39638 (in the stack) but it can still function without D39638.

The serials (D39638, D39852, D40127) of changes to elf / elf_object linker probably will NOT land in RELEASE/14 as it is now ALPHA and the KPI is frozen (IIUC).

Do you still support me commit this ?

[kp]

In D39866#945528, @zlei wrote:

Do you still support me commit this ?

Yeah, go ahead.

We still have the issue in 237477, but this won't make it any worse and would actually make it easier to write a test case for it.