Shared Memory Protection in a Multi-tenant JVM

Abstract

Multi-tenant Software-as-a-Service (SaaS) providers allow tenants to customize the application at different levels. When the customization involves tenant custom code and a single application instance is shared among multiple tenants, the issue of tenant isolation becomes critical. In common practice, tenant isolation, which amounts to protection of tenants against any interference and disturbance from each other, is performed by isolating tenant custom code in either a dedicated Virtual Machine (VM) or a dedicated container. However, tenant isolation can be enforced at the higher level of threads rather than OS processes. The main advantage of this alternative approach is that it significantly increases tenant accommodation capacity (the number of tenants that can be hosted on a single node).

However, tenant isolation can be enforced at the higher level of threads rather than OS processes. The main advantage of this alternative approach is that it significantly increases tenant accommodation capacity (the number of tenants that can be hosted on a single node). However, achieving this benefit raises a number of non-trivial challenges, most notably the need for access control over the memory space shared between the custom code of multiple tenants.

In this paper, we present a solution for protecting the shared memory space of the Java Virtual Machine (JVM) demarcated by the static fields of the java.base module. The solution is based on systematic analysis of the java.base module. As a result of the analysis, the set of shared classes is reduced to a minimal subset of the java.base module and it is shown that the static fields of the minimal subset can be protected using the Java platform security. A multi-tenant class loading mechanism is also provided for loading a tenant-specific runtime instance of classes not included in the minimal subset.

The proposed solution is implemented on top of a customized OpenJDK 11 and validated by means of 18 validation scenarios. The evaluation results presented in this paper show that achieving a memory footprint reduction ranging between 32% and 97% requires only 32 CLOC in OpenJDK source and denial of only 9 distinct permissions for tenants without any significant performance overhead for a wide range of application domains.