sk-filter: Add ability to get socket filter program
Subsystems (7)
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
@@ -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
@@ -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
@@ -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 ; }
Quoted 24 lines · Pavel Emelyanov
The
SO_ATTACH_FILTERoption is set only. I propose to add the get ability by usingSO_ATTACH_FILTERin getsockopt. To be less irritating to eyes theSO_GET_FILTERalias to it is declared.There are two issues with getting filter back.
First, kernel modifies the
sock_filter->codeon 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_Kcode modifies the command argument k to speed up the run-time division by doingkernel_k=reciprocal(user_k). Bad news is that differentuser_kmay result in samekernel_k, so we can't get the originaluser_kback. Good news is that we don't have to do it. What we need to is calculate auser2_kso, that
reciprocal(user2_k)==reciprocal(user_k)==kernel_ki.e. if it's re-loaded back the compiled again value will be exactly the same as it was. That said, the
user2_kcan be calculated like this
user2_k=reciprocal(kernel_k)
Quoted 7 lines
with an exception, that if
kernel_k== 0, thenuser2_k== 1.The optlen argument is treated like this -- when zero, kernel returns the amount of
sock_fprogelements in filter, otherwise it should be large enough for thesock_fprogarray.Signed-off-by Pavel Emelyanov <[email protected]>
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?)
David Miller
maintainerFrom: 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 andRX_RING, then you start looking at packets and at some point you stop and close everything. In which scenario would I (ever) call thisgetsockopt()? (Is it just for the sake for having a missing getter-function?)
Everything Pavel is working on is for checkpoint/restart.
David Miller
maintainerYou can't only add this to asm-generic, you must add the new option to all the arch specific headers that need it too.