7.5 Using Sandbox as a Method of Protection …
695
used one sandbox exclusively, and two other IP blocks sharing this sandbox due to
implementation of the source optimization procedure.
Even though the use of such sandboxes located between IP and the rest of the
system will undoubtedly lead to a certain increase in consumption of hardware
resources and implementation of procedures, it will nevertheless be justified from
the point of view of security.
7.5.5 Main Software Methods of Sandboxing
It should be said that many other modern innovative technologies, such as systems
on chip, theoretically emerged from software technologies before turning into actual
hardware means; however, software sandboxing has its own specific features. This
fully applies to the feature of executing the very mathematical procedure of sandboxing—placing an object into the structure that satisfies the requirements of the
used hardware means to the maximum degree.
Let us consider the classification adopted by the authors of [90] and borrowed
from [107], which assigns all known sandboxes to one of the following categories
depending on their operation mode.
(a) Managed code. All untrusted applications are compiled in the so-called intermediate code or representation (Java Bytecodes or Common Intermediate
Language (CIL) by Microsoft), which is usually executed under control of a
virtual machine (VM), such as Java VM or Microsoft common language runtime
(CLR). If controlled access is provided to system resources, such approach
cannot be applied to hardware IPs, since hardware means are executed not
simply as a sequence of instructions, which can be modeled using a virtual
machine, but as a structure of interconnected blocks, the actions of which are
transparently visible only on their interface.
(b) Embedded reference monitor. This approach implements the policy of access to
resources of such potentially unreliable IP that guarantees forced execution of
the security policy adopted by the owner of the IP. Many standard verification
tools today only insert assumptions into IP specification solely for the purpose of
verification. Since synthesized components, as a rule, are presented in OVL-type
libraries, they all are aimed at more coarse-grained integration on the interface
of components. The task of expanding such embedded reference monitor to the
microcircuit interface is more applicable for untrusted IPs, many of which are
COTS where such an integrator usually cannot access internal devices of the
design system and therefore unwillingly limits interaction with the interface.
(c) Sandbox of system calls Here, all sanboxed applications can access system
resources only by forming special system calls that are intercepted and quickly
executed by the VM or the sandbox manager. This approach differs from the
previous one only by the performance of emulation on the application interface
and not inside the code lines.
695
used one sandbox exclusively, and two other IP blocks sharing this sandbox due to
implementation of the source optimization procedure.
Even though the use of such sandboxes located between IP and the rest of the
system will undoubtedly lead to a certain increase in consumption of hardware
resources and implementation of procedures, it will nevertheless be justified from
the point of view of security.
7.5.5 Main Software Methods of Sandboxing
It should be said that many other modern innovative technologies, such as systems
on chip, theoretically emerged from software technologies before turning into actual
hardware means; however, software sandboxing has its own specific features. This
fully applies to the feature of executing the very mathematical procedure of sandboxing—placing an object into the structure that satisfies the requirements of the
used hardware means to the maximum degree.
Let us consider the classification adopted by the authors of [90] and borrowed
from [107], which assigns all known sandboxes to one of the following categories
depending on their operation mode.
(a) Managed code. All untrusted applications are compiled in the so-called intermediate code or representation (Java Bytecodes or Common Intermediate
Language (CIL) by Microsoft), which is usually executed under control of a
virtual machine (VM), such as Java VM or Microsoft common language runtime
(CLR). If controlled access is provided to system resources, such approach
cannot be applied to hardware IPs, since hardware means are executed not
simply as a sequence of instructions, which can be modeled using a virtual
machine, but as a structure of interconnected blocks, the actions of which are
transparently visible only on their interface.
(b) Embedded reference monitor. This approach implements the policy of access to
resources of such potentially unreliable IP that guarantees forced execution of
the security policy adopted by the owner of the IP. Many standard verification
tools today only insert assumptions into IP specification solely for the purpose of
verification. Since synthesized components, as a rule, are presented in OVL-type
libraries, they all are aimed at more coarse-grained integration on the interface
of components. The task of expanding such embedded reference monitor to the
microcircuit interface is more applicable for untrusted IPs, many of which are
COTS where such an integrator usually cannot access internal devices of the
design system and therefore unwillingly limits interaction with the interface.
(c) Sandbox of system calls Here, all sanboxed applications can access system
resources only by forming special system calls that are intercepted and quickly
executed by the VM or the sandbox manager. This approach differs from the
previous one only by the performance of emulation on the application interface
and not inside the code lines.