bpf filter : support for vlan tag

Hi :

I was looking at the kernel side implementation of the BPF filter. I
do not see any code that supports filtering of packets based on
provided vlan tag information from the skbuff. This will make it
impossible to provide any filter to tcpdump that will filter packets
based on the tag information if libpcap uses the kernel filter.

Any help will be much appreciated.

Cheers,
ani

On Mon, 2012-10-15 at 19:10 -0700, Ani Sinha wrote:

Hi :

I was looking at the kernel side implementation of the BPF filter. I
do not see any code that supports filtering of packets based on
provided vlan tag information from the skbuff. This will make it
impossible to provide any filter to tcpdump that will filter packets
based on the tag information if libpcap uses the kernel filter.

Any help will be much appreciated.

Right, we need a basic support, using a new ancillary definition.

Is the following patch enough to address your need, or do you also need
access to vlan_tx_tag_present() ?

diff --git a/include/linux/filter.h b/include/linux/filter.h
index 24d251f..0218e41 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h

@@ -123,6 +123,7 @@ enum {
 	BPF_S_ANC_CPU,
 	BPF_S_ANC_ALU_XOR_X,
 	BPF_S_ANC_SECCOMP_LD_W,
+	BPF_S_ANC_VLAN_TAG,
 };
 
 #endif /* __LINUX_FILTER_H__ */

diff --git a/net/core/filter.c b/net/core/filter.c
index 3d92ebb..de4a5dc 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c

@@ -341,6 +341,9 @@ load_b:
 		case BPF_S_ANC_CPU:
 			A = raw_smp_processor_id();
 			continue;
+		case BPF_S_ANC_VLAN_TAG:
+			A = vlan_tx_tag_get(skb);
+			continue;
 		case BPF_S_ANC_NLATTR: {
 			struct nlattr *nla;
 

@@ -600,6 +603,7 @@ int sk_chk_filter(struct sock_filter *filter, unsigned int flen)
 			ANCILLARY(RXHASH);
 			ANCILLARY(CPU);
 			ANCILLARY(ALU_XOR_X);
+			ANCILLARY(VLAN_TAG);
 			}
 		}
 		ftest->code = code;

On Tue, Oct 16, 2012 at 8:46 AM, Eric Dumazet [off-list ref] wrote:

On Mon, 2012-10-15 at 19:10 -0700, Ani Sinha wrote:

quoted

Hi :

I was looking at the kernel side implementation of the BPF filter. I
do not see any code that supports filtering of packets based on
provided vlan tag information from the skbuff. This will make it
impossible to provide any filter to tcpdump that will filter packets
based on the tag information if libpcap uses the kernel filter.

Any help will be much appreciated.

Right, we need a basic support, using a new ancillary definition.

Is the following patch enough to address your need, or do you also need
access to vlan_tx_tag_present() ?

I like this patch, it's especially useful to speed up processing for
packet analyzers. vlan_tx_tag_present() might also be good to have if
this doesn't waste to much room for future ancillary operations.

On Tue, 2012-10-16 at 13:00 +0200, Daniel Borkmann wrote:

On Tue, Oct 16, 2012 at 8:46 AM, Eric Dumazet [off-list ref] wrote:

quoted

On Mon, 2012-10-15 at 19:10 -0700, Ani Sinha wrote:

quoted

Hi :

I was looking at the kernel side implementation of the BPF filter. I
do not see any code that supports filtering of packets based on
provided vlan tag information from the skbuff. This will make it
impossible to provide any filter to tcpdump that will filter packets
based on the tag information if libpcap uses the kernel filter.

Any help will be much appreciated.

Right, we need a basic support, using a new ancillary definition.

Is the following patch enough to address your need, or do you also need
access to vlan_tx_tag_present() ?

I like this patch, it's especially useful to speed up processing for
packet analyzers. vlan_tx_tag_present() might also be good to have if
this doesn't waste to much room for future ancillary operations.

There is plenty of room in ancillary space

Note that if speed is needed, we also want to update various JIT
implementations.

diff --git a/include/linux/filter.h b/include/linux/filter.h
index 24d251f..c9f0005 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h

@@ -123,6 +123,8 @@ enum {
 	BPF_S_ANC_CPU,
 	BPF_S_ANC_ALU_XOR_X,
 	BPF_S_ANC_SECCOMP_LD_W,
+	BPF_S_ANC_VLAN_TAG,
+	BPF_S_ANC_VLAN_TAG_PRESENT,
 };
 
 #endif /* __LINUX_FILTER_H__ */

diff --git a/include/uapi/linux/filter.h b/include/uapi/linux/filter.h
index 3d79224..9cfde69 100644
--- a/include/uapi/linux/filter.h
+++ b/include/uapi/linux/filter.h

@@ -127,7 +127,9 @@ struct sock_fprog {	/* Required for SO_ATTACH_FILTER. */
 #define SKF_AD_RXHASH	32
 #define SKF_AD_CPU	36
 #define SKF_AD_ALU_XOR_X	40
-#define SKF_AD_MAX	44
+#define SKF_AD_VLAN_TAG	44
+#define SKF_AD_VLAN_TAG_PRESENT 48
+#define SKF_AD_MAX	52
 #define SKF_NET_OFF   (-0x100000)
 #define SKF_LL_OFF    (-0x200000)
 

diff --git a/net/core/filter.c b/net/core/filter.c
index 3d92ebb..5a114d4 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c

@@ -39,6 +39,7 @@
 #include <linux/reciprocal_div.h>
 #include <linux/ratelimit.h>
 #include <linux/seccomp.h>
+#include <linux/if_vlan.h>
 
 /* No hurry in this branch
  *

@@ -341,6 +342,12 @@ load_b:
 		case BPF_S_ANC_CPU:
 			A = raw_smp_processor_id();
 			continue;
+		case BPF_S_ANC_VLAN_TAG:
+			A = vlan_tx_tag_get(skb);
+			continue;
+		case BPF_S_ANC_VLAN_TAG_PRESENT:
+			A = !!vlan_tx_tag_present(skb);
+			continue;
 		case BPF_S_ANC_NLATTR: {
 			struct nlattr *nla;
 

@@ -600,6 +607,8 @@ int sk_chk_filter(struct sock_filter *filter, unsigned int flen)
 			ANCILLARY(RXHASH);
 			ANCILLARY(CPU);
 			ANCILLARY(ALU_XOR_X);
+			ANCILLARY(VLAN_TAG);
+			ANCILLARY(VLAN_TAG_PRESENT);
 			}
 		}
 		ftest->code = code;

On Tue, Oct 16, 2012 at 1:28 PM, Eric Dumazet [off-list ref] wrote:

On Tue, 2012-10-16 at 13:00 +0200, Daniel Borkmann wrote:

quoted

On Tue, Oct 16, 2012 at 8:46 AM, Eric Dumazet [off-list ref] wrote:

quoted

On Mon, 2012-10-15 at 19:10 -0700, Ani Sinha wrote:

quoted

Hi :

I was looking at the kernel side implementation of the BPF filter. I
do not see any code that supports filtering of packets based on
provided vlan tag information from the skbuff. This will make it
impossible to provide any filter to tcpdump that will filter packets
based on the tag information if libpcap uses the kernel filter.

Any help will be much appreciated.

Right, we need a basic support, using a new ancillary definition.

Is the following patch enough to address your need, or do you also need
access to vlan_tx_tag_present() ?

I like this patch, it's especially useful to speed up processing for
packet analyzers. vlan_tx_tag_present() might also be good to have if
this doesn't waste to much room for future ancillary operations.

There is plenty of room in ancillary space

Note that if speed is needed, we also want to update various JIT
implementations.

Thanks for the patch. My kernel was still compiling and mutt was
already open for a submission on the vlan_tx_tag_present() operation.
:-)

On Tue, Oct 16, 2012 at 4:28 AM, Eric Dumazet [off-list ref] wrote:

Note that if speed is needed, we also want to update various JIT
implementations.

Thanks Eric for the patch. I will take a look at it. We also need the
JIT module support as well (for x86 and x86_64) since we use the JIT
filter. I have been studying the various instructions and how other
filter operations have been implemented using them but it will take me
a little bit more time to understand the code.

Cheers,
ani

On Tue, 2012-10-16 at 09:54 -0700, Ani Sinha wrote:

On Tue, Oct 16, 2012 at 4:28 AM, Eric Dumazet [off-list ref] wrote:

quoted

Note that if speed is needed, we also want to update various JIT
implementations.

Thanks Eric for the patch. I will take a look at it. We also need the
JIT module support as well (for x86 and x86_64) since we use the JIT
filter. I have been studying the various instructions and how other
filter operations have been implemented using them but it will take me
a little bit more time to understand the code.

Dont worry, I'll do the JIT part (but only for x86_64, we dont support
i386)

how about this?

On Tue, Oct 16, 2012 at 4:28 AM, Eric Dumazet [off-list ref] wrote:

+               case BPF_S_ANC_VLAN_TAG:
+                       if (!vlan_tx_tag_present(skb)) {
+                               return 0;
+                       }
+                       A = vlan_tx_tag_get(skb);
+                       continue;
+               case BPF_S_ANC_VLAN_TAG_PRESENT :
+                       A = !! vlan_tx_tag_present(skb);
+                       continue;

Now, is there any particular reason we are not using clan_get_tag() api?

Thanks
ani

On Fri, Oct 19, 2012 at 8:32 PM, Ani Sinha [off-list ref] wrote:

I didn't look into the code, but I assume that if no vlan is present,
then vlan_tx_tag_get might return 0 anyway. Also, your return is
simply wrong, since then after this instruction you leave the *whole*
BPF machine ignoring the rest of the filter program to process ...

+               case BPF_S_ANC_VLAN_TAG_PRESENT :
+                       A = !! vlan_tx_tag_present(skb);
+                       continue;

Now, is there any particular reason we are not using clan_get_tag() api?

Thanks
ani

On Fri, Oct 19, 2012 at 1:53 PM, Daniel Borkmann
[off-list ref] wrote:

On Fri, Oct 19, 2012 at 8:32 PM, Ani Sinha [off-list ref] wrote:

quoted

how about this?

On Tue, Oct 16, 2012 at 4:28 AM, Eric Dumazet [off-list ref] wrote:

quoted

@@ -341,6 +342,12 @@ load_b:
                case BPF_S_ANC_CPU:
                        A = raw_smp_processor_id();
                        continue;
+               case BPF_S_ANC_VLAN_TAG:
+                       A = vlan_tx_tag_get(skb);
+                       continue;
+               case BPF_S_ANC_VLAN_TAG_PRESENT:
+                       A = !!vlan_tx_tag_present(skb);
+                       continue;
                case BPF_S_ANC_NLATTR: {
                        struct nlattr *nla;

+               case BPF_S_ANC_VLAN_TAG:
+                       if (!vlan_tx_tag_present(skb)) {
+                               return 0;
+                       }
+                       A = vlan_tx_tag_get(skb);
+                       continue;

I didn't look into the code, but I assume that if no vlan is present,
then vlan_tx_tag_get might return 0 anyway.

This might not be true all the time. So it's always safe to do this
check before returning the VLANID and throw some kind of error if the
vlan ID is not set.


 Also, your return is

simply wrong, since then after this instruction you leave the *whole*
BPF machine ignoring the rest of the filter program to process ...

I had done that because I can see in other parts of that state machine
that in error condition the code simply stops processing the packet. I
am not sure how else to handle the error case.

Ani

On Fri, Oct 19, 2012 at 11:02 PM, Ani Sinha [off-list ref] wrote:

On Fri, Oct 19, 2012 at 1:53 PM, Daniel Borkmann
[off-list ref] wrote:

quoted

On Fri, Oct 19, 2012 at 8:32 PM, Ani Sinha [off-list ref] wrote:

quoted

how about this?

On Tue, Oct 16, 2012 at 4:28 AM, Eric Dumazet [off-list ref] wrote:

quoted

@@ -341,6 +342,12 @@ load_b:
                case BPF_S_ANC_CPU:
                        A = raw_smp_processor_id();
                        continue;
+               case BPF_S_ANC_VLAN_TAG:
+                       A = vlan_tx_tag_get(skb);
+                       continue;
+               case BPF_S_ANC_VLAN_TAG_PRESENT:
+                       A = !!vlan_tx_tag_present(skb);
+                       continue;
                case BPF_S_ANC_NLATTR: {
                        struct nlattr *nla;

+               case BPF_S_ANC_VLAN_TAG:
+                       if (!vlan_tx_tag_present(skb)) {
+                               return 0;
+                       }
+                       A = vlan_tx_tag_get(skb);
+                       continue;

I didn't look into the code, but I assume that if no vlan is present,
then vlan_tx_tag_get might return 0 anyway.

This might not be true all the time. So it's always safe to do this
check before returning the VLANID and throw some kind of error if the
vlan ID is not set.

But wasn't this the reason why Eric added BPF_S_ANC_VLAN_TAG_PRESENT ?
Or is your objection performance related?

 Also, your return is

quoted

simply wrong, since then after this instruction you leave the *whole*
BPF machine ignoring the rest of the filter program to process ...

I had done that because I can see in other parts of that state machine
that in error condition the code simply stops processing the packet. I
am not sure how else to handle the error case.

See comment above. In my opinion the other cases are more severe like
divide by zero and the like, but okay ..

On Tue, Oct 16, 2012 at 1:28 PM, Eric Dumazet [off-list ref] wrote:

On Tue, 2012-10-16 at 13:00 +0200, Daniel Borkmann wrote:

quoted

On Tue, Oct 16, 2012 at 8:46 AM, Eric Dumazet [off-list ref] wrote:

quoted

On Mon, 2012-10-15 at 19:10 -0700, Ani Sinha wrote:

quoted

I was looking at the kernel side implementation of the BPF filter. I
do not see any code that supports filtering of packets based on
provided vlan tag information from the skbuff. This will make it
impossible to provide any filter to tcpdump that will filter packets
based on the tag information if libpcap uses the kernel filter.

Any help will be much appreciated.

Right, we need a basic support, using a new ancillary definition.

Is the following patch enough to address your need, or do you also need
access to vlan_tx_tag_present() ?

I like this patch, it's especially useful to speed up processing for
packet analyzers. vlan_tx_tag_present() might also be good to have if
this doesn't waste to much room for future ancillary operations.

There is plenty of room in ancillary space

Note that if speed is needed, we also want to update various JIT
implementations.

Eric, can you submit this patch to net-next if there are no objections
from your side regarding the follow-up comments? Big thanks.

On Fri, 2012-10-26 at 10:05 +0200, Daniel Borkmann wrote:

Eric, can you submit this patch to net-next if there are no objections
from your side regarding the follow-up comments? Big thanks.

Yep, I am preparing two patches :

1) Generic support

2) x86_64 jit support