[QUESTION] Kernelspace <-> Userspace communication during tcp stack code execution

["Jack Bauer" <mlsubscriber@gmail.com>]

Hi,

I'm a student in computer science and for my master thesis i have to
modify the kernel TCP stack in a way that it allows to perform a
transparent user authentification during the TCP 3-way-handshake (with
the help of a modified firewall which tracks the 3-way-handshake).

As you might imagine I have to alter the syn,synack and ack packets
and fill it with authentification information of the user who
initiated the new TCP connection. These information are stored in
config files on the client/user host (for example a config file which
contains the location of the users certificate). On the firewall host
I also need file access from within a netfilter kernel module and have
to perform other time consuming tasks (for example reading the root
certificate and check the users cert in the syn packet).

As these tasks are typical userspace tasks I want to write a daemon
which does all the file access and certificate work when the kernel
requests it and which than sends the information back to the kernel.

What opportunities do I have to implement a fast Kernel <-> Userspace
Daemon communication?

My first tought was to create a /proc or /dev entry and register file
operation functions for these entries. But the first problem I see is
that the daemon has to read the /proc or /dev file in an endless loop
so that the daemon recognizes (in a fast way) when the kernel pushes
request commands to the /proc or /dev file. The second problem is that
the kernel has to wait for the answer of the daemon before it can
continue and putting the requested information in the syn packet for
example. And what happens if the request method (which got called in
the tcp stack) blocks until the daemon response was read in? I think
the kernel would hang, wouldn't it?

The second tought was to use AF_NETLINK which should solve the first
problem but as the NETLINK readmsg() method also blocks until it
recieved data I don't know if the kernel would also hang.

Do you have any suggestions how to solve this situation?

regards,
Jack
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/