* [rfc] ipt_owner.c improvements
@ 2005-03-04 1:25 Juha Heljoranta
2005-03-04 23:35 ` Patrick McHardy
0 siblings, 1 reply; 3+ messages in thread
From: Juha Heljoranta @ 2005-03-04 1:25 UTC (permalink / raw)
To: netfilter-devel
I'd like to make few improvements to ipt_owner.c or perhaps to create
something new that is like owner match.
First I'd like to improve performance for incoming packet matches. The
next thing is to reliably identify sending/receiving process. Last
proposal is to improve performance when matching is done several times
per packet.
For incoming packets we can use code from sk callback mechanism:
sk->sk_state_change = sock_def_wakeup;
sk->sk_data_ready = sock_def_readable;
When userspace is informed following functions are called:
sock_def_readable / sock_def_wakeup
`-- wake_up_interruptible
`-- __wake_up
`-- __wake_up_common
|--...
Basically what happens is:
list_for_each_safe(tmp, next, &sk->sk_sleep->task_list) {
curr = list_entry(tmp, wait_queue_t, task_list);
struct task_struct *owner = curr->task;
...
}
This relies on fact that to receive a packet task must sit on
sk->sk_sleep queue (or in struct fasync_struct *fa).
However, packet can pass through netfilter just before task enters into
sk_sleep resulting that the task might get the packet.
Just to remind: quote from iptables(8) man page "some packets (such as
ICMP ping responses) may have no owner, and hence never match".
Also, some in-kernel stuff uses different functions to inform userspace:
net/sunrpc/svcsock.c
net/sunrpc/xprt.c
net/bluetooth/rfcomm/core.c
net/bluetooth/rfcomm/sock.c
net/atm/common.c
and possibly samba too
I haven't yet tested the behavior when using e.g. rpc. It might or might
not work.
Next, slightly modified fs/proc/base.c:proc_exe_link():
struct file *get_vm_executable(struct task_struct *p)
{
struct vm_area_struct *vma;
struct file *vm_file = NULL;
struct mm_struct *mm = p->mm;
if (!mm)
return NULL;
vma = mm->mmap;
while (vma) {
if ((vma->vm_flags & VM_EXECUTABLE) &&
vma->vm_file) {
vm_file = vma->vm_file;
break; /* found! */
}
vma = vma->vm_next;
}
return vm_file;
}
this means for example that stat(2) information is available
vfs_getattr(vm_file->f_vfsmnt, vm_file->f_dentry, &stat);
thus it would mean that it is possible to
# iptables -A foo -m owner --cmd-owner XXX -j ACCEPT
where XXX can be something like '/usr/sbin/sshd' or device/inode number.
All tricks above should be performed only once per packet, so that doing
# iptables -A foo -m owner --cmd-owner x -j ACCEPT
# iptables -A foo -m owner --cmd-owner y -j ACCEPT
# iptables -A foo -m owner --cmd-owner z -j ACCEPT
# iptables -A foo -m owner --cmd-owner foo -j ACCEPT
# iptables -A foo -m owner --cmd-owner bar -j ACCEPT
# iptables -A foo -m owner --cmd-owner baz -j ACCEPT
...
would not waste system resources.
Targets are allowed to modify skb so that 'skb->sk->foo = bar' can be
done. Would it make sense to have an OWNER target (that requires mangle
table?)? If yes, what would be the behavior if the OWNER target is not
yet passed:
# iptables -A foo -m owner --cmd-owner x -j ACCEPT
# iptables -A foo -j OWNER
# iptables -A foo -m owner --cmd-owner y -j ACCEPT
Alternatively I can keep list of tasks and socket and put up a timer to
clean the list once awhile.
Regards,
Juha Heljoranta
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [rfc] ipt_owner.c improvements
2005-03-04 1:25 [rfc] ipt_owner.c improvements Juha Heljoranta
@ 2005-03-04 23:35 ` Patrick McHardy
2005-03-09 12:59 ` Juha Heljoranta
0 siblings, 1 reply; 3+ messages in thread
From: Patrick McHardy @ 2005-03-04 23:35 UTC (permalink / raw)
To: Juha Heljoranta; +Cc: netfilter-devel
Juha Heljoranta wrote:
> I'd like to make few improvements to ipt_owner.c or perhaps to create
> something new that is like owner match.
>
> First I'd like to improve performance for incoming packet matches. The
> next thing is to reliably identify sending/receiving process. Last
> proposal is to improve performance when matching is done several times
> per packet.
As Dave Miller pointed out, the only sensible thing to do is add new
hooks to the protocols themselves, anything else is racy. The main
challenges are making sure incoming connections using protocols that
support sockets aren't confirmed before they survived the socket
hooks, with all possible module combinations, and possibly hooks for
outgoing packets, I haven't thought about that very much.
Regards
Patrick
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [rfc] ipt_owner.c improvements
2005-03-04 23:35 ` Patrick McHardy
@ 2005-03-09 12:59 ` Juha Heljoranta
0 siblings, 0 replies; 3+ messages in thread
From: Juha Heljoranta @ 2005-03-09 12:59 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel
Patrick McHardy wrote:
> Juha Heljoranta wrote:
>
>> I'd like to make few improvements to ipt_owner.c or perhaps to create
>> something new that is like owner match.
>>
>> First I'd like to improve performance for incoming packet matches. The
>> next thing is to reliably identify sending/receiving process. Last
>> proposal is to improve performance when matching is done several times
>> per packet.
>
>
> As Dave Miller pointed out, the only sensible thing to do is add new
> hooks to the protocols themselves, anything else is racy. The main
> challenges are making sure incoming connections using protocols that
> support sockets aren't confirmed before they survived the socket
> hooks, with all possible module combinations, and possibly hooks for
> outgoing packets, I haven't thought about that very much.
I've been skimming through the code and concluded that the fastest and
most reliable way to find a task receiving packet is to copy
sock_def_readable and modify it to fit into job.
I'm not exactly sure what you mean by adding new hooks to protocols but
I think that the this could be it (the hook for tcp and udp). Right?
I don't expect any race conditions to exist (famous last words) because
all what we are performing is just crippled version of sock_def_readable.
As I stated before sunrpc¸ samba, bluetooth, x25, etc. reassign callback
functions which means that things _might_ not work as expected when
using them. Any way, I think that this is separate issue, we are not
trying to find tasks that use samba but task that use tcp or udp, right?
To get an idea what will happen when modified version of
sock_def_readable is issued (simplified and no locking):
void foo(struct sock *sk)
{
if (sk->sk_sleep && waitqueue_active(sk->sk_sleep)) {
list_for_each_safe(tmp, next,
&sk->sk_sleep->task_list) {
...
}
}
/* for finding SIGIO targets */
bar(sk->sk_socket->fasync_list)
}
void bar(struct fasync_struct *fa)
{
while (fa) {
baz(&fa->fa_file->f_owner);
fa = fa->fa_next;
}
}
void baz(struct fown_struct *fown)
{
pid = fown->pid;
if (pid > 0) {
p = find_task_by_pid(pid);
if (p)
...
} else {
do_each_task_pid(-pid, PIDTYPE_PGID, p) {
...
} while_each_task_pid(-pid, PIDTYPE_PGID, p);
}
}
There is still case of multicast to deal with (locate all receiving
struck sock *sk and issue foo(sk) for each).
Regards,
Juha Heljoranta
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2005-03-09 12:59 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-03-04 1:25 [rfc] ipt_owner.c improvements Juha Heljoranta
2005-03-04 23:35 ` Patrick McHardy
2005-03-09 12:59 ` Juha Heljoranta
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.