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
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. I?ll try to do that today, after I fix my dev-VM. Best regards, Kristof