Sphere:  |  Tags: , , ,

What is virtualization?

Virtualization has been in use in compute servers for decades. IBM’s VM/370 provided the image of a complete hardware mainframe to a guest operating system, potentially with more memory and resources than the actual hardware that VM/370 ran on. As VM/370 would have to keep spooling the virtual memory to disk, the actual performance would far lower than a dedicated machine. However, in most respects, the guest operating system saw a ‘real’ machine. Virtualization made it possible to mix batch and interactive compute jobs on the same machine, saving the cost of buying additional dedicated mainframes.

Originally employed to deal with the high cost of compute hardware, virtualization has re-emerged as a potential answer to high energy usage in servers, and for security and resource optimization in embedded systems.

Virtualization makes it more economical to consolidate multiple server computers into a single blade. Because many servers run well below full capacity, consolidation not only cuts costs but improves power consumption. As each server draws close to full power even when running an idle loop, improving processor utilization by bringing multiple environments onto the same machine is more energy efficient.

A similar principle has been applied to low-end smartphones where virtualization is, invisible to the consumer, being used to cut the bill of materials. A popular approach to smartphone design, for example, splits responsibilities between at least two microprocessors. On one, a real-time operating system (RTOS) running on the baseband processor co-ordinates the interface between the phone and the wireless network. The other processor, usually a higher-performance model, is one intended to run user-visible operating systems such as Android, Apple’s iOS or Windows Phone 7.

Why is it useful?

Similar to the situation for compute servers, the baseband processor is often underused in a multicore handset, leaving some spare capacity for the applications-oriented operating system. According to Open Kernel Labs, one of the suppliers of hypervizors for mobile phones, it is feasible to run an Android installation on a 200MHz ARM926 with 128MB of memory alongside the baseband RTOS.

A further argument for using virtualization in embedded systems is software portability. Application writers can develop code for a generic canonical machine that will run on any platform that can emulate the behaviour of that machine even if the physical implementation has completely different registers and memory maps. This should reduce the cost of porting code to new hardware as only low-level firmware needs to change – something that phone vendors with large hardware portfolios are keen to have.

Conventionally, embedded systems have used forms of virtualization primarily for resilience. An example is the ARINC 653 executive for avionics systems. This provides slices of time for guest operating systems, ensuring that one environment does not starve another of processor time.

Because it offers the ability to seal off guest operating systems from physical I/O, virtualization has acquired the image of making embedded systems more secure. This is only partially true. As long as the hypervizor is secure, it’s true. But it is easy to introduce sneak paths that allow attacks to sneak through, particularly through device drivers. Because drivers need low-level access to peripherals, they often need to run in a privileged mode. If they are not sufficiently protected against attacks such as buffer overflows, they can provide a means for a hacker to take control of the entire machine by acting as a trap door into the hypervizor functions.

One advantage that a hypervizor has in terms of security is that its codebase can often be much smaller than that of a full operating system, making it more amenable to intensive testing and formal verification. And the hypervizor can block calls to peripherals that are deemed potentially harmful or remove access to ports that should not be available to unprivileged code.

By locking down parts of the hardware, it becomes possible to use a wider range of software in systems that previously only had access to a highly restricted approved list of operating systems and applications. For example, industrial control and military systems can make use of the user-interface development tools available for Android and similar products but leave vital functions to a dedicated RTOS.

Comments are closed.


Synopsys Cadence Design Systems Siemens EDA
View All Sponsors