Add FreeBSD PF Firewall to libbsd

[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?

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

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

Chris