Date: Fri, 21 Aug 2020 10:01:51 -0700 From: Chris <bsd-lists@BSDforge.com> To: freebsd-stable <freebsd-stable@freebsd.org> Cc: Kristof Provost <kp@FreeBSD.org> Subject: Re: net.pf.request_maxcount: UNDESIRABLE_OID Message-ID: <3c0d5c4fea1d4eb71f68a1837a8a0c4c@udns.ultimatedns.net> In-Reply-To: <A517F339-2E65-48BD-84E9-46208DFDB1E8@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
On Fri, 21 Aug 2020 08:56:12 +0200 Kristof Provost kp@FreeBSD.org said > On 21 Aug 2020, at 8:53, Chris wrote: > > On Fri, 21 Aug 2020 08:33:16 +0200 Kristof Provost kp@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 --Chrishome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3c0d5c4fea1d4eb71f68a1837a8a0c4c>