Add FreeBSD PF Firewall to libbsd

[Christian Mauderer]

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.

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.

> 
>> - 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.

>> - 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.

>> - 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.

The plugin could be a solution to automate the process. But It would be
highly gcc specific. I think that manipulating the section names inside
the object file like suggested in the linked discussion would be a more
portable solution.

Kind Regards

Christian
-- 
--------------------------------------------
embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.