Hi Chris,
On 21 Aug 2020, at 2:40, Chris wrote:
We've been developing an appliance/server based on FreeBSD &&
pf(4). We started some time ago, and have been using a very
early version of 12. We're now collecting some 20,000,000
IP's /mos. So we're satisfied we're close to releasing. As
such, we needed to bring the release up to a supported
(freebsd) version (12-STABLE). We would have done so sooner.
But we need a stable (unchanging) testbed to evaluate what
we're working on.
We built and deployed a copy of 12-STABLE @r363918 that
contained our work with pf(4). Booting into it failed
unexpectedly with: cannot define table nets: too many
elements. Consider increasing net.pf.request_maxcount.
pfctl: Syntax error in config file: pf rules not loaded
OK this didn't happen on our testbed prior to the upgrade
with a combined count of ~97,000,900 IPs. In fact the OID
mentioned didn't exist.
For reference; our testbed provides DNS, www, mail for
~60 domains/hosts, as well as our pf(4) testing. We can
happily load our tables, and run these services w/8Gb
RAM.
This OID is more a problem than a savior. Why not simply
return ENOMEM?
To quote the commit message:
pf ioctls frequently take a variable number of elements as
argument. This can
potentially allow users to request very large allocations. These
will fail,
but even a failing M_NOWAIT might tie up resources and result in
concurrent
M_WAITOK allocations entering vm_wait and inducing reclamation of
caches.
Limit these ioctls to what should be a reasonable value, but allow
users to
tune it should they need to.
Now that pf can be used in vnet jails there’s a possibility of an
attacker using pf to deny service to other jails (or the host) by
exhausting memory. Imposing limits on pf request sizes mitigates this.
Isn't that what it used to do? pf.conf(5)
already facilitates thresholds, and they aren't _read
only_. Is there any way to turn this OID off; like using
a -1 value? Or will we need to simply back out the commit?
You can functionally disable it by setting a very large value. Try
setting 4294967295.
Best regards,
Kristof
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[email protected]"
