Networking stack into kernel

[Jonathan S. Shapiro]

> One interesting option is to allow TCP sessions to survive reboots of the
> system.

You can't.  There is a security issue.  Because the TCP connection is
connection oriented, the endpoints tend to authenticate at the start
and not thereafter.

Also, the TCP segments that both sides have agreed are transmitted are 
eagerly discarded.  You could keep the sequence numbers, but you
wouldn't have the data to retransmit.

> If existing connections are to be torn down on reboot, the other end should
> be notified.  Otherwise it may have a hanging connection.

This is no different from the remote host going down.  TCP, at least,
has well-defined timeouts for keepalive counters that guarantee
reasonably fast teardown.  At the very least it is reduced to a
previously solved problem.

The minute the downed host reboots the two sides will rapidly agree
that the connections are stale.

> How do you protect against Trojan horses in the network driver code?  Even
> if you aren't trying to formally verify the kernel, you still want to get
> informal assurance of correctness.  Making it larger won't help.  (But
> being able to easily port existing code is damn attractive!)

First, this is publicly examinable code.

Second, removing the protocol code won't eliminate the network driver
problem.

In the long term I agree that the network code doesn't necessarily
belong in the kernel, but it is more important at this time to get
something working quickly.  This can be re-engineered later.

> >     AO- Implementing this requires introduction of dynamically
> >	 allocated memory into the kernel.
> 
> This issue is not exactly dynamic memory allocation.  It is always being
> able to proceed when memory is not available.  e.g. When a page frame is
> not available, the process needing it waits for a page out operation to
> complete.  So much code is written which assumes that it is OK to fail when
> malloc fails, that the easy way to express the need to proceed is to say,
> "No dynamic memory allocation".

There are (at least) two legitemate behaviors:

  1. Wait for memory to become available
  2. Deal with the lack of memory by doing something appropriate.

Networking stacks, for example, can always discard packets.

The tricky part is that several of the important things being
allocated have bursty behavior, and this needs to be dealt with.


shap