Add FreeBSD PF Firewall to libbsd

[Chris Johns]

On 03/08/2016 15:56, Christian Mauderer wrote:
> Am 03.08.2016 um 02:54 schrieb Chris Johns:
>> On 02/08/2016 21:27, Christian Mauderer wrote:
>>> - A basic support for the FreeBSD cdev subsystem. This subsystem uses
>>> devfs which I implementation based on the RTEMS IMFS.
>>
>> Is this automatically included and what can we configure and control?
>
> A lot of drivers in BSD use the cdev subsystem to create their /dev/xyz
> nodes. Till now we had only a very minimalistic implementation (enough
> to let everything link without errors) and a lot of workarounds to
> somehow avoid the usage of the /dev/xyz nodes or to create them inside
> the driver. One such example is freebsd/sys/net/bpf.c
>
> My implementation replaces the "let me just link" version. Therefore it
> is automatically included like the previous version. I don't think that
> it would be useful to switch it off.

I agree. This is a nice change to have.

> Making it optional means that we would have to offer a selection between
> the old "let me just link" version and the new one. That could lead to a
> lot of problems with dependencies. Some drivers might would rely on the
> one or the other implementation.

I was only asking to see if there was something we need to manage.

>
>>
>>> - The PF modules can now be linked by using the SYSINIT_NEED_FIREWALL_PF
>>> and SYSINIT_NEED_FIREWALL_PFLOG configuration macros.
>>
>> Can you please add RTEMS_BSD_CONFIG_FIREWALL_PF and
>> RTEMS_BSD_CONFIG_FIREWALL_PFLOG to rtems-bsd-config.h.
>>
>> This is the user interface and what I intend to document and so what we
>> need to maintain and keep working into the future.
>>
>
> I'll look into this.
>

Thanks.

>>> - I ported the control tool for the firewall (pfctl) to libbsd.
>>>
>>> - I added a chapter on how to use PF to libbsd.txt. An example can be
>>> found in the pf01 test.
>>
>> Is there support for rc.conf(5)
>> (https://www.freebsd.org/cgi/man.cgi?rc.conf%285%29) in the change?
>>
>> It would be nice to support ipfilter_enable, ipfilter_rules,
>> ipv6_ipfilter_rules, and ipfilter_flags. I think ipfilter_program can be
>> silently ignored.
>>
>> I would like LibBSD's user interface to be rc.conf(5) as standard and my
>> hope is the support work I have done for rc.conf makes it easy to add
>> support. I am happy for other ways to configure to be present and the
>> tests tend to need this however users who depend on those interface
>> maybe disappointed if those interfaces change or break.
>>
>
> I haven't added the support. But I'll try to create a patch in the next
> few days.
>

Great. If there is something you need in the rc.conf support please let 
me know.

>>> - The method that I used for the pfctl port slightly improves the
>>> approach that is currently used for most other user space tools. A basic
>>> guide how to port a tool using the new method can be found in the
>>> libbsd.txt in the chapter "Porting of user space utilities".
>>
>> This is a nice change.
>>
>>>
>>> Basically I made two changes to the current approach:
>>>
>>> 1. I used a new method to handle the global variables. Basically they
>>> are put into a linker section that is saved before the program call and
>>> restored afterwards.
>>>
>>> 2. Beneath that I added some wrappers to calls like open / close or
>>> malloc / free. These wrappers create a list of opened files and
>>> allocated resources. After the program main function has finished, the
>>> resources are closed / freed.
>>>
>>> Please note: The method described in 1. makes it necessary to pull
>>> function static variables out of their functions. This works but is not
>>> really an optimal solution. The FreeBSD people are not really happy with
>>> this kind of patches. Currently I'm trying to evaluate an alternative
>>> solution (manipulating the object files to put the variables into a
>>> section) in this thread:
>>>
>>> https://lists.rtems.org/pipermail/devel/2016-August/015749.html
>>>
>>
>> I have wondered about using libdl as a way to wrap and limit scope and
>> while it is a nice idea ARM needs veneers to be fully supported. I have
>> also wondered if a GCC plugin could be used when building these specific
>> files to handle the linker attributes automatically. There is a nice
>> Python plugin framework for GCC which may help make this easier.
>>
>
> I think libdl is currently only available for some platforms? So my
> suggested solution currently targets a wider range of plattforms without
> the necessity to first port libdl.

Yes and it complicates the build because of symbols and this extends the 
reach of what is needed into the user's build systems.

> The plugin could be a solution to automate the process. But It would be
> highly gcc specific.

Yes.

> I think that manipulating the section names inside
> the object file like suggested in the linked discussion would be a more
> portable solution.

I did not pick this up when I read the thread. What is being suggested?

Chris