On 21 Aug 2020, at 8:53, Chris wrote:
On Fri, 21 Aug 2020 08:33:16 +0200 Kristof Provost [email protected] 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?
It doesn’t have to be, and in CURRENT it’s not:
https://svnweb.freebsd.org/base?view=revision&revision=355744
That hasn’t been MFC’d for the excellent reason that I forgot.
I’ll try to do that today, after I fix my dev-VM.
Best regards,
Kristof
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[email protected]"
