Mailing List Archive: Sharing information for many rules using same module

Sharing information for many rules using same module

Aug 21, 2007, 7:54 AM

Post #1 of 3 (1901 views)

Hi.
I am working on simple netfilter match extension. It takes packet, analyzes it, and puts all info in structure. Then it looks at fields in matchinfo and decides if there is a match or not.
The problem is there will be probably many rules, and each time module will repeat the first part of process- where it would be enought to use same structure as in first rule. Is there any way to share info between rules?
I would also like to know if netfilter is processing packetss in pararell - or maybe i can be sure that until packet gets dropped or reaches NIC driver, netfilter wont start to process another one - that would solve my problem as i could simply keep that info inside matching module.
And BTW something offtopic - what is ( is there any) a good way to access userspace memory ( for example some process gets information from databases, and i need that data inside kernel ) from kernel module ?

Re: Sharing information for many rules using same module [ In reply to ]

jengelh at computergmbh

Aug 21, 2007, 8:15 AM

Post #2 of 3 (1803 views)

Permalink

On Aug 21 2007 16:54, Åukasz Stosik wrote:

>I am working on simple netfilter match extension. It takes packet,
>analyzes it, and puts all info in structure. Then it looks at fields
>in matchinfo and decides if there is a match or not.

>The problem is there will be probably many rules, and each time
>module will repeat the first part of process- where it would be
>enought to use same structure as in first rule. Is there any way to
>share info between rules?

Use a global variable (hash, linked list, whatever) in
xt_yourmatch.c.

>I would also like to know if netfilter is processing packetss in
>pararell - or maybe i can be sure that until packet gets dropped or
>reaches NIC driver, netfilter wont start to process another one -
>that would solve my problem as i could simply keep that info inside
>matching module.

You have to assume that it does things in parallel, and hence need
proper locking around your global variable.

>And BTW something offtopic - what is ( is there any) a good way to
>access userspace memory

copy_from_user(), but only if you have a user context. Which you
generally do not during input packet processing.

> ( for example some process gets information
>from databases, and i need that data inside kernel ) from kernel
>module ?

Think of something else.

Jan
--

Re: Sharing information for many rules using same module [ In reply to ]

azez at ufomechanic

Aug 31, 2007, 3:39 AM

Post #3 of 3 (1781 views)

Permalink

* Jan Engelhardt wrote, On 21/08/07 16:15:
> On Aug 21 2007 16:54, Åukasz Stosik wrote:
>
>> I am working on simple netfilter match extension. It takes packet,
>> analyzes it, and puts all info in structure. Then it looks at fields
>> in matchinfo and decides if there is a match or not.
>
>> The problem is there will be probably many rules, and each time
>> module will repeat the first part of process- where it would be
>> enought to use same structure as in first rule. Is there any way to
>> share info between rules?
>
> Use a global variable (hash, linked list, whatever) in
> xt_yourmatch.c.

Unless the information is specific to the packet (skb) or flow
(conntrack) in which case you could consider extending the skb or
conntrack structs so you can store that information there.

Jan's answer is a neccessity if you are correlating information over
multiple flows, and is perhaps a good idea anyway to avoid conntrack/skb
bloat at the expense of some efficiency.

However you may want to look at the new ct_extend which could help here.

>> I would also like to know if netfilter is processing packetss in
>> pararell - or maybe i can be sure that until packet gets dropped or
>> reaches NIC driver, netfilter wont start to process another one -
>> that would solve my problem as i could simply keep that info inside
>> matching module.
>
> You have to assume that it does things in parallel, and hence need
> proper locking around your global variable.

And possibly also out-of-order in some cases.

Sam