net.pf.request_maxcount: UNDESIRABLE_OID

[Chris]

On Fri, 21 Aug 2020 08:56:12 +0200 Kristof Provost kp at FreeBSD.org said

> On 21 Aug 2020, at 8:53, Chris wrote:
> > 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?
> >
> 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.
Good news!
> 
> I’ll try to do that today, after I fix my dev-VM.
Hope it turns out to be an easy fix for you.

Thanks for all your time!
> 
> Best regards,
> Kristof

--Chris