On Fri, 21 Aug 2020 08:56:12 +0200 Kristof Provost k...@freebsd.org said
On 21 Aug 2020, at 8:53, Chris wrote:
> On Fri, 21 Aug 2020 08:33:16 +0200 Kristof Provost k...@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
_______________________________________________
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
