Address Space Compartmentalization Methods

[p-linh]

As described in #20, and specifically for our HighJMP scenario, we want to compartmentalize the ADS between the KVStore app and lib. We currently have a very basic method of compartmentalizing the core ADS regions, ELF code, ELF data, heap, stack, etc. However, we may want to further divide app and lib ELF data, or to separate musllibc data (or any other global data) such that the app and lib operate on entirely separate copies of it.

Our current and only idea is to do this using linker scripts. This thread is for documenting other methods found from surveying the literature.

[p-linh]

SOAAP

source

• Describes a framework for how a system should implement compartmentalization such that it could be reasoned about
• Provides a static analysis tool to better inform developers about the consequences and potential risks of their compartmentalization designs.
• Developers would annotate their code with compartmentalization hints and run it through the SOAAP tool. Output from the tool would highlight potentially unintended data accesses from an untrusted compartment (that's been annotated by a hint), for instance.
• The analysis is done considering the principles of their SOAAP framework

Takeaways

Not much, it mentions data-centered compartmentalization where the same code runs on different instances of the data, but does not elaborate on how this should be set up, only that it is one possible method of compartmentalization.

[p-linh]

SecureCells

source

A proposed mechanism for implementing intra-address-space compartmentalization consisting of both hardware and software adjustments:

• New user-space assembly instruction to switch between compartments
• Users define a section of the program that needs to be compartmentalized, which then gets added to a central table managed by a trusted compute base.
• The central table holds virtual memory regions and each compartment's associated permissions for accessing that region.
• MMU is re-programmed to use this central table - the TLB looks up permissions rather than virtual addresses

Takeaways

This is one way in which we can achieve address space compartmentalization, but is far over-engineered for our requirements.

We could maybe employ the idea of a central entity that manages the compartmentalization of the address space and accesses to certain compartments. We would need a way to trigger the central entity's involvement when we switch compartments.

[p-linh]

MicroStache

source

• A method based on priviledge elevation for accessing sensitive data that requires hardware modifications (new registers and new instructions) and compiler extensions (to emit the new instructions)
• Each process can allocate "safe" regions (called Staches) of physical memory that is never mapped into its ADS
• MicroStache includes new assembly instructions for accessing the Stache, which is the only way to access it, and is done with compiler support
• Execution in the Stache is done in a safe stack that is included in the Stache, also with special new instructions for allocating Stache stack frames

Takeaways

This is a potential implementation of HighJMP that wouldn't require context switching between two ADSes.

The key requirement that our HighJMP is lacking is a way to clearly distinguish a region of memory that must be accessed separately. Most of these compartmentalization techniques assume that we've been able to do that already, and simply require a method to quickly and safely swap between them.

[p-linh]

Polytope

source

A language-level compartmentalization technique that tries to move manual isolation policy enforcement from user-program source code into the compiler.

• For instance, moving away from the developer having to manually embed calls to Intel MPK functions, which the authors claim to be error-prone
• Under Polytope, all code and data belong to a defined partition
• Developers can annotate their source files, functions, variables with Polytope-specific annotations to declare which parts of code and data belong to which partitions
• Their special compiler and toolchain groups code and data sections based on which partition they belong to and generates a linker script that lays out these partitions in separate sections in the ELF
• Dynamic memory is handled by swapping out standard calls like malloc with their special partition-based handlers (which are included in their runtime library) during linkage
• At runtime, before the main application starts, their runtime library labels each partition with an Intel MPK. The library is responsible for hopping between partitions using MPK functions

Takeaways

It might not be possible for us to place clear boundaries between app and lib data in a HighJMP ADS without customizing what happens during linkage. With Polytope, the developer doesn't need to consciously worry about the linker, but code and data separation eventually boils down to a custom linker script.