There is a lot of ongoing work to make the Linux kernel a viable operating system option for platforms running mission-critical applications. However, there is still some work to be done with respect to supporting new features. This article addresses some needed features and mechanisms in the Linux kernel - features that are necessary in server nodes operating in mission-critical environments. Such environments include telecom, where reliability, performance, availability, and security are extremely important.
The focus is on four features: a cluster communication protocol, support for multiple FIBs, support for verifying digital signatures of binaries at runtime, and an efficient low-level asynchronous event mechanism. We'll discuss each feature, its importance, the advantages it provides, its implementation, and the status of its integration with the Linux kernel.
Transparent Interprocess Communication Protocol
Today's computing and telecommunication environments are increasingly adopting clustered servers to gain benefits in performance, availability, and scalability. The benefits of a cluster are greater or more cost efficient than what a single server can provide. In the telecommunication industry, the interest in clustering originates from the fact that clusters address carrier grade characteristics. Such characteristics include guaranteed service availability, reliability, and scaled performance using cost-effective hardware and software. The requirements can be divided into the following categories, but these are not absolute:
- Short failure detection and failure recovery
- Guaranteed availability of service
- Short response times
The most widely adopted clustering technique is use of multiple interconnected, loosely coupled nodes to create a single highly available system. In addition, the usage of commercial off-the-shelf building blocks in clustered systems has a number of advantages, such as a better price/performance ratio when compared to specialized parallel supercomputers; deployment of the latest mass-market technology, as it becomes available at low cost; and added benefits from latest standard operating system features, as they become available.
One feature missing from the Linux kernel in this area is a reliable, efficient, and transparent interprocess and interprocessor communication protocol that we can use in building highly available Linux clusters.
Transparent Inter Process Communication (TIPC) is a suitable open source implementation that fills the gap and provides an efficient cluster communication protocol, leveraging the particular conditions present within loosely coupled clusters. Figure 1 provides a functional overview of TIPC.
TIPC is unique because there seems to be no other protocol providing a comparable combination of versatility and performance. It includes some original innovations such as the functional addressing, the topology subscription services, and the reactive connection concept. Other important TIPC features include full location transparency, support for lightweight connections, reliable multicast, signaling link protocol, topology subscription services, and more.
TIPC should be regarded as a useful toolbox for anyone wanting to develop or use carrier grade or highly available Linux clusters. It provides the necessary infrastructure for cluster, network, and software management functionality, as well as a good support for designing site-independent, scalable, distributed, high-availability, and high-performance applications.
It is also worthwhile mentioning that the ForCES working group within IETF has agreed that their router internal protocol (the ForCES protocol) must be possible to carry over different types of transport protocols. There is consensus that TCP is the protocol to be used when ForCES messages are transported over the Internet, while TIPC is the protocol to be used in closed environments (LANs), where special characteristics such as high performance and multicast support are desirable. Other protocols may also be added as options.
In addition, TIPC meets several priority level 1 and level 2 requirements as defined in the OSDL Carrier Grade Linux Requirements Definition version 2.0. It provides an implementation for the Cluster Communication Service requirements.
TIPC has undergone a significant redesign over the past two years and is now available as a portable source code package of about 12,000 lines of C code. The code implements a kernel driver, a design that has made it possible to boost performance - 35% faster than TCP - and minimize code footprint. The current version is available under a dual BSD and GPL license. TIPC runs on Linux 2.4 and 2.6; several proprietary portations to other operating systems (OSE, True64, Dicos) exist and more are planned during this year.
TIPC was announced on the Linux Kernel Mailing List (LKML) in May 2004 and will be presented at the Ottawa Linux symposium in July 2004.
Support for Multiple Forwarding Information Bases
Routers are core elements of modern telecom networks. They propagate and direct billions of data packets from their source to their destination using air transport devices or through high-speed links. They must operate as fast as the medium in order to deliver the best quality of service and have a negligible effect on communications. It is common for routers to manage 10.000-500.000 routes. In these situations, good performance is achievable by handling around 2.000 routes per second.
The actual implementation of the IP stack in Linux works fine for home or small business routers. However, with the high expectations of telecom operators and the new capabilities of telecom hardware, it appears almost impossible to use Linux as an efficient forwarding and routing element of a high-end router for a large network (core/border/access router) or a high-end server with routing capabilities.
One problem with the networking stack in Linux is the lack of support for multiple forwarding information bases (multi-FIB) with the overlapping interface's IP address, and the lack of appropriate interfaces for addressing FIB. Another problem with the current implementation is the limited scalability of the routing table.
The solution to these problems is to provide support for multi-FIB with an overlapping IP address. As such, we can have independent networks in the same Linux box, on different VLAN or different physical interfaces. Another good reason for VLAN separation is security and separation of services. For instance, a GSN node having multiple company networks connected to it could use VLAN for separation, but that might not hold on the "other" side of the node - the only way to keep separation (and security) would be to have multiple FIBs. Another example is having two HTTP servers serving two different networks with potentially the same IP address. One HTTP server will serve the network/FIB 10, and the other HTTP server will serve the network/FIB 20. The advantage is to have one Linux box serving two different customers using the same IP address. ISPs adopt this approach by providing services for multiple customers sharing the same server (server partitioning), instead of using a server per customer.
The way to achieve this is to have an ID (an identifier that identifies the customer or user of the service) to completely separate the routing table in memory. Two approaches exist:
- Have separate routing tables, each routing table looked up by its ID. Within that table the lookup is done on the prefix.
- Have one table. The lookup is done on the combined key = prefix + ID.
A different kind of problem arises when we are not able to predict access time, with the chaining in the hash table of the routing cache (and FIB). This problem is of interest in an environment that requires predictable performance.
Another aspect of the problem is that the route cache and the routing table are not kept synchronized most of the time (path MTU, for example). The route cache flush is executed regularly; therefore, any updates on the cache are lost. For example, if you have a routing cache flush, you have to rebuild every route that you are currently talking to by going for every route in the hash/try table and rebuilding the information. First, you have to look in the routing cache, and if you have a miss, then you need to go in the hash/try table. This process is very slow and unpredictable since the hash/try table is implemented with a linked list and there is high potential for collisions when a large number of routes are present. This design is suitable for a home PC with a few routes, but it is not scalable for a large server.
To support the various routing requirements of server nodes operating in high-performance, mission-critical environments, Linux should support the following:
- An implementation of multi-FIB using tree (radix, patricia, etc.): It is very important to have predictable performance in insert/delete/lookup from 10.000 to 500.000 routes. In addition, it is favorable to have the same data structure for both IPv4 and IPv6.
- Socket and ioctl interfaces for addressing multi-FIB.
- Multi-FIB support for neighbors (arp).
Providing these implementations in Linux will affect a large part of net/core, net/ipv4, and net/ipv6; these subsystems (mostly the network layer) will need to be rewritten. Other areas will have minimal impact at the source-code level, mostly at the transport layer (socket, TCP, UDP, RAW, NAT, IPIP, IGMP, etc.).
As for the availability of an open source project that can provide these functionalities, there exists a project called "Linux Virtual Routing and Forwarding." This project aims to implement a flexible and scalable mechanism for providing multiple routing instances within the Linux kernel. The project has some potential in providing the needed functionalities; however, no progress has been made since 2002 and the project seems to be inactive.
Runtime Authenticity Verification for Binaries
The Distributed Security Infrastructure (DSI) is an open source project to provide a secure framework for carrier grade Linux clusters that run soft real-time distributed applications. Carrier grade clusters have very tight restrictions on performance and response time, making the design of security solutions difficult. Many security solutions cannot be used due to their high resource consumption; therefore, a security framework that targets Carrier Grade Linux clusters is important in providing advanced security levels in such systems.
Linux has been generally considered immune to the spread of viruses, backdoors, and Trojan programs on the Internet. However, with the increasing popularity of Linux as a desktop platform, the risk of seeing viruses or Trojans developed for this platform are rapidly growing. One way of addressing this risk is to allow the system to prevent the execution of untrusted software on runtime.
One solution is to digitally sign the trusted binaries and have the system check the digital signature of binaries before running them. Therefore, untrusted (not signed) binaries are denied the execution. This can improve the security of the system by preventing a wide range of malicious binaries like viruses, worms, Trojan programs, and backdoors from running on the system.
One implementation of such a feature is called DigSig, which is a component of DSI (see Figure 2). DigSig is a Linux kernel module that checks the signature of a binary before running it. DigSig inserts digital signatures inside the ELF binary and verifies this signature before loading the binary. It is based on the Linux Security Module hooks (LSM has been integrated with the Linux kernel since 2.5.x and higher).
With this approach, vendors do not sign binaries; the control of the system remains with the local administrator. The responsible administrator is to sign all trusted binaries with his or her private key. Therefore, DigSig guarantees two things:
- If you signed a binary, nobody other than you can modify that binary without being detected.
- Nobody can run a binary that is not signed or is badly signed.
There have already been several initiatives in this domain, such as Tripwire, BSign, and Cryptomark, but the DigSig project is the first to be both easily accessible to all (available on SourceForge, under the GPL license) and to operate at kernel level at runtime. The run time is very important for Carrier Grade environments as this takes into account the high-availability aspects of the system.
The DigSig approach has been using existing solutions like GnuPG and Bsign rather than reinventing the wheel. However, in order to reduce the overhead in the kernel, the DigSig project only took the minimum code necessary from GnuPG. This was very helpful in reducing the amount of code imported to the kernel in the source code of the original (only 1/10 of the original GnuPG 1.2.2 source code has been imported to the kernel module).
DigSig was released under the GPL license and has been announced on LKML; however, it is not yet integrated in the Linux Kernel.
Efficient Low-Level Asynchronous Event Mechanism
Operating systems for carrier grade systems must ensure that they can deliver a high response rate with minimum downtime. In addition, carrier grade systems must take into account such characteristics as scalability, high availability, and performance.
In carrier grade systems, thousands of requests must be handled concurrently without affecting the overall system performance, even under extremely high loads. Subscribers can expect some latency time when issuing a request, but they are not willing to accept an unbounded response time. Such transactions are not handled instantaneously for many reasons, and it can take some milliseconds or seconds to reply. Waiting for an answer reduces applications' abilities to handle other transactions.
Many solutions have been proposed and prototyped to improve the Linux kernel capabilities in this area using different types of software organization, such as multithreaded architectures, implementing efficient POSIX interfaces, and improving the scalability of existing kernel routines.
One possible solution that is appropriate for carrier grade servers is the Asynchronous Event Mechanism. AEM provides an asynchronous execution of processes in the Linux kernel. It implements a native support for asynchronous events in the Linux kernel and aims to bring carrier grade characteristics to Linux in areas of scalability, performance, and soft real-time responsiveness.
An event-based mechanism provides a new programming model that offers software developers unique and powerful support for asynchronous execution of processes. Of course, it radically differs from the sequential programming styles used but it offers a design framework better structured for software development. It also simplifies the integration and the interoperability of complex software components.
In addition, AEM offers an event-based development framework, scalability, flexibility, and extensibility. This emerging paradigm provides a simpler and more natural programming style compared to the complexity offered by multithreaded architectures. It proves its efficiency for the development of multilayer software architectures, where each layer provides a service to the upper layer. This type of architecture is quite common for distributed applications
One of the strengths of AEM is its ability to combine synchronous code and asynchronous code in the same application, or even mix these two types of models within the same code routine. With this hybrid approach, it is possible to take advantage of their respective capabilities depending on the situation. This model is especially favorable for the development of secure software and for the long-term maintenance of mission-critical applications.
AEM was released to open source in February 2003 under the GPL license and was announced on the LKML. The feedback received suggested changes to the design, which resulted in an improved implementation, and a better kernel-compliant code structure. AEM is not yet integrated with the Linux kernel.
Conclusion
There are many challenges accompanying the migration from proprietary to open platforms. The main challenge is the availability of the various kernel features and mechanisms needed for telecom platforms, and integrating these features in the Linux kernel. As part of its involvement with the open source community, Ericsson has provided three essential feature implementations (AEM, DigSig, and TIPC) that are needed by server nodes operating in a mission- critical environment. I hope that more companies will follow this example, and provide feature implementations that will allow Linux to meet various requirements demanded by high-end server nodes. The second part of the challenge will be to integrate those implementations in the Linux kernel. Timing is always an important factor!
Acknowledgments
I would like to acknowledge Ludovic Beliveau, Mathieu Giguere, Magnus Karlson, Jon Maloy, Mats Näslund, Makan Pourzandi, and Frederic Rossi for their valuable contributions and reviews.
References
TIPC: http://tipc.sf.net
Maloy, John. "Make Clustering Easy with TIPC." LinuxWorld Magazine. April 2004.
DSI and DigSig: http://disec.sf.net
Pourzandi, Makan; Apvrille, Axelle; Gordon, David; and Roy, Vincent. "Stop Malicious Code Execution at Kernel Level." LinuxWorld Magazine. January 2004.
AEM: http://aem.sf.net
Open System Lab: www.linux.ericsson.ca
IETF ForCES: www.ietf.org/html.charters/forces-charter.html
Linux Virtual Routing and Forwarding project: http://linux-vrf.sourceforge.net
Tripwire: www.tripwire.com
Bsign: http://packages.qa.debian.org/b/bsign.html
Cryptomark: www.immunix.org/cryptomark.html
GnuPG: www.gnupg.org
DigSig announcement on LKML: http://lwn.net/Articles/51007
AEM announcement on LKML: http://lwn.net/Articles/45633
Subscribe to Linux Email News Alerts
Subscribe via RSS
