Failing to properly isolate components in the same address space has resulted in a substantial amount of vulnerabilities. Enforcing the least privilege principle for memory accesses can selectively isolate software components to restrict attack surface and prevent unintended cross-component memory corruption. However, the boundaries and interactions between software components are hard to reason about and existing approaches have failed to stop attackers from exploiting vulnerabilities caused by poor isolation. We present the secure memory views (SMV) model: a practical and efficient model for secure and selective memory isolation in monolithic multithreaded applications. SMV is a third generation privilege separation technique that offers explicit access control of memory and allows concurrent threads within the same process to partially share or fully isolate their memory space in a controlled and parallel manner following application requirements. An evaluation of our prototype in the Linux kernel (TCB < 1,800 LOC) shows negligible runtime performance overhead in real-world applications including Cherokee web server (< 0.69%), Apache httpd web server (< 0.93%), and Mozilla Firefox web browser (< 1.89%) with at most 12 LOC changes.

The potential of aspect-oriented programming to adequately capture crosscutting concerns has yet to be fully realized. For example, authors have detailed significant challenges in creating reusable aspect component libraries. One proposed solution is to introduce Explicit Join Points (EJPs) to increase modularity by reducing obliviousness, enabling a Cooperative Aspect-Oriented Programming (Co-AOP) methodology where base code and aspects synergistically collaborate. This article explores the trade-offs between obliviousness and modularity. We briefly introduce EJPs and Co-AOP, and hypothesize how to balance obliviousness and modularity using Co-AOP. We build upon a prior empirical study to refactor three real-life Java applications to implement the exception handling concern using three distinct strategies: (1) using fully oblivious aspects in AspectJ, (2) using EJPs in a fully explicit fashion, and (3) using EJPs while following the Co-AOP methodology. We study other crosscutting concerns by refactoring a fourth application, JHotDraw. The differences in terms of common code metrics are analyzed, and the impact on modularity is assessed using design structure matrices. Results indicate that the Co-AOP methodology can in many cases significantly improve code quality attributes versus fully oblivious or fully explicit approaches. We conclude with guiding principles on the proper use of EJPs within the Co-AOP methodology.

The need for programs to execute subcomponents in isolation from each other or with lower privileges is prevalent among today's systems. We introduce ribbons: a shared memory programming model that allows for more implicit sharing of memory than processes but is more restrictive than threads. Ribbons structure the heap into protection domains. Privileges between these protection domains are carefully controlled in order to confine computation. We propose RibbonJ, a backwards-compatible extension of Java, to easily create or port programs to use the ribbons model. We study the progress and isolation properties of a subset of the language. Building on JikesRVM we implement ribbons by leveraging existing memory protection mechanisms in modern hardware and operating systems, avoiding the overhead of inline security checks and read or write barriers. We evaluate efficiency via microbenchmarks and the DaCapo suite, observing minor overhead. Additionally, we refactor Apache Tomcat to use ribbons for application isolation, discuss the refactoring's design and complexity, and evaluate performance using the SPECweb2009 benchmark.

As computer systems continue to become more powerful and complex, so do programs. High-level abstractions introduced to deal with complexity in large programs, while simplifying human reasoning, can often obfuscate salient program properties gleaned from automated source-level analysis through subtle (often non-local) interactions. Consequently, understanding the effects of program changes and whether these changes violate intended protocols become difficult to infer. Refactorings, and feature additions, modifications, or removals can introduce hard-to-catch bugs that often go undetected until many revisions later.

The potential of aspect-oriented programming to represent cross-cutting concerns as reusable components has yet to be fully realized. Indeed, authors have detailed significant challenges in creating reusable aspect component libraries. Proposed solutions include restricting the power of aspects upfront, inferring concern interaction, and shaping base code to conform to abstract design rules. Another proposed strategy is to reduce obliviousness in return for increased modularity by extending AspectJ with explicit join points (EJPs).