I-JVM: a Java Virtual Machine for component isolation in OSGi

Abstract

The OSGi framework is a Java-based, centralized, component oriented platform. It is being widely adopted as an execution environment for the development of extensible applications. However, current Java Virtual Machines are unable to isolate components from each other. For instance, a malicious component can freeze the complete platform by allocating too much memory or alter the behavior of other components by modifying shared variables. This paper presents I-JVM, a Java Virtual Machine that provides a lightweight approach to isolation while preserving compatibility with legacy OSGi applications. Our evaluation of I-JVM shows that it solves the 8 known OSGi vulnerabilities that are due to the Java Virtual Machine and that the overhead of I-JVM compared to the JVM on which it is based is below 20%.

Evaluation of OSGi-based architectures for customer energy management systems

“…This leads to the problem, that a single application can cause a system crash, for instance when allocating too much memory. A way to isolate applications in OSGi platforms has been presented in [13].…”

ScapeGoat: Spotting abnormal resource usage in component-based reconfigurable software systems

“…However, their work is focused on CPU usage and does not consider other resources, such as memory or I/O. Exploring the Java heap to obtain useful information about resource consumption has been proposed in [37,40]. As in our work, they account objects to the resource principal being explored (in their case to OSGi bundles) the first time an object is reached.…”

“…Computations in the second mechanism occur only on demand but are intensive because they involve traversing the graph of living objects in the heap. The accounting policy follows the paradigm of assigning objects to the component that is holding them and, if an object is reachable from more than one component, it is accounted to either one randomly, as suggested in [37]. In this paper, we call this second mechanism Heap Exploration.…”

“…As a consequence, in certain occasions the framework states that an object is being consumed for many components at the same time. We built this solution on top of the JVM Tool Interface (JVMTI) by implementing the algorithm proposed in [37,40], with the main difference being that our solution works without modifying the garbage collector. In summary, this algorithm simply try to find those objects that are reachable from the references of each component.…”

Simple Isolation for an Actor Abstract Machine

“…A number of systems rely on run-time mechanisms for achieving isolation, most using either deep-copy or special message heaps for communication, e.g. [7,9,11,12]. Of these, O-Kilim [12], which builds directly on the PhD work of the first author of this paper [6], is the closest to Siaam: it places no constraint on transferred object graphs, but at the expense of a complex programming model and no programmer support, in contrast to Siaam.…”