Re: installing bsd network layer from open source

Giorgos Keramidas <keramida@xxxxxxxxxxxxxxx> wrote:
+---------------
| checkit <katzir.shai@xxxxxxxxx> wrote:
| > i need to extract the TCP/IP stack of the FreeBSD for use in my
| > program.
|
| The TCP/IP stack is not implemented by a 'program', but by the kernel of
| the FreeBSD operating system. As it is a part of a large, complex piece
| of software -- like the FreeBSD kernel -- it's is fairly modular, but it
| also depends on *MANY* features of the FreeBSD kernel.
+---------------

Actually, not all *that* many, if you slice it out of the kernel along
just the right boundaries. [See below.]

+---------------
| As a result, it is not very easy to "copy a few files around" and
| "BLAM!" implement a new TCP/IP stack. It will take a huge amount of
| effort to extract and modularize _only_ the TCP/IP stack, and make it
| an integral module of another system altogether. It's not impossible,
| mind you. Just mind-boggingly difficult.
+---------------

Well, I actually did *exactly* that for a consulting client just
about 20 years ago. As I recall, it took me about two calendar months
to rip the guts out of the 4.3 BSD Tahoe networking code and get it
to work inside an Amdahl UTS-5 kernel [UTS didn't yet have TCP/IP
networking at the time, which is why my client was paying me for
the job] plus wrap a bunch of small user-mode utilities around the
whole thing *and* write a "netif" driver for a funny IBM channel
style Ethernet adapter. [Yes, STARTIOs & CAWs & CCWs & CSWs and all
that. In C.] I cheated just a little by *not* implementing a special
socket system call on the target the way BSD does it, but instead
wrote a fake "/dev/socket" driver, then implemented all of the BSD
"socket()" calls in a library as calls to the "ioctl()" routine of
the "/dev/socket" device [since that was easier than adding a new
system call to UTS-5].

A good-sized piece of work, to be sure, but I'd classify it more
as boring grunt work rather than "mind-boggling".

It would be harder if your target is not a Unix-like or Linux-like
operating system, of course, though probably still doable.

+---------------
| checkit <katzir.shai@xxxxxxxxx> wrote:
| > can someone help me understand, which part of the source code
| > is required for this...
+---------------

You will need to use *AND UNDERSTAND VERY WELL* at least all of the
code in the following directories on a standard FreeBSD machine with
kernel source installed:

/usr/src/sys/net/* [~85 files]
/usr/src/sys/netinet/* [~90 files]
/usr/src/sys/netinet6/* [~70 files, optional if you're not doing IPv6]

plus at least the following headers [and any they include, recursively]:

/usr/src/sys/sys/socket.h
/usr/src/sys/sys/socketvar.h
/usr/src/sys/sys/sockio.h
/usr/src/sys/sys/mbuf.h
/usr/src/sys/sys/protosw.h

plus at least the following other kernel files:

/usr/src/sys/kern/sys_socket.c
/usr/src/sys/kern/kern_mbuf.c
/usr/src/sys/kern/uipc_*.c [11 files]

NOTE: The above list of files leaves out all the code for IPSEC,
ATM, Appletalk, 802.11, and a bunch of other stuff like
NFS & RPC & Samba. It's just the basic TCP/UDP/IP stack.

Basically, you need to cut the stack at the top somewhere just below
the system call level and just above all of the "so*" request routines,
e.g., "socreate()", "sobind()", "solisten()", the body [but not all of]
"accept1()", "soconnect()", what *used* to be just "sosend()" but
is now [say, in "kern_sendit()"] the more generic dispatch call
"so->so_proto->pr_usrreqs->pru_sosend()", and so on.

And then you need to cut the stack on the side, where the "mbuf"
allocation code calls the system's allocation routines, and replace
them with your own. [Statically allocating a largish hunk of kernel
memory and *only* providing small mbufs allocated out of that (with
a simple linked free list) is barely sufficient (it's what *I* did,
see above), but you'll probably want to do better if performance is
an issue.]

Then finally, you need to slice the stack at the bottom, either just
above all the "ifnet" drivers, or, if your target platform uses some
of the same chips, inside the "ifnet" drivers around all of the calls
they make out to kernel services you don't have on your target, and
replace those services with some equivalent(s).

When sliced this way, the guts of the BSD TCP/IP stack actually
do come out with surpisingly few "dangling bits" that you need to
reconnect to the corresponding services in your new environment.

+---------------
| checkit <katzir.shai@xxxxxxxxx> wrote:
| > ...and what configurations are need to be done.
+---------------

Uh-oh! This suggests that you probably don't have the kernel
internals knowledge to pull this off. "Never mind..."


-Rob

-----
Rob Warnock <rpw3@xxxxxxxx>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

.

Relevant Pages

  • Re: Linux Kernel Exploits / ABFrag
    ... *BSD remote kernel-level (TCP/IP stack) ... that would perform a stack smash in the kernel, ... >is bad to kids/defacers, but good to security ...
    (Bugtraq)
  • Re: multi-core ramifications w.r.t the monolithic linux kernel
    ... process 2 networking packets on 2 instances of the TCP/IP stack ... implementation as 2 threads to serve 2 applications that want to ... A lot of the evolution has been getting rid of the BF kernel lock as ...
    (comp.arch)
  • Re: Embedded kernel with C source?
    ... hardware independant C (with full sourcecode). ... project requires a TCP/IP stack, I would prefer a kernel for which such ... I can't keep the old kernel. ...
    (comp.arch.embedded)
  • Re: Kernel newbie questions
    ... This is a nit. ... hogs and the kernel will run smoother without it. ... I'm not aware of any other reasons for doing this, ... Ah - this would be the reason the entire TCP/IP stack is in the kernel, ...
    (comp.os.linux.misc)
  • Re: FreeBSD vs Linux
    ... I've heard that Linux's TCP/IP stack has ... Marconi, not FreeBSD. ... Best, no; better than Linux, I don't know; good enough, certainly. ... If you find them, make sure they are recent, are comparing oranges to ...
    (comp.unix.bsd.freebsd.misc)