freebsd stable - Aug 2020 - net.pf.request_maxcount: UNDESIRABLE_OID

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

On Fri, 21 Aug 2020 08:33:16 +0200 Kristof Provost kp at 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