Viruses and Embedded DesignsWhether you like it or not, in the net-centric computing environment the embedded designer must accept its openness. Here's the problem. Unlike the traditional environment where the designer can control the environment by locking the doors, in the new house in which his application must live the doors are open, unlocked, or non-existent.
A wide-open environment has a number of implications, but the one I have been thinking about is the problem of computer viruses. How likely is it that an Internet-enabled embedded device, an information appliance, or an embedded Internet device will become infected? And if one does get infected, what protection does the software contained in the device have against it?
In the near future, the number of viruses likely to invade Internet-accessible devices will be fairly small. First, a virus creator not only needs to have a knowledge of programming in the language in which the application is written, but must also be knowledgeable about the particular operating system and its application programming interface. The reason Windows is so much of a target is that it is ubiquitous and a lot of people understand it. In the net-centric computing device market, there is no one standard operating system and API, with two exceptions, so the number of people knowledgeable enough to build a virus that infects a specific OS is pretty small.
One of the exceptions, Java, along with its virtual machine (VM), was designed with the specific aim of being a universal processor-and-operating-system-independent platform (write once, run everywhere). While Java is more or less OS independent, one reason that few Java viruses have appeared is that the language is relatively new, and there aren't a lot of programmers with the expertise to write these viruses. Second, because it was designed from the very beginning to simplify the creation of applets downloadable to any system, Sun has put extensive work into making it as immune to viruses as possible.
The other exception, however, I am not sure about. Windows CE is still a relatively young operating system, and despite the convolutions Microsoft goes through with the market numbers to make us believe it is a leading operating system in the net-centric consumer device market, it hasn't been deployed as widely as Java. However, it has the same API as desktop Windows and many of the operating system features are identical to those on its older, desktop brothers. So virus creators who learned their tricks on the desktop, the server or the workstation can shift their attention to the youngster of the family, WinCE.
Most of the current mobile net-centric computing device worms and viruses have targeted PalmOS-based devices, not CE-based ones because Palm devices have been around longer and constitute the majority of the market right now. During the past year four infections have affected Palm devices: the Liberty Crack, the Phage, Vapor, and a Visual Basic script worm. During the same time frame new viruses appeared on the desktop nearly every week.
But even if the industry can reduce the likelihood of viruses infecting the new generation of net-centric devices to one-hundredth of one percent of that on Windows systems, the numbers are against us.
Currently there are about 100 million Internet users, of whom 55 million access the Internet and World Wide Web at least two to three times a day, mostly from desktop systems. The variety of net-centric computing devices is likely to grow at least ten-fold by the end of the decade. Given that there will likely be dozens of Internet-enabled embedded devices populating our lives, the number of users and devices accessing the Web is likely to skyrocket.
Even if we assume a very small number of devices being infected, say one tenth of one percent, given the potentially huge size of the Internet user population, this is still a huge number of systems.
Embedded developers and the tool and OS vendors I have talked to have made roughly the same calculations. It is not surprising that all of them are going back to see what's in their tool kits and in operating systems that might help.
The shift from flat RTOSes to more nuanced, layered OS implementations with memory management, segmentation, and protection capabilities offers some promise. Memory segmentation allows the separation of the operating system and each of the applications into its own protected memory address space, so that if an application fails it doesn't bring down the other applications or the operating system. Some operating systems are extremely fine-grained, allowing the protection of individual processes and threads. The same mechanisms that protect a system from a badly designed or buggy application can also protect a system if a virus happens to get in.
However, memory protection and segmentation features are costly in a number of respects. Memory management requires more memory and it often slows down the operation of the processor. It also drives up the cost of the system under development. A processor with memory management is more expensive than one without it. More memory and more memory accesses also pushes up the power consumption.
While these aspects of memory protection are acceptable on the desktop and the server and in routers and switches, it rules out the use of such traditional techniques on many of the net-centric computing applications requiring a small memory foot print, low power, and low cost. So I have been looking around for features of existing embedded software and hardware that can be turned to the developer's advantage in the fight against potential virus incursions, but that do not require much memory or processor overhead.
One such feature is version stamping, which is implemented in Microware's OS9 and a few other operating systems. Version stamping uses an error-checking code scheme to ensure that the right version of a driver is connected with the right version of another software component. All of the components in a particular version of the OS (or which were designed to work with it) have the same code sequence. So when a virus penetrates a system, the act of attaching itself to or replacing some component changes the component's code so that it no longer matches when error checking is done.
Other operating systems, such as Green Hill's Integrity, have, in addition to memory segmentation, time and space domain protection. Even when the smallest possible implementation of the OS is used, these last two features are still available to developers in a memory-constrained application. Used to limit the damage that a badly written application could do and to prevent its taking up memory space it shouldn't or staying too long, such capabilities can be used to protect against viruses as well.
Some of the new processors aimed at the consumer-oriented net-centric computing device space also have features built in that directly or indirectly aid in dealing with viruses. For example, aJile Corp.'s new processor implements not just one, but two Java virtual machines in silicon. The primary aim of this configuration is to allow multiple versions of the VM to be active. It also allows one VM to deal with human interface and Internet communications, leaving the other to do control functions unimpeded. The equivalent of a software brick wall separates the two, so that if a virus is introduced from the network, the primary control functions of the processor are not affected.
Although it was designed for use primarily in the Java environment, you can take advantage of this dual VM in hardware approach in other environments as well: Java on one side and C/C++ on the other, or various combinations of C/C++ without using Java at all. Although designed for Java code, VM executes C or C++ code, but not very fast. In an application requiring only C or C++, the virus protection capabilities of the VM brick wall could be used.
I'm sure there are more clever ways to add virus protection to small footprint applications, and I would like to hear about them. If you are a developer and have found an innovative technique let me know. If you are an OS or tool vendor whose products have these capabilities, I interested in talking to you. If you have an opinion, pro or con, let me know and we can talk about it in this column.