Date: Fri, 21 Aug 2020 08:33:16 +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: <7EF94FEA-90A0-413A-8EB5-FB2FD53B1C6F@FreeBSD.org> In-Reply-To: <54a0a1c4da6d5add83ecdf2668cf2f7b@udns.ultimatedns.net> References: <54a0a1c4da6d5add83ecdf2668cf2f7b@udns.ultimatedns.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
From owner-freebsd-stable@freebsd.org Fri Aug 21 06:53:26 2020
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mailman.nyi.freebsd.org (Postfix) with ESMTP id A800A3B55ED
for <freebsd-stable@mailman.nyi.freebsd.org>;
Fri, 21 Aug 2020 06:53:26 +0000 (UTC)
(envelope-from bsd-lists@BSDforge.com)
Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com
[24.113.41.81])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "ultimatedns.net",
Issuer "Let's Encrypt Authority X3" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4BXsft1CjTz4WwY;
Fri, 21 Aug 2020 06:53:25 +0000 (UTC)
(envelope-from bsd-lists@BSDforge.com)
Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1])
by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 07L6rLCS052408
(version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO);
Thu, 20 Aug 2020 23:53:27 -0700 (PDT)
(envelope-from bsd-lists@BSDforge.com)
X-Mailer: Cypht
MIME-Version: 1.0
Cc: Kristof Provost <kp@FreeBSD.org>
In-Reply-To: <7EF94FEA-90A0-413A-8EB5-FB2FD53B1C6F@FreeBSD.org>
From: Chris <bsd-lists@BSDforge.com>
Reply-To: bsd-lists@BSDforge.com
To: freebsd-stable <freebsd-stable@freebsd.org>
Subject: Re: net.pf.request_maxcount: UNDESIRABLE_OID
Date: Thu, 20 Aug 2020 23:53:27 -0700
Message-Id: <d99bf256afd730da3ad844206f818be6@udns.ultimatedns.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Rspamd-Queue-Id: 4BXsft1CjTz4WwY
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
none
X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[];
ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.33
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>;
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Aug 2020 06:53:26 -0000
On Fri, 21 Aug 2020 08:33:16 +0200 Kristof Provost kp@FreeBSD=2Eorg said
> Hi Chris,
Hello, Kristof=2E Thanks for the reply=2E
Nice name BTW=2E ;-)
>=20
> On 21 Aug 2020, at 2:40, Chris wrote:
> > We've been developing an appliance/server based on FreeBSD &&
> > pf(4)=2E We started some time ago, and have been using a very
> > early version of 12=2E We're now collecting some 20,000,000
> > IP's /mos=2E So we're satisfied we're close to releasing=2E As
> > such, we needed to bring the release up to a supported
> > (freebsd) version (12-STABLE)=2E We would have done so sooner=2E
> > But we need a stable (unchanging) testbed to evaluate what
> > we're working on=2E
> > We built and deployed a copy of 12-STABLE @r363918 that
> > contained our work with pf(4)=2E Booting into it failed
> > unexpectedly with: cannot define table nets: too many
> > elements=2E Consider increasing net=2Epf=2Erequest_maxcount=2E
> > 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=2E In fact the OID
> > mentioned didn't exist=2E
> > For reference; our testbed provides DNS, www, mail for
> > ~60 domains/hosts, as well as our pf(4) testing=2E We can
> > happily load our tables, and run these services w/8Gb
> > RAM=2E
> > This OID is more a problem than a savior=2E Why not simply
> > return ENOMEM?
> >
> To quote the commit message:
>=20
> pf ioctls frequently take a variable number of elements as=20
> argument=2E This can
> potentially allow users to request very large allocations=2E These=20
> will fail,
> but even a failing M_NOWAIT might tie up resources and result in=20
> concurrent
> M_WAITOK allocations entering vm_wait and inducing reclamation of=20
> caches=2E
>=20
> Limit these ioctls to what should be a reasonable value, but allow=20
> users to
> tune it should they need to=2E
>=20
> Now that pf can be used in vnet jails there=E2=80=99s a possibility of an=
=20
> attacker using pf to deny service to other jails (or the host) by=20
> exhausting memory=2E Imposing limits on pf request sizes mitigates this=2E
Hadn't considered vnet=2E Thanks for mentioning it=2E
But why must it be a read-only OID?
>=20
> > Isn't that what it used to do? pf=2Econf(5)
> > already facilitates thresholds, and they aren't _read
> > only_=2E 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=2E Try=20
> setting 4294967295=2E
Thanks=2E When I was confronted with the message=2E I simply chose an
arbitrarily high number of 800000000=2E Which allowed the tables to load=2E
But I felt I should look closer into this for a better understanding=2E :-)
Thank you very much for taking the time to reply!
>=20
> Best regards,
> Kristof
--Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7EF94FEA-90A0-413A-8EB5-FB2FD53B1C6F>