System Assurance through Memory and Shared Resource Protection - Introduction

This is the introduction to my new paper, System Assurance through Memory and Shared Resource Protection. Like previous ones, I will be posting it in pieces with the last page having a link to the paper.

Regardless of the operating system, architecture, or purpose, general purpose computing devices have one unquestioned constant: instructions and the data they operate on are available in primary storage. While instructions and initial data can be permanently fixed in read only memory, data being interacted with must be writable and is typically volatile, random access memory: RAM. (Jessup, Valacich & Wade, 2003) Whenever an interaction involves reading information there is a potential for concerns about the confidentiality of the data and the reliability of the read is dependent on the data integrity. Writing interactions present potential threats to data integrity, and both reading and writing actions are dependent on the availability of the data source. This statements are true and applicable when the interactions in question are performed with reference to computer memory; thus memory needs protection to ensure the confidentiality, integrity, and availability of the system it resides within.

Operating systems, as massively complex pieces of software, are simultaneously dependent on the integrity of system memory and responsible for the protection of that same memory. To achieve this state of existing in the same memory that it is protecting, the operating system utilizes the privilege features provided by the hardware to allocate sections of the memory to by only accessible by code running in a privileged context: the kernel. (Vacca, 2009) Remaining sections of memory are left readable, writable, or both by code running without being in a privileged context: userspace.

Abstracting the limitations and layout of physical RAM away from the memory accesses by software additionally protects the memory state of both kernel and userspace code. This model of virtual memory utilizes secondary storage, such as a hard disk, to store data that running code gets to treat as being in memory even if the amount of memory being used exceeds the capacity of the physical RAM. (Jessup et al., 2003) Implementing such abstraction requires dedicated, specialized code in the kernel which can perform actions while running such as permission checking. While the abstraction code is running it is also utilized to provide significant additions to security scheme protecting system memory.

A third related, but not entirely limited to memory, system protection is the polyinstantiation of shared resources. Polyinstantiation is the generation of a separate instance of an accessed resource for the accessor. A common, necessary occurrence in multilevel databases, poly-instantiated records are records that share a supposedly unique key. (Jajodia & Sandhu, 1994) Virtual memory, as a model, is itself an example of polyinstantiation of the addressable memory space.

---

Jajodia, S., & Sandhu, R. (1994). Solutions to the polyinstantiation problem. GEORGE MASON UNIV FAIRFAX VA.

Jessup, L. M., Valacich, J. S., & Wade, M. (2003). Information systems today. Upper Saddle River, NJ, USA: Prentice Hall.

Vacca, J. R. (2009). Computer and Information Security Handbook. Burlington, MA: Morgan Kaufman