[PATCH] multiple instances of ipfw(4)

[Ermal Luçi]

On Mon, Jun 10, 2013 at 5:01 PM, Luigi Rizzo <rizzo at iet.unipi.it> wrote:

>
>
>
> On Mon, Jun 10, 2013 at 3:30 PM, Ermal Luçi <eri at freebsd.org> wrote:
>
>> Hello,
>>
>> reviving this old thread since i had time to bring the patch to FreeBSD 10
>> and unified the whole controlling under ipfw(8) binary.
>>
>> For reminder, the patch located at [1] provides multiple instances for
>> ipfw(4).
>> Basically you can control which interfaces belong to which context/ruleset
>> to make maintaining easier.
>>
>>
> ...
>
>
>
>> Any objections on pushing this into FreeBSD?
>>
>>
>> [1]
>>
>> https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/CP_multi_instance_ipfw.diff
>>
>>
>>
>
> if i understand well, this has no runtime overhead as the ifp has
> the index of the context it refers to ?
> Or you need an additional IPFW_CTX_RLOCK() ?
>

Theoretically you would need for correctness the read lock.
It has never been hit in pfSense hence no further investigation on it has
been done.
It can be made even a read mostly lock or to prevent the race the  write
lock
of the pfil hooks so no packets are passed through?!




>
> Comments on the control/config path:
> - in ipfw_ctl(), handling IP_FW_CTX_GET i am worried that you might
>   overflow the temporary buffer when building the list. You compute
>   the length under rlock, release the lock, malloc(), then fill the
>   list without checking if the total size is still correct.
>   This kind of code is terribly boring to write, but essentially
>   you need a bound check in the second loop and possibly
>   retry if you notice that you need more memory.
>   "ipfw show" addresses the problem by failing and requesting the
>   user application to pass a larger buffer.
>

Yeah that probably can be fixed.
During implementation it was considered enough rare operation to not
justify further thought.



>
> - similarly, how do you guarantee that deleting a context while
>   a packet is under processing does not cause dereferencing a
>   NULL pointer ?
>

Presently, none, but as i said during instance/context operation a write
lock on the pfil hook can be taken?
That should prevent the issue altogether and remove the requirement of
having to read lock the fast path.

If you agree with the above i can redo the patch again with the above
changes for review?


> cheers
> luigi
>
>  while
>> --
>> Ermal
>>
>> _______________________________________________
>> freebsd-net at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>>
>
>
>
> --
> -----------------------------------------+-------------------------------
>  Prof. Luigi RIZZO, rizzo at iet.unipi.it  . Dip. di Ing. dell'Informazione
>  http://www.iet.unipi.it/~luigi/        . Universita` di Pisa
>  TEL      +39-050-2211611               . via Diotisalvi 2
>  Mobile   +39-338-6809875               . 56122 PISA (Italy)
> -----------------------------------------+-------------------------------
>



-- 
Ermal