On Fri, 21 Aug 2020 08:33:16 +0200 Kristof Provost k...@freebsd.org said
Hi Chris,
Hello, Kristof. Thanks for the reply.
Nice name BTW. ;-)
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.
Hadn't considered vnet. Thanks for mentioning it.
But why must it be a read-only OID?
> 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.
Thanks. When I was confronted with the message. I simply chose an
arbitrarily high number of 800000000. Which allowed the tables to load.
But I felt I should look closer into this for a better understanding. :-)
Thank you very much for taking the time to reply!
Best regards,
Kristof
--Chris
_______________________________________________
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
