OVERVIEW

In this the penultimate virtualisation article, we look at key aspect of virtualisation security; memory design.

BEYOND THE VENDOR GLOSS

Virtualised resources and appliances are now a major revenue stream for a number of vendors, virtual resources are widely deployed in a number of sectors, and this is a trend that is expected to continue. Virtualised resources are being deliberately targeted at those organisations that wish to make cost savings, and are mooted by many as being a secure, flexible and high availability technology. Beyond the vendor gloss however, virtualised resources suffer from many of the same issues that currently face conventional networked infrastructure, and have challenges that are unique.

STALLING THE CPU

It is a difficult to discuss virtualisation as a subject area without first considering computer memory design models, as both virtualised platforms and resources are reliant upon virtual memory models. Although there are a number of memory models that have been employed with regard virtualised technologies and parallel computing modern CPUs still run faster than the main memory that they may be attached to. To avoid CPUs stalling, and becoming memory starved, a number of research projects have been undertaken to allow for high speed memory access for CPUs. NUMA (Non-Uniform Memory Allocation) is one of many such memory models, and attempts to provide separate memory for each processor, and thus avoid the difficulties inherent in multi-processor environments. NUMA become problematic when considered in relation to the von Neumann architecture programming model and its attendant bottleneck. In the von Neumann model, a processing unit, and a single storage area for data and instructions are separated. This separation between CPU and memory leads to a scenario whereby there is limited throughput between the CPU and memory compared to the available amount of memory, and subsequently the CPU stalls, consequently there have been limited implementations of NUMA.

CACHE FLOW

Cache Coherent NUMA (CCNUMA) was introduced, and is widely deployed as the memory model of choice in a number of assets. CCNUMA seeks to maintain the integrity of data that is stored within the local cache controllers of shared resources, as well as that stored in the memory of multiprocessor systems. CCNUMA is used in the majority of current cluster computing models and virtualised resources and servers including HP Superdomes and Integrity Servers, as well as assets produced by Sun and IBM. CCNUMA utilises both local physical nodal and remote, shared memory to complete data transaction processes. When local memory is full, CCNUMA architecture allocates remote memory pages to facilitate CPU access and recall.  In a HP Superdome virtualised resource, the composition is as follows

Figure 1: Components of a HP Superdome

HP Superdomes can be broken down into a number of distinct components:

In the current HP model if an individual processor cannot write to another processor instances within a cell, it will attempt to write to its neighbours with the proviso that data will not cross more than two crossbar instances. The CCNUMA implemented within Superdomes utilises locality domains (LDOM) to control logic domains, but also data flows. In relation to how these relate to virtualised resources, each LDOM may consist of a separate, independent domain and a related collection of processors and memory, or in relation to data flows specifically, data will be passed quicker between two adjoining cells or processors than those situated elsewhere in the architecture.  Within the context of this architecture, local memory is restricted to the storage of private objects and data structures.  However, this does not imply that it cannot be accessed by other processor instances. The main local memory restriction being that the further a processor is away from the memory instance, the longer access will take.  Many vendors employ this working model with regards to virtualised resources however it is not without a potentially security flaw.

INJECTING MALICIOUS CODE

It may be possible utilising the model detailed in Figure 1, for malicious code to not only impact upon the memory of individual cells/processors but also the interleaved and local memory of all cells within the environment. Rather than the injection of a malicious code base into an individual processor memory instance, it possible for an attacker to inject and infect all memory instances in the virtualised resource environment.  It should be noted that many implementations of virtualised resources, are in fact acting in one form or another as a replacement for a conventional local area network, with associated application, application server and database instances. Therefore, if an application enters an error state, becoming a ‘processor hog’ it may impact significantly the integrity/stability of associated processors both within an individual cell, and beyond.

A number of protections are exist to prevent the scenario detailed above within commercially available virtualised resources. However, these are by no means universal, and many protection mechanisms may well be treated as commercially sensitive by technology vendors. The principle holds true however, that memory within a virtualised resource is no different to that which is associated with a monolithic memory instance with a number of processors attached to it. In the latter scenario if an attacker (or their code base) can gain privileged access to an individual processor they can write to the shared memory space and corrupt execution flows. There is however one significant differential between these two scenarios, namely that a virtualised resource may well be operating in the capacity of a fully networked instance. Rather than impacting upon the stability of an individual system component within a LAN.  If the hypothetical attack can be enacted, it has the potential to impact upon the security of the whole network. Consequently, the impact of malicious increases thanks to shared and interleaved memory areas within the virtualised resource.

NEXT TIME…

In our final article we discuss the wider security implications of virtualisation for business.