Reconfigurable Computing and Active Networks - CiteSeerX

Reconfigurable Computing and Active Networks Nikolaos G. Bartzoudis, Alexandros G. Fragkiadakis, David J. Parish, José Luis Núñez and J.M. Sandford Department of Electronic & Electrical Engineering Loughborough University, Loughborough, Leics. LE11 3TU. UK. E-mail: {N.Bartzoudis, A.Fragiadakis, D.J.Parish, J.L.Nunez-yanez, J.M.Sandford}@lboro.ac.uk Abstract This paper describes an experimental platform, optimised for Active Network processing. The system is based on a PC running Linux and operating as a router. The active applications are downloaded in a FPGA based PCI board. An embedded hardware module monitors and manages the active applications at run time. A stable and safe reconfigurable platform for the Active Applications is the objective of this investigation. Keywords: Reconfigurable Computing Safety, Active Networks, Hardware Monitor.

1. Introduction The growing demand for network applications with advanced features and complex network services to support them is creating the need for programmable network devices. Reconfigurable computing can be applied to hardware solutions for active networks [1]. An active packet [13] that carries executable code can potentially change the state of a node. Nodes (e.g. routers, switches) are public resources. Their operability is critical to the proper and correct running of many important systems and services. Therefore, the execution environment must satisfy very strict safety and security requirements. A preliminary security framework for a proposed target hardware platform is introduced in this paper. It will be implemented into the heart of a hardware module (PCI board), and will be applied to the IP cores that will be sent or requested by an end user.

2. Active Packets The Active Packets [13] may have one of the following operation modes: i) In the first scenario the Active Packet has a pointer to a certain application. The requested application is stored either in the Active Router or in a different location (e.g. a Code Server). The Active Router detects and processes the Active Packet so as to serve the request. The requested application is then configured in our hardware platform. The Active Router

forwards the user’s data to the PCI card, so as to be processed by the Active Application. ii) In the second approach, several Active Packets carry a configuration bitstream and data in their payloads. The Active Router detects and processes the Active Packets so as to serve the request. This processing stage includes authentication of the user, and integrity checks. The application is then configured in the target FPGA board and in the following stage the host transfers the user data.

3. Previous work Tests on experimental platforms have already addressed issues like a hardware manager and a hardware operating system [2] in an embedded hardware platform, and also run-time [3] and partial (re)-configuration [4]. Considerable work in almost all the above issues has been implemented in the FPX project [5]. The deliverables of the P4 project [6] are similar to many of the requirements of our project. Xilinx introduced IRL (Internet Reconfigurable Logic) [7] as a system design methodology that enables modification and upgrading of hardware and software in a target system across a network. Altera followed, introducing the remote system configuration in the Stratix devices [8].

4. Objectives The scope is to provide a reliable, flexible and secure platform for configuring hardware cores in support of the Active Networks initiative. A synopsis of the objectives is given below: § The re-programmatibility of an Active Network with new configuration bitstreams. § The use of a PCI board having a reconfigurable array (FPGA) in a PC-based router, as the execution environment of the active applications. § A post implementation method for monitoring the functionality of digital designs, through a monitor module embedded in the board. § The implementation of compute-intensive algorithms in hardware and the on-demand configuration of hardware cores.

§

Structure guides for building safe reconfigurable systems.

5. Reconfigurable Computing and Active Networking security Our Active Router can suffer from two different classes of system failures: a) malicious/intentional attacks and b) hardware bugs which are analogous to the software bugs, meaning failures in the logic design. A malicious attack can potentially create a failure of the hardware device at the electrical signals level. The attacker may create electrical failures either in the internal connections of the FPGA device or to the pins that connect one device with other neighbouring embedded components. The kind of attack described above does not apply directly to the requirements and the scope of this project. The hardware designs that are going to be used in our platform will be verified and tested by the hardware developers who produce them. In another scenario of malicious attacks, one could intercept a configuration bitstream being downloaded into the hardware platform of an Active Router and leave the ID unchanged but replace the rest of the bitstream with random bits. Finally, a theoretical way to attack a FPGA is the development of a ‘malicious’ compiler. A countermeasure for this attack is to use authentication credentials in all the incoming active packets. A different category of system failures is possible when an application over-consumes the resources of a computer system (host) or the local resources of an embedded system. The result may be performance degradation for the other applications running on the host, or even Denial of Service (DoS). In the worst-case scenario of DoS failures, the host may stop operating. An Active Application may require the following resources from a host computer in a single user environment: i) Memory ii) CPU cycles iii) Network connections iv) FPGA application specific requirements. In a multi-user model, the resource management is a more complex issue because it involves fair allocation and fair scheduling of the resources. The logic failures of a digital design can generate invalid cycles. Some common events may include data corruption, continuous request for bus ownership, reading an empty memory, trying to write to a full memory, generating illegal read or write cycles, bus contention etc. Some of these failures may lead in an endless loop for a particular computational process. Moreover illegal cycles can violate certain rules of a protocol specification. The performance of the applications can be monitored if we probe one of the following computer entities: a) the main bus of the system or a local bus, b) the reconfigurable array (FPGA) c) the memory (embedded or external) and d) the microprocessor.

Monitoring a bus seems to be the best means for tracking the functionality and behaviour of a system, since it reflects the system functionality. A FPGA-based hardwired logic can be developed to monitor the functionality of the system components in real time.

6. Design guidelines and requirements 1. A fundamental requirement is that all the hardware applications (in the form of a configuration bitstream) have already been verified and tested. 2. The hardware developers should encrypt the configuration bitstreams with a standard encryption algorithm, before encapsulating them in active packets. The downloading process of a configuration bitstream is given in detail in figure 1. Incoming Configuration bitstream

NO Authentication

YES

NO

Application discarded

Decryption YES

NO Integrity Checks YES FPGA board Communication with the host

NO

Policy-based Monitor Module YES

Figure 1: The configuration process of a bitstream. 3. Altera-based products were chosen, because of the previous expertise in the integration of an IP core with the Altera PCI MegaCore function [9]. The developers who are targeting our reconfigurable platform must build or adapt their IP cores according to the Altera PCI design guidelines. 4. It is almost impossible to predict every single violation that will cause the router to enter a nonoperating mode. Hence, the execution environment of the configuration bitstreams was physically isolated from the Linux routing processes, using a second Linux PC to host the reconfigurable module (PCI board). 5. So far two PCI boards have met our requirements [12]. However, a Xilinx PCI board is currently being used for testing purposes in our experimental Active Network. This Xilinx PCI board is specially designed to

deliver rapid implementation of reconfigurable computing applications, and thus it was used at this stage for practical reasons. In the future it will be part of a multi FPGA vendor Active Network. 6. When the Linux scheduling module receives multiple requests for different configuration bitstreams targeting our FPGA board, a first come first served policy will be applied. The scenario for serving multiple users simultaneously can be realised by two approaches: a. A multiple FPGA board having a scheduling algorithm for allocating the several configuration bitstreams to the FPGA devices b. Partial configuration of one FPGA device [4] Both solutions involve the implementation of complex resource allocation and switching mechanisms, and hence they are not adopted at least at this stage. 7. The configuration environment can be realized with the topology shown in figure 2. PCI BUS PCI signals Interface module with the Altera PCI MegaCore

Altera PCI MegaCore function pci_mt32

IP core requested or sent by a user

Configuration FPGA

Target FPGA

Embedded Monitor and management Logic

CTRL DATA

Select Logic Configuration (CPLD)

JTAG Connector

FLASH

CTRL

DATA

JTAG JTAG Config In Controller

Figure 2: The proposed topology that meets the system requirements.

FPGA interacts with other embedded components, it may cause internal failures. This kind of violation or performance degradations will be detected indirectly, through the monitoring of the PCI bus signals.

7. Current Status A way to check the validity of a model is to monitor the transactions of a certain protocol being used. A violation of a protocol specification may result in system instability. In our case, most of the transactions use the PCI core interface. Therefore monitoring the internal signal transactions is an efficient way to validate the performance of an application. The violations of the PCI protocol were characterised according to the PCI bus specification (rev. 2.2) [11] and the Altera PCI MegaCore function specification. The monitor module detects violations in the communication of a configured IP core with the host over the PCI bus. The Embedded Monitor Logic is implemented by a series of state machines in hardware, which set time-out events on the communication between the Altera PCI MegaCore function and the custom IP core. The PCI bus protocol properties were transformed into monitoring rules and realized in a hardware description language (VHDL). Some events of the PCI bus protocol were studied. The challenge was to demonstrate if these events hide potential threats for our system. For example the target can suffer with a disconnect from the data if one of the following conditions occur: 1) the target is slow. It cannot deliver the subsequent data within 8 cycles, 2) the target does not support bursts, 3) the target does not understand the addressing sequence for cache line wrap, 4) the transfer crosses over the address/cache line boundary of the target. When a target disconnects with the data, an alert flag can be raised for suspicious or invalid behaviour.

7.1 An experimental Active Network An embedded module, permanently configured in one of the FPGAs of the PCI board, will monitor both the PCI interface signals and the local side signals of the Altera PCI MegaCore function. Any kind of unstable, suspicious or malicious application is considered as potential threat for the operability of the Active Router. As a consequence such applications will be terminated upon the detection of a violation. This monitoring module can prevent the system from reaching a performance critical mode. A set of rules, taken from the PCI bus specification, defines the protocol violations. If a violation is detected, then the monitor module will alert the host to stop the data transfers. In the next step the monitor module will unload the current configuration and replace it with a safe configuration bitstream. This safe configuration will restore the system’s stability. When a configured application in the

A first primitive experiment is described in the following lines based on the topology shown in figure 3. An application that is running on host A generates UDP packets having as destination host B. These packets are wrapped in host A into active packets of type 2 [13] by an Active Daemon. The module unique identification is 2. At default, the active application with module id: 1 is running in the Active Router (AR). This is an active application that changes the data of the packets’ payload to their first complement. When an active packet of type 2 (and module id=2) is transmitted from host A to host B, it will be routed by the AR. Prior to routing, the AR verifies that the active packet has module id 2 and checks which module is currently configured in the reconfigurable platform. In our case the configured application has module id=1. At that point the AR has to

make a decision: either to stop application 1 and run application 2 or to continue running the current application and just route unmodified the active packet to its destination. The AR has to check the available resources in the target platform. If they are enough it stops application 1 and loads application 2, configuring the FPGA board with the appropriate bitstream. The AR downloads the bitstream from the code server and invokes the active module no 2. This active module configures the FPGA on the fly with the appropriate bitstream and passes all consequent active packets (with module id=2) to and from the FPGA. The application that ‘runs’ in the FPGA nibble-reverses the payload data of the packets. Code Server

Host A

[3] J. Burns, A. Donlin, J. Hogg, S. Singh, M. de Wit. “A Dynamic Reconfiguration Run-Time System.”, Proceedings IEEE Symposium on FPGAs for Custom Computing Machines, April 1997, pp. 66-75. [4] O. Diessel, H. ElGindy, M. Middendorf, H. Schmeck and B. Schmidt, “Dynamic scheduling of tasks on partially reconfigurable FPGAs”, IEE Proceedings Computers and Digital Techniques, May 2000, vol. 147(3), pp. 181–188.

Firewall

Linux PC Active Router

LAN

Host B

Linux PC

[2] O. Diessel, D. Kearney and G. Wigley, “A Webbased Multi-user Operating System for Reconfigurable Computing”. In IPPS/SPDP'99 Parallel and Distributed Processing. San Juan, Puerto Rico, USA. Springer, April 1999, pp. 579-587.

Active Processing Engine

Figure 3: An Active Network with a reconfigurable processing engine.

8. Future Work The local side signals of the Altera PCI MegaCore have also to be monitored. The goal is to prevent the active application from writing to a host’s memory area, which is out of the allocated memory range, set by the OS. Also, the threats will be grouped in categories, and the Linux process running on the host will be alerted with a different interrupt for each corresponding category. Another important sub-module of the monitoring core will keep a track of the events, which happened some cycles before the present status of the monitoring module. On completion of the above development phase, the efficiency of the monitoring module will be validated when tested with the available deliberate corrupted versions of X-MatchPRO [10], and other available commercial IP cores.

9. References [1] D.L. Tennenhouse, J.M. Smith, W.D. Sincoskie, D.J. Wetherall and G.J.Minden, “A Survey of Active Network Research”, IEEE Communications, vol. 35, 1997, pp. 80-86.

[5] F. Braun, J. Lockwood, and M. Waldvogel, “Reconfigurable router modules using network protocol wrappers”, In Proceedings of Field-Programmable Logic and Applications, Belfast, Northern Ireland, Aug. 2001, pp. 254-263. [6] I. Hadzic and J. M. Smith, “On-the-fly Programmable Hardware for Networks”, In Proc. Globecom '98, IEEE, Sidney, Australia, November 1998. [7] “Architecting Systems for Upgradability with IRL”, Xilinx Application Note, June 2001, (www.xilinx.com/xapp/xapp412.pdf) [8] “Using Remote System Configuration with Stratix Devices”, Altera Application Note(AN 217), November 2002. (www.altera.com/literature/an/an217.pdf) [9] “PCI MegaCore Function User Guide”, Altera, 2002 (www.altera.com/literature/ug/ug_pci.pdf) [10] J.L. Núñez, C. Feregrino, S. Jones, S. Bateman, “X-MatchPRO: A ProASIC-Based 200 Mbytes/s FullDuplex Lossless Data Compressor”, In Proceedings of FPL 2001, Lecture Notes in Computer Science, Springer, August 2001, pp. 613-617. [11] “PCI Local Bus Specification, Revision 2.2”, PCI Special Interest Group, December 1998. [12] GIDEL PROC20KE board, DN3000k10AS board (www.gidel.com/proc20ke.htm),(www.dinigroup.com/p roducts/3000k10as.html) [13] A.G. Fragkiadakis, N.G. Bartzoudis, D.J. Parish and M.J. Sandford, “Hardware Support for Active Networking”, In Proceedings of The 2003 International Multiconference in Computer Science & Engineering (SAM'03), Las Vegas, U.S.A., June 2003.