Implementing copy protection on software is a difficult problem that has resisted a satisfactory solution for many years. This paper proposes a set of features that allows a machine to execute XOM code: code where neither the instructions or the data are visible to entities outside the running process. To support XOM code we use a machine that supports internal compartments, where a process in one compartment cannot read data from another compartment. All data that leaves the machine is encrypted, since we assume secure compartments cannot be guaranteed by anything outside the machine. The design of this machine poses some interesting trade-offs between security, efficiency and flexibility. We explore some of the potential security issues as one pushes the machine to become more efficient and flexible. Our analysis indicates, while not cheap, it is possible to create a normal multi-tasking machine where nearly all applications can be run in XOM mode. While a virtual XOM machine is possible, the underlying hardware needs to support a unique private key, asymmetric decryption, private memory, fast symmetric ciphers, and traps on cache misses for efficient operation.

Recently, there has been considerable interest in providing "trusted computing platforms" using hardware --- TCPA and Palladium being the most publicly visible examples. In this paper we discuss our experience with building such a platform using a traditional time-sharing operating system executing on XOM --- a processor architecture that provides copy protection and tamper-resistance functions. In XOM, only the processor is trusted; main memory and the operating system are not trusted.

Traditionally, operating systems have fulfilled the dual roles of enforcing security on computer systems, as well as managing and virtualizing resources for the various applications sharing the machine. However, more recently, there have been some promising proposals in creating systems where hardware, rather than software enforces security and protection. These proposals would require an operating system running on such hardware to manage resources on behalf of applications that do not trust it. Unfortunately, the implementation of such an operating system has not received much attention in the literature and it is not clear if a traditional services of an operating system could be provided on such hardware. This paper discusses the modifications that are necessary to make a modern operating system execute on such hardware. The modifications were modest, the most significant changes were in the areas that perform context switches, signal handling, and virtual memory management.