What is lwn network

So the channel implementations which are being posted now are unlikely to resemble the code which will, someday, be merged into the mainline; they are, instead, exercises intended mainly to obtain a better understanding of the real nature of the problem.

But they are still a promising start to what looks to be an interesting development effort. I think the netfilter problems are more significant. I don't see why. If I'm designing a server process that requires very high throughput, I'm not going to install iptables rules for established connections. That kind of performance hit just seems antithetical to high throughput. The rule you cited deals with the easy subset: there are no rules that apply once the connection is established.

And obviously any hardware would be able to implement zero rules. User: Password:. Implementing network channels [Posted May 1, by corbet]. Implementing network channels Posted May 4, UTC Thu by liljencrantz guest, [ Link ] How does this relate to the zero-copy work going on with splice, tee and friends?

Are those functions inherently oriented exclusively towards pipes and kernel buffers or could these be used for sending IO to network cards as well? Implementing network channels Posted May 4, UTC Thu by nix subscriber, [ Link ] If the networking stack moved into libc, every app could stay the same unless it wanted direct channel access.

Implementing network channels Posted May 4, UTC Thu by caitlinbestler guest, [ Link ] Or more generally, before binding a flow to a netchannel: 1 find all netfilter rules that would apply to the flow. Implementing network channels Posted May 4, UTC Thu by smoogen subscriber, 97 [ Link ] The case where I could see the need for high throughput and high integrity or modification would be in a router.

In some cases you want the netfilter stack to be very low level. I could see netfilter in this 'world' to be split into a layered approach. But we still need this functionality for firewalls on the host. Some firewall applications need to track connections, scan packets within a connection, and even have the option of dropping connections altogether eg.

Netfilter will need some rearrangement to achieve this if channels go direct to userspace. Properly done, circular buffers require no locks and share no writable cache lines between the producer and the consumer. So adding data to or removing data from a net channel will be a fast, cache-friendly operation.

As a first step, channels can be pushed into the driver interface. But things need not stop there. A next logical step would be to get rid of the networking stack processing at softirq level and to feed packets directly into the socket code via a channel. Doing that requires creating a separate channel for each socket and adding a simple packet classifier so that the driver knows which channel should get each packet. The socket code must also be rewritten to do the protocol processing using the existing kernel code.

But why stop there? If one wants to be serious about this end-to-end thing, one could connect the channel directly to the application. Said application gets the packet buffers mapped directly into its address space and performs protocol processing by way of a user-space library.

This would be a huge change in how Linux does networking, but Van's results speak for themselves. Three layers of kernel code have been shorted out altogether, with the remaining work performed in the driver interrupt handler and the application itself.

The test system running with the full application channel code was able to handle twice the network bandwidth as an unmodified system - with the processors idle most of the time. Linux networking hackers have always been highly attentive to performance issues, so numbers like these are bound to get their attention. Beyond performance, however, this approach promises simpler drivers and a reasonably straightforward transition between the current stack and a future stack built around channels.

A channel-based user-space interface will make it easy to create applications which can send and receive packets using any protocol. If Van's results hold together in a "real-world" implementation, the only remaining question would be: when will it be merged so the rest of us can use it? Thank you for yet another enlightening article which explains a foreign concepts so even mortals have at least a remote chance of understanding them!

Do more. His comment was that there was no reason why netfilter couldn't become just another consumer of packets, and my take on that is that whilst that would require patching to the netfilter code that too could be a good thing if it eliminates the use of double-linked lists the use of which would cause you to fail CS under VJ according to him :- but would probably be a lot of code.

Of course this is only necessary if you go further than chanellising the drivers themselves as one of the really elegant things is that this change of thinking is that its very modular - you can convert drivers one at a time until they're all done, then start on looking at channelising the socket layer and then start on the consumers of the socket layer.

That looks like it's enough for most firewalling: it should give you pass existing channel , fail no channel , or needs more work channel to netfilter. Of course, the kernel would have to keep a TCP implementation, but that's not surprising, since static binaries that use sockets should continue to work.

Go for it.. OK - this was known already but could be handy for beating vendors around the head with.. Not having been at the talk, I don't know what circumstances he was talking about perhaps specifically TCP at 10Gbps? VERY interesting - but security implications to others?!? But it appears to me that this has a dark side. Today, because the kernel assembles packets, then only trusted root programs can forge packets and create many kinds of funky attack packets.

If user-level applications can create arbitrary packets, then ANYONE -- even untrusted applications -- can forge arbitrary packets and arbitrary attack packets. Clearly, in some situations this wouldn't matter. But historically getting only "user privileges" limited what you could do, including having to give away your IP address and only being able to send certain kinds of packets. Today, given only low privileges, you can't create funky packets like Xmas tree ones or total forgeries. Unless there are kernel-level checks or I misunderstand something, you CAN cause these problems.

Just imagine; a user-space app sends out a broadcast from There's a LOT of mischief that's been limited to kernel-space programs before that this might expose. I'd like to see an implementation automatically check the outgoing packets for certain properties as part of the kernel e. And I understand though don't agree with the other side of the coin: Yes, of course people who have root can send any packet.

That's not my point. My point is that for a large, shared network to be useful, there needs to be a defense-in-depth so that attackers aren't automatically given the whole store when they get just a little privilege.

This would kick away one of those mechanisms. Absolutely nothing stops a user from booting their workstation with a LiveCD that they have root access to. Or plugging in a different machine to the network. Or rebooting into single-user mode. You cannot rely on a per-machine control like root access to protect your network.

If it could, that's what I'd call a gaping security hole. Sneaky indeed! If you are implicitly trusting every packet sent by some 'trusted' host which, if it were truly trusted, would never be running any malicious code anyhow , or trusting anything running on port down, you're not running a very secure network at all.

There is no security at the IP level at all. If you want trust and security, you have to put it all in higher layers. That's not the point. Not all users are malicious.

Sometimes systems run servers like web servers that an attacker can somehow subvert. Sure, all systems should be invulnerable to all attackers. But they aren't.

Limiting the network-level actions of unprivileged accounts is not the be-all of security. Diseases that spread rapidly are often unstoppable, because you just don't have enough time to react.

Slowing the spread of a disease is key to countering it. Similarly, in the network world, slowing down attack vectors is also key to countering it.

You don't need a system-wide lock to do that kind of checking; after a call to the kernel, the memory could be mapped out and checked WITHOUT harming the cache lines of other systems. For most systems it'd just involve checking a few bytes Except the fact that this user can be an unauthorized one who've just cracked into the system from an other continent using the latest bug in a PHP BBS and his processes are running as 'nobody' user.

He'd have hard time putting a live CD into the computer, but still we really don't want him to send arbitrary packets into the network. The kernel interface for network drivers is designed for this different mode of operation. Network drivers also have to be prepared to support a number of administrative tasks, such as setting addresses, modifying transmission parameters, and maintain- ing traffic and error statistics.

The API for network drivers reflects this need and, therefore, looks somewhat different from the interfaces we have seen so far. The network subsystem of the Linux kernel is designed to be completely protocol- independent.

This applies to both networking protocols Internet protocol [IP] versus IPX or other protocols and hardware protocols Ethernet versus token ring, etc. Interaction between a network driver and the kernel properly deals with one network packet at a time; this allows protocol issues to be hidden neatly from the driver and the physical transmission to be hidden from the protocol.

This chapter describes how the network interfaces fit in with the rest of the Linux kernel and provides examples in the form of a memory-based modularized network interface, which is called you guessed it snull. To simplify the discussion, the inter- face uses the Ethernet hardware protocol and transmits IP packets. The knowledge you acquire from examining snull can be readily applied to protocols other than IP, and writing a non-Ethernet driver is different only in tiny details related to the actual network protocol.

The interested reader is urged to refer to other books describing networking issues. One note on terminology is called for before getting into network devices. The net- working world uses the term octet to refer to a group of eight bits, which is generally the smallest unit understood by networking devices and protocols. The term byte is almost never encountered in this context.

In keeping with standard usage, we will use octet when talking about networking devices. A header is a set of bytes err, octets prepended to a packet as it is passed through the various layers of the networking subsystem. When an application sends a block of data through a TCP socket, the networking subsystem breaks that data up into packets and puts a TCP header, describing where each packet fits within the stream, at the beginning. The lower lev- els then put an IP header, used to route the packet to its destination, in front of the TCP header.

If the packet moves over an Ethernet-like medium, an Ethernet header, interpreted by the hardware, goes in front of the rest.

Network drivers need not con- cern themselves with higher-level headers usually , but they often must be involved in the creation of the hardware-level header. How snull Is Designed This section discusses the design concepts that led to the snull network interface.