Mark Aiken
Microsoft
Network
Latest external collaboration on country level. Dive into details by clicking on the dots.
Publication
Featured researches published by Mark Aiken.
european conference on computer systems | 2006
Manuel Fähndrich; Mark Aiken; Chris Hawblitzel; Orion Hodson; Galen C. Hunt; James R. Larus; Steven P. Levi
Message-based communication offers the potential benefits of providing stronger specification and cleaner separation between components. Compared with shared-memory interactions, message passing has the potential disadvantages of more expensive data exchange (no direct sharing) and more complicated programming.In this paper we report on the language, verification, and run-time system features that make messages practical as the sole means of communication between processes in the Singularity operating system. We show that using advanced programming language and verification techniques, it is possible to provide and enforce strong system-wide invariants that enable efficient communication and low-overhead software-based process isolation. Furthermore, specifications on communication channels help in detecting programmer mistakes early---namely at compile-time---thereby reducing the difficulty of the message-based programming model.The paper describes our communication invariants, the language and verification features that support them, as well as implementation details of the infrastructure. A number of benchmarks show the competitiveness of this approach.
european conference on computer systems | 2007
Galen C. Hunt; Mark Aiken; Manuel Fähndrich; Chris Hawblitzel; Orion Hodson; James R. Larus; Steven P. Levi; Bjarne Steensgaard; David Tarditi; Ted Wobber
In most modern operating systems, a process is a hardware-protected abstraction for isolating code and data. This protection, however, is selective. Many common mechanisms---dynamic code loading, run-time code generation, shared memory, and intrusive system APIs---make the barrier between processes very permeable. This paper argues that this traditional open process architecture exacerbates the dependability and security weaknesses of modern systems. As a remedy, this paper proposes a sealed process architecture, which prohibits dynamic code loading, self-modifying code, shared memory, and limits the scope of the process API. This paper describes the implementation of the sealed process architecture in the Singularity operating system, discusses its merits and drawbacks, and evaluates its effectiveness. Some benefits of this sealed process architecture are: improved program analysis by tools, stronger security and safety guarantees, elimination of redundant overlaps between the OS and language runtimes, and improved software engineering. Conventional wisdom says open processes are required for performance; our experience suggests otherwise. We present the first macrobenchmarks for a sealed-process operating system and applications. The benchmarks show that an experimental sealed-process system can achieve performance competitive with highly-tuned, commercial, open-process systems.
workshop on memory system performance and correctness | 2006
Mark Aiken; Manuel Fähndrich; Chris Hawblitzel; Galen C. Hunt; James R. Larus
Most operating systems enforce process isolation through hardware protection mechanisms such as memory segmentation, page mapping, and differentiated user and kernel instructions. Singularity is a new operating system that uses software mechanisms to enforce process isolation. A software isolated process (SIP) is a process whose boundaries are established by language safety rules and enforced by static type checking. SIPs provide a low cost isolation mechanism that provides failure isolation and fast inter-process communication.To compare the performance of Singularitys SIPs against traditional isolation techniques, we implemented an optional hardware isolation mechanism. Protection domains are hardware-enforced address spaces, which can contain one or more SIPs. Domains can either run at the kernels privilege level or be fully isolated from the kernel and run at the normal application privilege level. With protection domains, we can construct Singularity configurations that are similar to micro-kernel and monolithic kernel systems. We found that hardware-based isolation incurs non-trivial performance costs (up to 25--33%) and complicates system implementation. Software isolation has less than 5% overhead on these benchmarks.The lower run-time cost of SIPs makes their use feasible at a finer granularity than conventional processes. However, hardware isolation remains valuable as a defense-in-depth against potential failures in software isolation mechanisms. Singularitys ability to employ hardware isolation selectively enables careful balancing of the costs and benefits of each isolation technique.
ACM Transactions on Storage | 2005
Galen C. Hunt; James R. Larus; Martín Abadi; Mark Aiken; Paul Barham; Manuel Fähndrich; Chris Hawblitzel; Orion Hodson; Steven P. Levi; Nick Murphy; Bjarne Steensgaard; David Tarditi; Ted Wobber; Brian Zill
Archive | 2005
Mark Aiken; Gurdeep S. Pall; Dennis Morgan
Archive | 2001
Mark Aiken
Archive | 2006
Galen C. Hunt; Chris Hawblitzel; James R. Larus; Manuel Fähndrich; Mark Aiken
Archive | 2001
Mark Aiken; Ryan O'Donnell
Archive | 2001
Mark Aiken; Gurdeep S. Pall; Dennis Morgan
Archive | 2001
Mark Aiken; Ryan O'Donnell