The chapter expands on a usage of context based polymorphism, in other words, reasoning over CFG, as a ground to implement application level virtualization. One way to approach virtualization problem is to model it in terms of satisfying constraints imposed by environment over agents that operate within it, as presented below: sizo (distorted abbreviation of SEcurity ZOne) — logical entity introduced to represent environment and describe desired virtualization outcome. zek (distorted abbreviation of SEcurity aGent) — represents behaviour of the code in terms of virtualized resources access. Basic idea is to automatically reason over information defined by sizos and zeks and produce virtualization plan as a solution that dictates which parts of code should be virtualized and how exactly. Such reasoning enables two features: Optimization. Allows choosing virtualization technique with a least performance penalty nevertheless satisfying necessary requirements. Safety. Validates manually chosen virtualization plan to be safe and sound by checking that it indeed satisfies requirements. In other words, context based reasoning provides improvements by virtualizing only necessary sections of code, only for necessary type of resources and by employing as lightweight as possible virtualization strategy just enough to comply with safety and security requirements expressed by annotations in the code.

Virtualization refers to an abstracting code from underlying resources used by it. Here term resource depicts any external entity such as devices, files, network connections, etc, for which it is desirable to regulate access. Virtualization is a vast area and broad term that includes number of techniques on different levels to achieve several important goals such as: Shared access — to allow several clients use the same resource while behaving as if each client is the sole resource user simplifying development and testing. Isolation — cornerstone of safety and behaviour repeatability achieved by minimizing influence of isolated clients between each other and external environment. Adaptation — to allow client application work within an unexpected environment it was not developed for, by emulating "native" familiar environment thus reducing adaptation and support costs. Due to importance of goals achievable with virtualization, it is unavoidable in a long run. That being said, basic virtualization techniques have performance penalties arising from indirect and regulated access to underlying resources. Further discussion is concerned with what can be done to alleviate major virtualization inefficiencies by fine-grained control over what, when, and how should be virtualized.

Whole program can be broken down into one or more virtualization zones, each having different appropriate type of virtualization strategy. Such approach allows to model hybrid virtualization, i.e. different parts of program are virtualized differently depending on some conditions. To capture this concept, term sizo is introduced and refers to a logical entity that holds information about particular zone necessary to find best suited virtualization strategy. Sizo is associated with context, i.e. each zone spans over one or more code blocks. There is a annotation assign_sizo to specify sizo a code block is assigned to: SYNTAX: **assign_sizo**(//sizo-ref//). sizo-ref unique sizo's identifier Next thing is to specify which resources a particular sizo controls access to, as below: SYNTAX: **assign_sizo_control**(//resource-type//). It indicates that current sizo(sizo that spans over code block the annotation located within) regulates all access to a resources of a given type resource-type. Conversely, If for a particular environment there is no need to control, for example, file system access, no virtualization for file operations is applied. On the other hand, there is an annotation to mark function that accesses one or another resource: SYNTAX: **assign_zek_access**(//resource-type//). Let's consider an example to demonstrate all above: name="tests/virtualization.cpp: Virtualization.Doc_AccControl_1", lines=15 import raw ("scripts/cfa/context.lp"). //enable context reasoning import raw ("scripts/virtualization/virtualization.lp"). //enable virtualization reasoning guard:: strategy(direct) { openFile = function(filename::string):: int { printf("direct file access") } } guard:: strategy(common) { openFile = function(filename::string):: int; assign_zek_access(files) { printf("virtualized file access") } } main = function:: int; entry { context:: assign_sizo(zoneA); assign_sizo_control(files). openFile("/some/file") } Example outlines dummy function openFile to model file system access. The function has two specializations with guards strategy(direct) to model direct access, and strategy(common) to be invoked if virtualization is enabled. It also annotated with assign_zek_access(files) to indicate that it accesses file system. On the other hand, context of function main defines sizo zoneA and enables control over file operations. Reasoning works with provided information and decides whether it is necessary to enable virtualization. In this case, the answer is yes for zoneA, because of the fact that sizo controls file operations and there is actually function within the sizo that requires files access. Consequently, example outputs:virtualized file accessconfirming that specifically virtualized specialization of openFile was invoked.

As shown in the previous section, it is possible to enable(or disable) virtualization on per resource basis. However such functionality is limited in a sense that if several sizos allow access to the same resource they can interfere with each other. Thus, next step to consider is isolation, i.e. zeks in different sizos should not have ability to access the same resource, but rather work with their own set of resources associated with particular sizo. As previously, following examples are focused on file operations as most ubiquitous type of resources. One way to isolate file access is to associate unique file prefix with each sizo. If virtualization enabled, all filenames in the sizo are silently transformed on the fly by adding assigned prefix. This way, all the file operations from one sizo are confined within specific directory allocated solely for that particular sizo or simply have unique prefix if the same directory contains files belonging to a different sizos. name="tests/virtualization.cpp: Doc_Isolation_1", lines=15 main = function:: int; entry { seq { context:: assign_sizo(domainA); assign_sizo_control(files). openFile("test") } { context:: assign_sizo(domainA). openFile("test") } { context:: assign_sizo(domainB); assign_sizo_control(files). openFile("test") } } In this example file test is accessed from different sizos domainA and domanB. As there are several "competing" sizos are declared, they are isolated and openFile resolves test to a different filename depending on from which sizo it is called. One possible way to implement discussed strategy shown below: name="tests/virtualization.cpp: Doc_Isolation_1", lines=15 import raw ("scripts/cfa/context.lp"). //enable context reasoning import raw ("scripts/virtualization/virtualization.lp"). //enable virtualization reasoning import raw ("scripts/virtualization/test-Isolation_1.assembly.lp"). //additional configuration DictSizo = type slave dict_sizo. Sizo = type slave virt_sizo. guard:: strategy(direct) { resolveFilename = function(filename:: string):: string; assign_zek_access(files) { filename } } guard:: strategy(prefix) { resolveFilename = function(filename:: string):: string; assign_zek_access(files) { dictSizo = intrinsic query("dict_sizo")::[DictSizo]. sizoId = intrinsic query late("sizo_current"->sizoCurrent:: Sizo):: int; demand(sizo) { loop fold(dictSizo->entry::DictSizo, 0->id):: int { if(entry[0] == sizoCurrent):: int { entry[1] } else { id } } }. buf = "00"::string. seq { sprintf(buf, "%d/%s", sizoId, filename) } { buf } } } openFile = function(filename:: string):: int { filenameReal = resolveFilename(filename):: string. printf("File opened: '%s'%c", filenameReal, 10) } Example outputs: File opened: '0/test' File opened: '0/test' File opened: '1/test' In this example function openFile calls resolveFilename to find out real filename. It can be said, that resolveFilername serves as hypervisor dereferencing file pseudonym into real filename. In order to do that, resolveFilername consists of two specializations: specialization strategy(direct) serves non virtualized environmentб leaving filename without any processing, and the other specialization strategy(prefix) implements resolving strategy by adding sizo-associated prefix to each file. More specifically, unique index is assigned to each sizo and resolveFilename uses the index as file name prefix. Resolution function resolveFilename has only one parameter filename, deriving required prefix from late context associated with particular sizo. Client code has no way to influence resolving process and force to use unapproved prefix, thus accessing and interfering with files that belong to other sizos.

Every optimization technique applicable only if some specific preconditions are met. Indeed, only general approach can handle general task. However, for practical instances there are always some improvements possible by tailoring to the particular use case specifics and subtle details. In other words, the more information available the more space for improvements is there. And first step on this road is the very ability to express and reason about such additional information. As a demonstration, in order to improve reasoning to find out optimal virtualization strategy for particular use case, different sizo categories can be introduced, as below: Inward Isolation. The category describes sizo that prohibits access from other sizos to its internal resources, but able to access external resources freely. For example, monitoring and supervision software may have been assigned this type of isolation — freely accesses subordinate zones but can't be influenced from the outside. Outward isolation. The exact opposite of inward isolation. Allows access from external sizos but is only allowed to use its own internal resources, so no influence to the outside world is possible. Appropriate for various sandboxes and testing environments to run possibly insecure code. For file operations inward isolation may be implemented as virtualization strategy that requires from other sizos compulsory usage of file prefixes so no other sizo can access internal data of inwardly isolated sizo. Conversely, outward isolation is compatible with strategy that assigns prefix for this very sizo, so it can in no way access any external data, being at the same time exposed to the outside world for any sizo that have permission to know unique assigned prefix able to access internal data of sizo in question. To put it simply, strategy for these types can be described with following points: Inward isolation — requires prefixes for other sizos. Outward isolation — requires prefix for itself. There is an annotation introduced to declare category for the current sizo: SYNTAX: **assign_sizo_category(inward)**. **assign_sizo_category(outward)**. Consider the example below: name="tests/virtualization.cpp: Doc_IsolationCat_1", lines=15 test = function:: int; entry { seq { context:: assign_sizo(zoneA); assign_sizo_control(files); assign_sizo_category(inward). openFile("test1") } { context:: assign_sizo(zoneB); assign_sizo_control(files); assign_sizo_category(outward). openFile("test1") } } There are two sizos declared in the code above. Using reasoning apparatus developed in previous sections, both sizos activate virtualization, for both of them control file resources and both contain openFile that actually requires file access. However, this time additional bits of information are available, namely zoneA and zoneB declared as inward and outward, respectively. By strategy outlines above, zoneA enables prefix based isolation strategy for zoneB, and zoneB enables isolation for itself as well. As a result, it's enough to virtualize only one zone(zoneB) leaving zoneA to enjoy direct access to file resources. Example output's is shown below, confirming that direct file access is granted for zoneA: File opened: 'test1' File opened: '1/test1'