Add FreeBSD PF Firewall to libbsd

Wed Aug 3 06:15:16 UTC 2016

Am 03.08.2016 um 08:02 schrieb 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?
> 

Basically it boils down to the following: Currently I use an
__attribute__ on every variable that has to be initialized. That makes
updates a little more difficult because we would have to look out for
changed variables. In addition it is difficult for function static
variables.

A solution that would be simpler to maintain would be to manipulate the
object file. I would use objcopy to rename all sections with initialized
variables to put them into the linker set. This would be a little less
obvious if you read only the c code but it would solve both problems
mentioned above. But it makes it necessary that the build system adds
the object file manipulation step before it links the application. That
is the point where I'm currently stuck.

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.