Skip to contentSkip to conversation

sk-filter: Add ability to get socket filter program

PATCH In review Pavel Emelyanov 3 participants 4 messages Oct 26, 2012 – Oct 31, 2012

Subsystems (7)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 sk-filter: Add ability to get socket filter program

The SO_ATTACH_FILTER option is set only. I propose to add the get ability by using SO_ATTACH_FILTER in getsockopt. To be less irritating to eyes the SO_GET_FILTER alias to it is declared.

There are two issues with getting filter back.

First, kernel modifies the sock_filter->code on filter load, thus in order to return the filter element back to user we have to decode it into user-visible constants. Fortunately the modification in question is interconvertible.

Second, the BPF_S_ALU_DIV_K code modifies the command argument k to speed up the run-time division by doing kernel_k = reciprocal(user_k). Bad news is that different user_k may result in same kernel_k, so we can't get the original user_k back. Good news is that we don't have to do it. What we need to is calculate a user2_k so, that

reciprocal(user2_k) == reciprocal(user_k) == kernel_k

i.e. if it's re-loaded back the compiled again value will be exactly the same as it was. That said, the user2_k can be calculated like this

user2_k = reciprocal(kernel_k)

with an exception, that if kernel_k == 0, then user2_k == 1.

The optlen argument is treated like this -- when zero, kernel returns the amount of sock_fprog elements in filter, otherwise it should be large enough for the sock_fprog array.

---

include/linux/filter.h +1 -0
index 24d251f..6ca0085 100644
@@ -45,6 +45,7 @@ extern void sk_unattached_filter_destroy(struct sk_filter *fp);
 extern int sk_attach_filter(struct sock_fprog *fprog, struct sock *sk);
 extern int sk_detach_filter(struct sock *sk);
 extern int sk_chk_filter(struct sock_filter *filter, unsigned int flen);
+extern int sk_get_filter(struct sock *sk, struct sock_filter __user *filter, unsigned len);
 
 #ifdef CONFIG_BPF_JIT
 extern void bpf_jit_compile(struct sk_filter *fp);
include/uapi/asm-generic/socket.h +1 -0
index b1bea03..2d32d07 100644
@@ -43,6 +43,7 @@
 /* Socket filtering */
 #define SO_ATTACH_FILTER	26
 #define SO_DETACH_FILTER	27
+#define SO_GET_FILTER		SO_ATTACH_FILTER
 
 #define SO_PEERNAME		28
 #define SO_TIMESTAMP		29
net/core/filter.c +128 -0

131 lines not on this page · raw message

net/core/sock.c +6 -0
index 0a023b8..0628600 100644
@@ -1077,6 +1077,12 @@ int sock_getsockopt(struct socket *sock, int level, int optname,
 	case SO_BINDTODEVICE:
 		v.val = sk->sk_bound_dev_if;
 		break;
+	case SO_GET_FILTER:
+		len = sk_get_filter(sk, (struct sock_filter __user *)optval, len);
+		if (len < 0)
+			return len;
+
+		goto lenout;
 	default:
 		return -ENOPROTOOPT;
 	}
#1 lore raw
Quoted 24 lines · Pavel Emelyanov

The SO_ATTACH_FILTER option is set only. I propose to add the get ability by using SO_ATTACH_FILTER in getsockopt. To be less irritating to eyes the SO_GET_FILTER alias to it is declared.

There are two issues with getting filter back.

First, kernel modifies the sock_filter->code on filter load, thus in order to return the filter element back to user we have to decode it into user-visible constants. Fortunately the modification in question is interconvertible.

Second, the BPF_S_ALU_DIV_K code modifies the command argument k to speed up the run-time division by doing kernel_k = reciprocal(user_k). Bad news is that different user_k may result in same kernel_k, so we can't get the original user_k back. Good news is that we don't have to do it. What we need to is calculate a user2_k so, that

reciprocal(user2_k) == reciprocal(user_k) == kernel_k

i.e. if it's re-loaded back the compiled again value will be exactly the same as it was. That said, the user2_k can be calculated like this

user2_k = reciprocal(kernel_k)

Quoted 7 lines

with an exception, that if kernel_k == 0, then user2_k == 1.

The optlen argument is treated like this -- when zero, kernel returns the amount of sock_fprog elements in filter, otherwise it should be large enough for the sock_fprog array.

In your commit message, you address how you implement it, but not where it could be useful (or ``why one needs it''). For instance, in a simple case, you have a packet sniffer that uses PF_PACKET, sets up a socket filter and RX_RING, then you start looking at packets and at some point you stop and close everything. In which scenario would I (ever) call this getsockopt()? (Is it just for the sake for having a missing getter-function?)

maintainer
#2 lore raw

From: Daniel Borkmann <[email protected]>
Date: Fri, 26 Oct 2012 20:07:13 +0200

Quoted 7 lines

In your commit message, you address how you implement it, but not where it could be useful (or ``why one needs it''). For instance, in a simple case, you have a packet sniffer that uses PF_PACKET, sets up a socket filter and RX_RING, then you start looking at packets and at some point you stop and close everything. In which scenario would I (ever) call this getsockopt()? (Is it just for the sake for having a missing getter-function?)

Everything Pavel is working on is for checkpoint/restart.