Netlink header decoding

[Dmitry V. Levin]

On Sun, May 08, 2016 at 03:12:16PM +0000, Fabien Siron wrote:
> Quoting Dmitry V. Levin (2016-05-08 00:29:36)
> > On Fri, May 06, 2016 at 10:08:55PM +0000, Fabien Siron wrote:
> > > Quoting Dmitry V. Levin (2016-05-06 01:20:27)
> > > > Hi,
> > > > 
> > > > On Thu, May 05, 2016 at 10:04:51PM +0000, Fabien Siron wrote:
> > > > > Hi list,
> > > > > 
> > > > > I did a quick netlink header parser for sendmsg/recvmsg which does the
> > > > > following:
> > > > > 
> > > > > $ strace -qq -erecvmsg tests/netlink_inet_diag > /dev/null  
> > > > > recvmsg(1, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, \
> > > > > msg_iov(1)={len=96, type=20, flags=2, seq=0, pid=26615}, \
> > > > > msg_controllen=0, msg_flags=0}, 0) = 672
> > > > > 
> > > > > Of course, this is just a draft to get an idea on how the futur parser will
> > > > > work (so forget about the flags for the moment).
> > > > > Logically, the next step would be to handle the different protocols, but
> > > > > how can I obtain the protocol of a netlink socket fd?
> > > > > 
> > > > > I have two ideas:
> > > > > * keep all the pairs fd/protocol in a table when running the socket
> > > > > syscall.
> > > > 
> > > > sockets could be closed, cloned, and passed via SCM_RIGHTS messages.
> > > > Can you track it in a reliable way?
> > > > 
> > > > > * obtain the socket inode and then parse /proc/net/netlink to obtain the
> > > > > protocol.
> > > > 
> > > > As a modern alternative to /proc/net/netlink, you can use
> > > > NETLINK_SOCK_DIAG with AF_NETLINK sockets, too
> > > > (available in linux >= 3.10-rc1).
> > > 
> > > Nice, that's perfect. But do we have to handle the case where
> > > linux < 3.10-rc1?
> > 
> > I wouldn't worry about new netlink decoding features on linux < 3.10-rc1.
> 
> Well, in fact, there is a small issue with this idea. Consider that the
> socket is not binded (like netlink socket in netlink_inet_diag test),
> NETLINK_SOCK_DIAG won't be aware of that socket until the first send/recv.

Good point, neither NETLINK_SOCK_DIAG nor /proc/net/netlink would be aware
of it.

> It probably matters for netlink parsers because we need the netlink
> protocol for each send/recv.
> 
> e.g.:
> $ ./strace -qq -yy -esendmsg,recvmsg tests/netlink_inet_diag > /dev/null
> sendmsg(1<NETLINK:[10856350]>, ...
> recvmsg(1<NETLINK:[NETLINK_SOCK_DIAG]>, ...
> 
> An alternative would be to print the function arguments in recv/send
> functions only when the function is exiting. It seems to work like that.

Why do we decode syscall arguments on entering when possible?
Because syscalls may work for a long time, and we might want to know
what they are working on.

Assuming that we have an inode based cache of sockets, could it be
possible to decode these syscalls on entering when NETLINK_SOCK_DIAG
information is either already available or hasn't been requested, and
delay decoding on exiting otherwise?


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20160510/0f74f36b/attachment.bin>