virtualization.xml
No OneTemporary
Actions

Subscribers

None

File Metadata

Created: Thu, Jul 9, 6:39 AM

virtualization.xml
View Options

	<?xml version="1.0" encoding="UTF-8"?>
	<chapter version="5.1" xmlns="http://docbook.org/ns/docbook"
	xmlns:xlink="http://www.w3.org/1999/xlink"
	xmlns:xila="http://www.w3.org/2001/XInclude/local-attributes"
	xmlns:xi="http://www.w3.org/2001/XInclude"
	xmlns:trans="http://docbook.org/ns/transclusion"
	xmlns:svg="http://www.w3.org/2000/svg"
	xmlns:m="http://www.w3.org/1998/Math/MathML"
	xmlns:html="http://www.w3.org/1999/xhtml"
	xmlns:db="http://docbook.org/ns/docbook">
	<?xxe-sn 26yv439af40 1k?>

	<title><?xxe-sn 26yv439af40 1l?>Virtualization</title>

	<para><?xxe-sn 26yv439af40 1m?>The chapter expands on a usage of context
	based polymorphism, in other words, reasoning over CFG, as a ground to
	implement <emphasis><?xxe-sn 26yv439af40 1n?>application level
	virtualization</emphasis>.</para>

	<para><?xxe-sn 26yv439af40 1o?>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:</para>

	<itemizedlist>
	<?xxe-sn 26yv439af40 1p?>

	<listitem>
	<?xxe-sn 26yv439af40 1q?>

	<para><?xxe-sn 26yv439af40 1r?><emphasis><?xxe-sn 26yv439af40 1s?>sizo</emphasis>
	(distorted abbreviation of SEcurity ZOne) — logical entity introduced to
	represent environment and describe desired virtualization
	outcome.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 1t?>

	<para><?xxe-sn 26yv439af40 1u?><emphasis><?xxe-sn 26yv439af40 1v?>zek</emphasis>
	(distorted abbreviation of SEcurity aGent) — represents behaviour of the
	code in terms of virtualized resources access.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26yv439af40 1w?>Basic idea is to automatically reason over
	information defined by sizos and zeks and produce <emphasis><?xxe-sn 26yv439af40 1x?>virtualization
	plan</emphasis> as a solution that dictates which parts of code should be
	virtualized and how exactly. Such reasoning enables two features:</para>

	<itemizedlist>
	<?xxe-sn 26yv439af40 1y?>

	<listitem>
	<?xxe-sn 26yv439af40 1z?>

	<para><?xxe-sn 26yv439af40 20?>Optimization. Allows choosing
	virtualization technique with a least performance penalty nevertheless
	satisfying necessary requirements.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 21?>

	<para><?xxe-sn 26yv439af40 22?>Safety. Validates manually chosen
	virtualization plan to be safe and sound by checking that it indeed
	satisfies requirements.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26yv439af40 23?>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.</para>

	<section>
	<?xxe-sn 26yv439af40 24?>

	<title><?xxe-sn 26yv439af40 25?>Background</title>

	<para><?xxe-sn 26yv439af40 26?><emphasis><?xxe-sn 26yv439af40 27?>Virtualization</emphasis>
	refers to an abstracting code from underlying <emphasis><?xxe-sn 26yv439af40 28?>resources</emphasis>
	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.</para>

	<para><?xxe-sn 26yv439af40 29?>Virtualization is a vast area and broad
	term that includes number of techniques on different levels to achieve
	several important goals such as:</para>

	<itemizedlist>
	<?xxe-sn 26yv439af40 2a?>

	<listitem>
	<?xxe-sn 26yv439af40 2b?>

	<para><?xxe-sn 26yv439af40 2c?>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.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 2d?>

	<para><?xxe-sn 26yv439af40 2e?>Isolation — cornerstone of safety and
	behaviour repeatability achieved by minimizing influence of isolated
	clients between each other and external environment.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 2f?>

	<para><?xxe-sn 26yv439af40 2g?>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.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26yv439af40 2h?>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.</para>

	<para><?xxe-sn 26yv439af40 2i?>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.</para>
	</section>

	<section>
	<?xxe-sn 26yv439af40 2j?>

	<title><?xxe-sn 26yv439af40 2k?>Access Control</title>

	<para><?xxe-sn 26yv439af40 2l?>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 <emphasis><?xxe-sn 26yv439af40 2m?>hybrid
	virtualization</emphasis>, i.e. different parts of program are virtualized
	differently depending on some conditions. To capture this concept, term
	<emphasis><?xxe-sn 26yv439af40 2n?>sizo</emphasis> is introduced and
	refers to a logical entity that holds information about particular zone
	necessary to find best suited virtualization strategy.</para>

	<important>
	<?xxe-sn 26yv439af40 2o?>

	<para><?xxe-sn 26yv439af40 2p?>Sizo is associated with <link
	xlink:href="/w/concepts/context"><?xxe-sn 26yv439af40 2q?>context</link>,
	i.e. each zone spans over one or more code blocks.</para>
	</important>

	<para><?xxe-sn 26yv439af40 2r?>There is a annotation <code><?xxe-sn 26yv439af40 2s?>assign_sizo</code>
	to specify sizo a code block is assigned to:</para>

	<synopsis><?xxe-sn 26yv439af40 2t?>SYNTAX:
	assign_sizo(//sizo-ref//).</synopsis>

	<itemizedlist>
	<?xxe-sn 26yv439af40 2u?>

	<listitem>
	<?xxe-sn 26yv439af40 2v?>

	<para><?xxe-sn 26yv439af40 2w?><emphasis><?xxe-sn 26yv439af40 2x?>sizo-ref</emphasis>
	unique sizo's identifier</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26yv439af40 2y?>Next thing is to specify which resources a
	particular sizo controls access to, as below:</para>

	<synopsis><?xxe-sn 26yv439af40 2z?>SYNTAX:
	assign_sizo_control(//resource-type//).</synopsis>

	<para><?xxe-sn 26yv439af40 30?>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 <emphasis><?xxe-sn 26yv439af40 31?>resource-type</emphasis>.
	Conversely, If for a particular environment there is no need to control,
	for example, file system access, no virtualization for file operations is
	applied.</para>

	<para><?xxe-sn 26yv439af40 32?>On the other hand, there is an annotation
	to mark function that accesses one or another resource:</para>

	<synopsis><?xxe-sn 26yv439af40 33?>SYNTAX:
	assign_zek_access(//resource-type//).</synopsis>

	<para><?xxe-sn 26yv439af40 34?>Let's consider an example to demonstrate
	all above:</para>

	<programlisting xml:id="AccControl_1"><?xxe-sn 26yv439af40 35?>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")
	}</programlisting>

	<para><?xxe-sn 26yv439af40 36?>Example outlines dummy function
	<code><?xxe-sn 26yv439af40 37?>openFile</code> to model file system
	access. The function has two specializations with guards <code><?xxe-sn 26yv439af40 38?>strategy(direct)</code>
	to model direct access, and <code><?xxe-sn 26yv439af40 39?>strategy(common)</code>
	to be invoked if virtualization is enabled. It also annotated with
	<code><?xxe-sn 26yv439af40 3a?>assign_zek_access(files)</code> to indicate
	that it accesses file system. On the other hand, context of function
	<code><?xxe-sn 26yv439af40 3b?>main</code> defines sizo <code><?xxe-sn 26yv439af40 3c?>zoneA</code>
	and enables control over file operations.</para>

	<para><?xxe-sn 26yv439af40 3d?>Reasoning works with provided information
	and decides whether it is necessary to enable virtualization. In this
	case, the answer is yes for <code><?xxe-sn 26yv439af40 3e?>zoneA</code>,
	because of the fact that sizo controls file operations and there is
	actually function within the sizo that requires files access.
	Consequently, example outputs:<screen xml:id="Output_AccControl_1"><?xxe-sn 26yv439af40 3f?>virtualized file access</screen>confirming
	that specifically virtualized specialization of <code><?xxe-sn 26yv439af40 3g?>openFile</code>
	was invoked.</para>
	</section>

	<section>
	<?xxe-sn 26yv439af40 3h?>

	<title><?xxe-sn 26yv439af40 3i?>Isolation</title>

	<para><?xxe-sn 26yv439af40 3j?>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 <emphasis><?xxe-sn 26yv439af40 3k?>isolation</emphasis>,
	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.</para>

	<para><?xxe-sn 26yv439af40 3l?>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.</para>

	<programlisting xml:id="Isolation_1"><?xxe-sn 26yv439af40 3m?>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")
	}
	}</programlisting>

	<para><?xxe-sn 26yv439af40 3n?>In this example file <code><?xxe-sn 26yv439af40 3o?>test</code>
	is accessed from different sizos <code><?xxe-sn 26yv439af40 3p?>domainA</code>
	and <code><?xxe-sn 26yv439af40 3q?>domanB</code>. As there are several
	"competing" sizos are declared, they are isolated and <code><?xxe-sn 26yv439af40 3r?>openFile</code>
	resolves <code><?xxe-sn 26yv439af40 3s?>test</code> to a different
	filename depending on from which sizo it is called. One possible way to
	implement discussed strategy shown below:</para>

	<programlisting xml:id="Isolation_2"><?xxe-sn 26yv439af40 3t?>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)
	}</programlisting>

	<para><?xxe-sn 26yv439af40 3u?>Example outputs:</para>

	<screen xml:id="Output_Isolation_1"><?xxe-sn 26yv439af40 3v?>File opened: '0/test'
	File opened: '0/test'
	File opened: '1/test'
	</screen>

	<para><?xxe-sn 26yv439af40 3w?>In this example function <code><?xxe-sn 26yv439af40 3x?>openFile</code>
	calls <code><?xxe-sn 26yv439af40 3y?>resolveFilename</code> to find out
	real filename. It can be said, that <code><?xxe-sn 26yv439af40 3z?>resolveFilername</code>
	serves as <emphasis><?xxe-sn 26yv439af40 40?>hypervisor</emphasis>
	dereferencing file pseudonym into real filename. In order to do that,
	<code><?xxe-sn 26yv439af40 41?>resolveFilername</code> consists of two
	specializations: specialization <code><?xxe-sn 26yv439af40 42?>strategy(direct)</code>
	serves non virtualized environmentб leaving filename without any
	processing, and the other specialization <code><?xxe-sn 26yv439af40 43?>strategy(prefix)</code>
	implements resolving strategy by adding sizo-associated prefix to each
	file. More specifically, unique index is assigned to each sizo and
	<code><?xxe-sn 26yv439af40 44?>resolveFilename</code> uses the index as
	file name prefix.</para>

	<para><?xxe-sn 26yv439af40 45?>Resolution function <code><?xxe-sn 26yv439af40 46?>resolveFilename</code>
	has only one parameter <code><?xxe-sn 26yv439af40 47?>filename</code>,
	deriving required prefix from <emphasis><?xxe-sn 26yv439af40 48?>late
	context</emphasis> associated with particular sizo.</para>

	<important>
	<?xxe-sn 26yv439af40 49?>

	<para><?xxe-sn 26yv439af40 4a?>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.</para>
	</important>
	</section>

	<section>
	<?xxe-sn 26yv439af40 4b?>

	<title><?xxe-sn 26yv439af40 4c?>Isolation Categories</title>

	<para><?xxe-sn 26yv439af40 4d?>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.</para>

	<para><?xxe-sn 26yv439af40 4e?>As a demonstration, in order to improve
	reasoning to find out optimal virtualization strategy for particular use
	case, different <emphasis><?xxe-sn 26yv439af40 4f?>sizo
	categories</emphasis> can be introduced, as below:</para>

	<itemizedlist>
	<?xxe-sn 26yv439af40 4g?>

	<listitem>
	<?xxe-sn 26yv439af40 4h?>

	<para><?xxe-sn 26yv439af40 4i?><emphasis><?xxe-sn 26yv439af40 4j?>Inward
	Isolation</emphasis>. 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.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 4k?>

	<para><?xxe-sn 26yv439af40 4l?><emphasis><?xxe-sn 26yv439af40 4m?>Outward
	isolation</emphasis>. 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.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26yv439af40 4n?>For file operations inward isolation may be
	implemented as virtualization strategy that requires from
	<emphasis><?xxe-sn 26yv439af40 4o?>other</emphasis> 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:</para>

	<itemizedlist>
	<?xxe-sn 26yv439af40 4p?>

	<listitem>
	<?xxe-sn 26yv439af40 4q?>

	<para><?xxe-sn 26yv439af40 4r?>Inward isolation — requires prefixes
	for other sizos.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 4s?>

	<para><?xxe-sn 26yv439af40 4t?>Outward isolation — requires prefix for
	itself.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26yv439af40 4u?>There is an annotation introduced to
	declare category for the current sizo:</para>

	<synopsis><?xxe-sn 26yv439af40 4v?>SYNTAX:
	assign_sizo_category(inward).
	assign_sizo_category(outward).</synopsis>

	<para><?xxe-sn 26yv439af40 4w?>Consider the example below:</para>

	<programlisting xml:id="IsolationCat_1"><?xxe-sn 26yv439af40 4x?>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")
	}
	}
	</programlisting>

	<para><?xxe-sn 26yv439af40 4y?>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 <code><?xxe-sn 26yv439af40 4z?>openFile</code> that actually
	requires file access. However, this time additional bits of information
	are available, namely <code><?xxe-sn 26yv439af40 50?>zoneA</code> and
	<code><?xxe-sn 26yv439af40 51?>zoneB</code> declared as inward and
	outward, respectively. By strategy outlines above, <code><?xxe-sn 26yv439af40 52?>zoneA</code>
	enables prefix based isolation strategy for <code><?xxe-sn 26yv439af40 53?>zoneB</code>,
	and <code><?xxe-sn 26yv439af40 54?>zoneB</code> enables isolation for
	itself as well. As a result, it's enough to virtualize only one
	zone(<code><?xxe-sn 26yv439af40 55?>zoneB</code>) leaving <code><?xxe-sn 26yv439af40 56?>zoneA</code>
	to enjoy direct access to file resources. Example output's is shown below,
	confirming that direct file access is granted for <code><?xxe-sn 26yv439af40 57?>zoneA</code>:</para>

	<screen xml:id="Output_IsolationCat_1"><?xxe-sn 26yv439af40 58?>File opened: 'test1'
	File opened: '1/test1'
	</screen>
	</section>
	</chapter>
	<?xxe-revisions
	#1 2018-12-18T13:45:06Z pgess
	?>

virtualization.xmlNo OneTemporaryActions

File Metadata

virtualization.xmlView Options

Event Timeline

virtualization.xml
No OneTemporary
Actions

virtualization.xml
View Options