netdev - RFC: TIPC API, bind to two networks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <4787C6AF.7000308@nortel.com>
Date:	Fri, 11 Jan 2008 14:42:39 -0500
From:	"Randy Macleod" <macleodr@...tel.com>
To:	netdev@...r.kernel.org
CC:	Ravik Rao <ravik.rao@....com>,
	"Chris Friesen" <cfriesen@...tel.com>,
	tipc <tipc-discussion@...ts.sourceforge.net>
Subject: RFC: TIPC API, bind to two networks

I'd like some feedback on a change to TIPC that I plan
to submit to netdev/kernel.org. At this stage, I'm interested
in what people think about using the protocol parameter
of the socket interface to select a TIPC stack for the socket.
My co-worker, Chris Friesen, has suggested that it would
be more conventional to extend the TIPC sockaddr to
select the appropriate network in calls to sendto() or bind().
I prefer socket(,,protocol) approach.

Some background:

We use TIPC in an ATCA chassis (Advanced Telecommunications Computing
Architecture). An ATCA chassis may have two networks commonly called
base and data (outside of the ATCA world base is called control).

Users want to be able to create a TIPC socket that is
bound to one network OR the other. The intention is that these
networks should be isolated as much as possible.

The attached patch accomplishes this by using the protocol
parameter of the socket() syscall. A user can specify the TIPC stack
to which the socket should be attached as follows:
     int socket(int domain, int type, int protocol);
     fd = socket(AF_TIPC, SOCK_SEQPACKET, 1);
In the unpatched TIPC code the protocol was required to be zero.
This requires that the user know the network topology or that the
system designer provide an API (get_base_netid(), get_data_netid()).

The patch is for tipc-1.5.12 which you can get from tipc.sf.net.
We're way back on linux-2.6.14 - gotta love the embedded world!

In terms of implementation,
the basic idea of the patch is to introduce a layer in the
TIPC code around socket creation and tipc netlink messages.
This layer lets TIPC stack code register callback functions and
then dispatches socket() and netlink calls to the appropriate
TIPC stack.

For example usage, please see:
<http://sourceforge.net/mailarchive/message.php?msg_name=476839F3.8070203%40nortel.com>

One note for those who might not read the link above....
I create two modules: tipc.ko and tipcstack.ko
these are ~98% identical with certain bits of functionality,
like registering AF_TIPC, disabled. This means that we have
the same bits of code loaded twice but that's a feature not
a bug! It means that the control and data networks are even
more independent so you could update one but not the other
or you could use system tap on one but not the other.

diffstat:
    Makefile                |   15 +++-
    include/net/tipc/tipc.h |   11 ++-
    net/tipc/core.c         |  157
+++++++++++++++++++++++-------------------------
    net/tipc/core.h         |   25 +++++++
    net/tipc/handler.c      |   17 +++--
    net/tipc/netlink.c      |   21 +++++-
    net/tipc/socket.c       |   55 ++++++++++++----
    net/tipc/vtipc.c        |  154
+++++++++++++++++++++++++++++++++++++++++++++++
    net/tipc/vtipc.h        |   48 ++++++++++++++
    tools/tipc-config.c     |   29 ++++++--

Even though I *don't* want the attached patch to be integrated
into the kernel (yet), I'm still going to include:
Signed-off-by: Randy MacLeod (macleodr@...tel.com)
because it's taken such a long time to get Nortel to bless
official kernel participation!

// Randy

View attachment "tipc-1.5.12-vtipc-01.patch" of type "text/plain" (27357 bytes)