Electronic Design

GP OSs Add Security Systems To Embedded Systems

For decades, embedded systems consisted of special-purpose hardware running special-purpose software. Field upgrades involved changing pin settings, replacing EPROMs, etc. But the commoditization of hardware, software, and programmers has added a flexibility that often works like a two-edged sword. While this flexibility eases development of embedded systems, it comes at the cost of increased difficulty in meeting a fundamental requirement: An embedded system should continue to work as shipped.

Today, embedded systems are built on general-purpose operating systems (GP OSs) intended for embedded systems, such as MontaVista Linux, or completely general operating systems, like Windows XP or Windows 2003 Server. Some embedded systems are actually general-purpose computers. They can run a wide variety of code and can be easily reconfigured by anyone with access to the system.

Commodity OS platforms provide general-purpose services accessible via standardized interfaces, such as process control, file systems, and networking protocols. Although very convenient for developing embedded software, the shipped systems retain the ability to run a world of other software developed for the particular open platform regardless of that code's origin, intent, and impact. Unfortunately, such code can take the form of viruses, worms, spyware, or malware. The OS interface is widespread and standardized, so any security exploit that works on a given platform is a potential threat to all embedded systems built on that platform.

In addition, fielded systems can mutate as a result of OS patches, software patches, new software installation, updates of existing software, and modification of configuration files or databases, to name a few. Such field modifications can create significant problems, ranging from increased resource consumption and decreased performance (perhaps affecting real-time functions) to simply breaking the system's primary embedded software.

Today, there are several ways to address these issues. In one possible but impractical approach, the embedded system vendor tailors the OS to provide only the support required by the embedded system. While this may reduce (though not eliminate) the risk of security vulnerabilities, the vendor becomes the OS developer and loses the benefit of leaving such work to the OS vendor.

In another approach, the vendor uses a standard OS but shifts OS security maintenance to customers. Even if customers accept responsibility for OS security updates, once the OS vendor releases a patch, the embedded system vendor must immediately apply the patch and perform regression tests. Even worse, if the patch breaks the embedded system, the vendor is in the awkward position of advising customers not to apply the patch while at the same time being unable to offer a practical security alternative.

Vendors would rather focus on developing core embedded system functionality and use third-party security products to "harden" their systems. But today's third-party products are limited to antivirus, local firewalls, or intrusion detection, for instance, and are not specifically designed for embedded systems. Such security products can behave inappropriately, such as an antivirus warning pop-up on the screen of a parking payment kiosk, or impose operational practices that do not fit the end customers' deployment requirements, like needing Internet access to receive signature or policy updates. In most cases, these security products have a significant impact on system performance.

Solving such complex control issues in elegant and non-intrusive ways requires new enabling technology based on a fundamentally new approach to control. Ideally, such technology lets vendors build their embedded systems on open industry-standard platforms while realizing full stability, security, and support via total control over the run-time environment. Advantages would include leveraging the efficiencies of building on standard platforms, as well as immunity from malicious attacks and inadvertent harmful action, while retaining the freedom to deploy embedded systems in a manner consistent with highly differentiated, closed proprietary systems. Such enabling technology sounds like a tall order, but it may be on the way.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.