Creating a versatile, secure network controller using embedded Linux

PC/104 and Small Form Factors — September 1, 2004

This issue's special feature focuses on the impact of embedded software and development tools. Bundling all the software and hardware (including cables, power supplies, and simple enclosures) with a PC/104 board that has operational Linux already installed saves considerable time for developers. In this article Glen provides an alternative solution for the developer who is trying to pull all these items together to make them work, a Linux development kit.

21
Figure 1

Network devices
In the third quarter of 2003, Intel continued its expansion of XScale based platforms by introducing a family of devices targeted at networked communication products. Intel had carefully considered the technical features needed to extend the performance for networked devices while maintaining a cost that would be competitive for high volume products in the home and small-to-medium sized business market. Using the same ARM v5T core technology from the PXA255 device (used in mobile PDA and industrial controllers), Intel produced the IXP4xx family of network processors (including the IXP420, 421, 422, and 425). These devices are less focused on ultra low power consumption but designed to process IP based data packets with the highest possible throughput.  The IXP425, for example, has already been introduced into several commercial products including the new Linksys WRV54G Wireless VPN Broadband Router (see Figure 1) and Innominate mGuard VPN plug-in security device.

It is not the purpose of this article to describe the detailed capabilities of the IXP4xx devices – you can access all this information from the Intel website. It is intended to briefly describe the component technologies used to create a versatile, secure network controller using embedded Linux. One of the key technical characteristics of the IXP425 is the integrated hardware accelerated cryptography for authentication and encryption. This feature offloads a considerable amount of network activity from the core XScale processor and allows a high degree of parallel processing. The internal network processing engines of the IXP4xx are designed to handle much of the Layer 2 IP packets and can be used to accelerate VPN related tasks such as encryption (AES and 3DES) and packet authentication (SHA-1 and MD5). While this article describes an implementation using Arcom’s build of standard Linux, it is worth noting that the IXP42x family is supported by Wind River VxWorks, Microsoft WindowsCE .NET, and MontaVista Linux Professional Edition.

Getting started
The article describes the processes used by Arcom to create a standard embedded Linux development kit for the IXP425 based MERCURY board. The MERCURY is a PC/104 format module powered by the 533 MHz IXP425 processor. (See Figure 2). The block diagram of the MERCURY in Figure 3 shows it is fitted with64 MB of DRAM (133 MHz bus) and 16 or 32 MB of resident Flash along with a USB 2.0 controller and a CompactFlash port.The platform uses RedBoot to initialize the board (similar to a BIOS in a PC)and as aLinux boot loader. The RedBoot firmware is open source and comes standard with support for the Intel IXP425 processor and network utilities such as:

  • TFTP
  • HTTP
  • DHCP
  • BOOTP
22
Figure 2
23
Figure 3

Arcom’s embedded Linux team simply used the latest version from the RedBoot Concurrent Version System (CVS) repository and added in the low-level support code for the IXP425 Network Processor Engines and to correctly map the onboard 16/32 MB AMD MirrorBit Flash devices. The RedBoot Flash Image System (FIS) is a simple file manager and divides the Flash memory into three partitions:

  1. RedBoot image
  2. FIS configuration files
  3. JFFS2 (compressed journaling Flash File system)

The user defined configuration scripts specify the initial Linux command line, the root file system, and which Linux kernel to load from the JFFS2 file system. Using RedBoot, the MERCURY can quickly download a new Linux image from a host development system using TFTP via the Ethernet port. All the source files used to create the RedBoot firmware are included on the Development Kit CD.

Building Linux
The kernel is built from the current standard Linux source. Using the standard source ensures the highest level of compatibility with developments in the Linux community and reduces the support required by customers rebuilding their Linux kernel. Arcom used the latest released version of the 2.4 kernel (2.4.24) for the MERCURY Linux Development Kit. After downloading the source code from the Linux repository, it was then necessary to apply various patches to the kernel to match the hardware peripherals on the MERCURY and include the required communication technologies. There are several ARM compatibility patches and specific patches for the IXP425 available from the ARM Linux Project support site. The kernel build process also involves integrating the Intel IXP400 Access Library code  – essentially this contains all the libraries to fully exploit the hardware features of the IXP425 processor (such as Ethernet MAC, DMA, and cryptography). The development was carried out using standard GNU C Compiler (gcc) tools on a PC workstation installed with the Debian Linux distribution. Arcom includes the Fedora Core 1.0 distribution (successor to Red Hat 9) of Linux as part of the Development Kit so that the user has everything available to install on a host development platform.

There are two devices attached to the local IXP425 PCI bus:

  1. Philips 4 channel USB 2.0 controller (up to 480 Mbps)
  2. TI CardBus controller (for the CompactFlash port and PC/104 bus)

One of the benefits of using standard Linux is that drivers were readily available for both devices. In addition, since the CompactFlash port will be used for Wi-Fi cards, the standard module for the Intersil PRISM2 chipset (now produced by Conexant) was also included in the kernel build.

The operating system build is carried out with a cross toolchain targeting the ARM CPU running on a Linux x86 workstation. The familiar tools (such as gcc and ld) are merely prefixed with armbe-linux- (e.g. armbe-linux-gcc-). These tools are preconfigured to generate code that runs to the target with no additional options required. The reference to armbe denotes that the cross compiler will use the big endian data format (i.e., 32 bit data is stored in memory with MSB in the lowest memory address). Since the x86 PC architecture is inherently little endian, most Linux kernels used today are built using the little endian configuration. The IXP425 and other devices such as the PXA255 are bi-endian (they can be configured for either big or little endian operation). For the IXP425, Intel has written the IXP400 Access Library (for Linux) to drive the internal Network Processor Engines in big-endian format, which defines the entire Linux build.

Adding VPN functionality
The two commercial products listed earlier both offer Virtual Private Network (VPN) capability. The VPN uses the IPsec protocol to create a secure network connection between two computers. Targeted at the market for embedded industrial gateways, the MERCURY PC/104 board might be used to implement a telemetry link between a distributed data acquisition system and an Enterprise application or a Supervisory Control and Data Acquisition (SCADA) host. By using a VPN, data can be safely transferred between two systems using various un-trusted public networks such as the Plain Old Telephone System (POTS), wired Internet, or GPRS and iDEN wireless networks. For a Linux environment, Intel used an open source implementation of IPsec (from the Linux FreeS/WAN project) and added appropriate patches to take advantage of the hardware acceleration features of the IXP425. FreeS/WAN has a user space configuration tool to select different encryption standards and exchange security keys between the two systems. To demonstrate the performance of the IXP425, the embedded Linux kernel, and the FreeS/WAN patch, two MERCURY boards were set up to serve as VPN gateways between two desktop systems. By repeatedly transferring a 100 MB file from one desktop system to the other, it was possible to achieve an impressive payload data rate (i.e., the real data rate) of nearly 50 Mbps. Table 1 shows the results for both the Advanced Encryption Standard (AES) and triple Data Encryption Standard (3DES). For reference, this is approximately five times the performance achieved without the hardware acceleration patches built into FreeS/WAN.

 

Type of encryption and authentication

Payload data transfer rate (Mbps)

AES & SHA-1

49

AES & MD5

50

3DES & SHA-1

47

3DES & MD5

49

None selected

95

Table 1

Custom Linux builds
It is generally accepted that many developers will want to incorporate new technologies, drivers (perhaps for other CF cards or PC/104 modules), or even Intel’s code optimized Integrated Performance Primitives (IPP) into the Linux kernel image. To simplify the process of rebuilding the kernel, Arcom includes all the associated source code and a rebuild utility within the Development Kit.

A recent customer wanted to use a specific USB web camera to stream video data into the USB port and transmit these images onto the company network using a secure VPN connection over an 802.11b wireless link. The drivers for several cameras such as Logitec QuickCam and Creative WebCam Pro were readily available on the web. Since the standard Linux image already supported Wi-Fi and VPN, it was a simple process to build a new image incorporating the camera drivers. A quick review of the web found the Video for Linux site that included an open source application for streaming JPEG images over a network. A test application was rapidly tested and demonstrated to the customer within two days.

. . . . .

Glen Middleton
is the Managing Director at Arcom in Cambridge, England. He studied physics and electronics at Manchester University and then worked for the British Antarctic Survey developing data acquisition systems for use in oceanographic surveys. He has worked for Arcom for the last 15 years on product design, engineering management, and product marketing.

For further information, contact Glen at:

Arcom Control Systems
7500 West 161 Street
Overland Park, Kansas 66085
Tel: 888-941-2224
Fax: 913-549-1002
E-mail: gmiddleton@arcom.com
Website: www.arcom.com