Date: Fri, 21 Aug 2020 08:56:12 +0200 From: "Kristof Provost" <kp@FreeBSD.org> To: Chris <bsd-lists@BSDforge.com> Cc: freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: net.pf.request_maxcount: UNDESIRABLE_OID Message-ID: <A517F339-2E65-48BD-84E9-46208DFDB1E8@FreeBSD.org> In-Reply-To: <d99bf256afd730da3ad844206f818be6@udns.ultimatedns.net> References: <d99bf256afd730da3ad844206f818be6@udns.ultimatedns.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. I’ll try to do that today, after I fix my dev-VM. Best regards, Kristof
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A517F339-2E65-48BD-84E9-46208DFDB1E8>