Files F3995554

virtualization.xml
No OneTemporary
Actions

File Metadata

Created
Tue, Jul 7, 2:14 PM

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 the 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>
<remark><?xxe-sn 2c3rmc3fvnj 1td6aqezxvj7l?>Желательно расшифровать
аббревиатуру CFG, до этого она нигде не встречалась, и мне не ясно что она
означает</remark>
<para><?xxe-sn 26yv439af40 1o?>One way to approach the 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 for SEcurity ZOne): logical entity introduced to
represent an environment and describe the desired virtualization
outcome.</para>
</listitem>
<listitem>
<?xxe-sn 26yv439af40 1t?>
<para><?xxe-sn 26yv439af40 1u?><emphasis><?xxe-sn 26yv439af40 1v?>zek</emphasis>
(distorted abbreviation for SEcurity aGent): represents behaviour of the
code in terms of virtualized resources access.</para>
<remark><?xxe-sn 2c3rmc3fvnj 1td6aqezxvj7m?>По поводу длинных тире:
насколько я знаю, они практически не используются в английском языке
(как и наши «типографские» кавычки). Только короткие. Но эту информацию
нужно проверить (PS: сегодня читал книгу на английском, и таки увидел
там длинные тире).</remark>
</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 the smallest 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 ensure it is solid and operable by checking that
it indeed satisfies requirements.</para>
<remark><?xxe-sn 2c3rmc3fvnj 1td6aqezxvj7n?>Я бы вообще сократил: "to
ensure it is solid, operable and satisfying the necessary
requirements"</remark>
</listitem>
</itemizedlist>
<para><?xxe-sn 26yv439af40 23?>In other words, context based reasoning
provides improvements by virtualizing only necessary sections of code and
only for necessary type of resources by employing as lightweight
virtualization strategy as possible – just enough to comply with the 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 abstracting code from the underlying <emphasis><?xxe-sn 26yv439af40 28?>resources</emphasis>
used by it. Here the term 'resource' depicts any external entity such as a
device, file, network connection 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 — allowing several
clients to use the same resource while behaving as if each client were
sole resource user, to simplify 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 — allowing client
application work in 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 the 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 should be virtualized, when, and
how.</para>
</section>
<section>
<?xxe-sn 26yv439af40 2j?>
<title><?xxe-sn 26yv439af40 2k?>Access Control</title>
<para><?xxe-sn 26yv439af40 2l?>A 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 a program are
virtualized differently depending on certain conditions. To capture this
concept, the term <emphasis><?xxe-sn 26yv439af40 2n?>sizo</emphasis> is
introduced, that refers to a logical entity that holds information about a
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="/d/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 an 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 demonstrated below:</para>
<synopsis><?xxe-sn 26yv439af40 2z?>SYNTAX:
**assign_sizo_control**(//resource-type//).</synopsis>
<para><?xxe-sn 26yv439af40 30?>It indicates that the current sizo (sizo
that spans over the code block wherein the annotation is located)
regulates all access to 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
e.g. 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 a 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 the 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?>The example outlines a dummy function
<code><?xxe-sn 26yv439af40 37?>openFile</code> to model file system
access. The function includes two specializations with the <code><?xxe-sn 26yv439af40 38?>strategy(direct)</code>
guard to model direct access, and the <code><?xxe-sn 26yv439af40 39?>strategy(common)</code>guard
to be invoked if virtualization is enabled. It is also annotated with
<code><?xxe-sn 26yv439af40 3a?>assign_zek_access(files)</code> to indicate
that it accesses the file system. On the other hand, the context of the
function <code><?xxe-sn 26yv439af40 3b?>main</code> defines the
<code><?xxe-sn 26yv439af40 3c?>zoneA</code> sizo and enables control over
file operations.</para>
<para><?xxe-sn 26yv439af40 3d?>Reasoning works with the 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 the sizo controls file operations and that there
is actually a function within the sizo that requires file access.
Consequently, the example outputs the following:<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 a 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 the ability to access the
same resource, but rather work with their own set of resources associated
with a particular sizo. The following examples, just as the previous one,
are focused on file operations as the most ubiquitous type of
resources.</para>
<para><?xxe-sn 26yv439af40 3l?>One way to isolate file access is to
associate a unique file prefix with each sizo. If virtualization is
enabled, all filenames in the sizo are silently transformed on the fly by
adding an assigned prefix. This way, all the file operations from one sizo
are confined within a specific directory allocated solely for that
particular sizo, or simply have a unique prefix if the same directory
contains files belonging to a different sizo(s).</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, the 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 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 which sizo it was called from. One possible way to
implement the discussed strategy is 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"-&gt;sizoCurrent:: Sizo):: int;
demand(sizo)
{
loop fold(dictSizo-&gt;entry::DictSizo, 0-&gt;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, the function
<code><?xxe-sn 26yv439af40 3x?>openFile</code> calls <code><?xxe-sn 26yv439af40 3y?>resolveFilename</code>
to find out the real filename. It can be said that <code><?xxe-sn 26yv439af40 3z?>resolveFilename</code>
serves as <emphasis><?xxe-sn 26yv439af40 40?>hypervisor</emphasis>
dereferencing file pseudonym into a real filename. For this purpose,
<code><?xxe-sn 26yv439af40 41?>resolveFilename</code> consists of two
specializations: specialization <code><?xxe-sn 26yv439af40 42?>strategy(direct)</code>
serves the non-virtualized environment leaving the filename without any
processing, while the other specialization <code><?xxe-sn 26yv439af40 43?>strategy(prefix)</code>
implements the resolving strategy by adding a sizo-associated prefix to
each file. More specifically, a unique index is assigned to each sizo, and
<code><?xxe-sn 26yv439af40 44?>resolveFilename</code> uses the index as a
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 the required prefix from <emphasis><?xxe-sn 26yv439af40 48?>late
context</emphasis> associated with a particular sizo.</para>
<important>
<?xxe-sn 26yv439af40 49?>
<para><?xxe-sn 26yv439af40 4a?>Client code has no way to influence
resolving process and force it to use an 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 is applicable
only if certain preconditions are met. Indeed, only a general approach can
handle a general task. However, for practical instances some improvements
are always possible by tailoring to a particular use case specifics and
subtle details. In other words, the more information available, the more
space there is for improvements. And the first step along 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 the optimal virtualization strategy for a 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 of other sizos to its internal resources, but is able to access
external resources freely. For example, monitoring and supervision
software may have been assigned this type of isolation, where it
freely accesses subordinate zones but cannot 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 over the outside world is
possible. Appropriate for various sandboxes and testing environments
to run a potentially insecure code.</para>
</listitem>
</itemizedlist>
<para><?xxe-sn 26yv439af40 4n?>For file operations, inward isolation may
be implemented as a virtualization strategy that requires from
<emphasis><?xxe-sn 26yv439af40 4o?>other</emphasis> sizos compulsory usage
of file prefixes so that no other sizo could access internal data of
inwardly isolated sizo. Conversely, outward isolation is compatible with
the strategy that involves assigning a 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 and any sizo that has a permission to know a unique
assigned prefix able to access the internal data of the 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 a prefix
for itself.</para>
</listitem>
</itemizedlist>
<para><?xxe-sn 26yv439af40 4u?>There is an annotation introduced to
declare a category for a 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 the reasoning apparatus developed in the previous sections,
both sizos activate virtualization, for both of them control some 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> are declared as inward and
outward, respectively. According to the strategy outlined 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 is enough to virtualize only one zone
(<code><?xxe-sn 26yv439af40 55?>zoneB</code>) leaving <code><?xxe-sn 26yv439af40 56?>zoneA</code>
to enjoy a direct access to file resources. Example outputs are shown
below, confirming that the direct file access is granted to
<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
#2 2019-03-22T19:27:23Z Администратор
#1 2018-12-18T13:45:06Z pgess
1sPEAAABgaQOAIh1gZoaABWFD4NIYW9mYWZzV0lBcmRub9CxaWMnQnknc4QyAQETgT1DM1OCWAEC
Yw8zBTMnUxljgUMjDDMGcwVTUyMMM4N7AQEjBFOBVyMFAQEzBxMFMztzDFOBHCMHEwRTCkMSIwVT
GzMMIxhDG2OCDyMEMxRTV2MEMwhjJVMG4UMEMxFTBFOCbkMEYwVDCDMIMzdjBFMEQxEzCUMFQ4J3
gwSTBWMYEwdTgVUzgxRDD0MWUwpTgQUBAUOCB1MIYykjBTMmc0YjBRMLYy1Tgm5jhB0TDzMgU3Rj
DDMWEwVTBUMGUwljCCMHUxozBDMXQyFTKwEBMzpDBkMHcwZDgRtDgWVjhnJjC2MFQ2szBFMZQwUz
HzMcQwljE0MdQxtjMDNyUyATCFMEYwhzHVMYYwVzHWMRMwRTYhMHM4E4kwVDB1MYQxAjCVMiEwkz
D1MPY4McMx9DG1MGU4IHM2VzC2MGAQFjBVMFYwQTCSMIUwZjHlN5YzUzUkNUEwZTNjMQYwdTB0NC
UwxTFhMJUxtDhCBDgTsjBlMEczlTIkNvYwVjDjMEQwUTBGMcQxNTjVdjgQUzHUMEQy6jEwljZ5MQ
Uwu9Uy0jDhMFU2sBAhMLUw4BAoMJMyFDBUNcYx1TBDM0UyVDIWMuQ4FXEwdTWzOBHUMHQ4IWYxNz
BZMGAQIzJWMcMy+TBnMFQwZzEjMZIwRTYDMKQwYTBGMNgwQjBDMGYwsTBTOBOkMFUx9zEzOCUHMF
UyszgQgTBUMGYyMBATOCBVMFQ0MjB2NdEwdDZ2MoM4EMQw9TBBMGU1pDDiMGgwlTdpMEQxBTBmMQ
cweDDyMQgxFDgwZTgQNjDRMFEwsTKTOGPTMhQ1BTgh1jLgECMxETBEOBdQEBYyQzbxMIQydTBDMN
YwUzDUMekwRzHDOBKACENYM1N4JbmVwRKh2CGYFQWAieLoRev0CEBcQxgySFBoF33kO5cYp5gQIy
nCoTM60HEB+6IYIQGJFEijRpJwaBOAmNfROacaR5iTmCfwulc5gbPRWKGQtoXIMAiRobgVmDKoMU
zgkZgQgFggzNUDELlQCeI1gvgm+JMnWDZHgNjUilcppIjwaGY5J9CLhFHJhwOSzDCYMr3USBHR+v
WYEQhXiJdXSBPZhMOoR8K4EbNCAzYoQ/wlq4SWyBO44YbDnDIhqaTW0/oQyBSB2DShuNbSoTHYMd
Ia5gIoILkowgkgCgJIJnzjiHAZIchyIiezhVtERcN4IsoBMgnyyIEKRPj2OEJYQlkhK+EyGBA1yq
WW+BTRPJWQ4gFo1cgQmrJiC/PrQ4O6iPNo0sgQiBRNM0P5dNjzlUDZURKGCQOiM2gxBHMM18gWJd
jwGBKoIZSUQaJx6xeUZJBollG0EqinnzVRSxWoE9CtdrE6U2gUOBNNaCUy6kWCJ3Ja94gguKG0yb
c2loKoERrjeBhSkbXrRxfyp5ep5jF3CxiVFcgmqDCIEFyW65U7RsRIZBJVWCIT6BhR4VgXclqgR5
jHerRsQRmCq/aHlsPQ==
?>

Event Timeline

Email: pr.h7@xreate.org · 2019 Xreate.org · Powered by Phabricator