Skip to:

Implementation, Verification, and Testing of the US Army Patented OS Friendly Microprocessor Architecture

Abdel-Hameed Badawy, New Mexico State University
Patrick Jungwirth, Army Research Laboratory
Jaime Acosta, White Sands Missile Range

The OS Friendly Architecture

In the current architectures from well-known vendors, such as Intel, AMD, ARM, etc., there is no mechanisms to separate shared resources across executing threads and processes, unless you run a virtual machine which is slow and has its drawbacks, which allows breaches in security and holes that are exploited through, e.g. buffer overflows and similar other attacks. In the US Army patented “OS Friendly Architecture” (OSFA) [5], we will enforce a hardware mechanism to isolate exchanges across shared boundaries in a way that such exchanges will raise hardware traps thus preventing such attacks.

The OSFA basically provides a switched set of cache memory banks in a pipeline configuration. For light-weight threads, the on-chip cache hierarchy provides near instantaneous context switching times. The cache banks provide fast pipelined and parallel read and write operation to the caches while the microprocessor’s execution pipeline is running instructions. The cache banks controllers provide arbitration to prevent the memory pipeline and microprocessor’s execution pipeline from accessing the same cache bank at the same time.  This separation or virtual fence allows the cache memory pages to transfer to and from the L1 caches while the microprocessor pipeline is executing instructions. Computer security operations are implemented in hardware. By extending the Unix file permissions bits to each cache memory bank and memory address, the OSFA provides hardware level computer security protections.

The OSFA creates secure sandboxes for each executing process with little to no overhead. To demonstrate the utility and the capabilities of the architecture, an FPGA implementation based on an already available, softcore that runs one of the famous instruction set architectures such as the x86, e.g.  microBlaze [8],  NIOS [9],  Zet [10], or  Frix [11] will be extended to support the security features in the architecture. Instruction set compatibility will allow software development and debugging tools already developed to be Used with the demonstration architecture. Figure 1 shows a block diagram of the OSFA [4].

Figure 1: A Graphical Representation of the OSFA [4]. The figure shows the different cache banks that are connected to the execution pipelines to allow for isolation and making the architecture look more like a Harvard architecture model instead of a Von-Neumann architecture model.

Testing and Performance Benchmarking

As part of this effort, we will design and develop a benchmark suite that will be used to evaluate the performance (in relation to resilience to attacks) of our architecture. Aside from evaluating our architecture, this benchmark will be applicable to other architectures for future comparison studies of e.g., reduction of impact, overhead, and performance. The benchmark will contain binaries that contain traditional memory corruption vulnerabilities such as stack-based buffer overflow, heap- based buffer overflow, integer overflow, incorrect pointer scaling, expired pointer dereferences, and others as described in e.g., MITRE common weakness exposures [1]. In addition to the vulnerable binaries, the benchmark will contain code that will exploit the vulnerabilities.

The benchmark will be completed in three phases. In the first phase, we will identify and characterize a set of known, vulnerable binaries; characterization parameters will include file binary, run-level (user or kernel), and vulnerability type. We will use public resources that includes intentional (e.g., capture the flag challenges, DARPA’s Cyber Grand Challenge (CGC) [3] and other initiatives), and unintentional (e.g., metasploit exploit modules, exploit-db, and packet storm) resources. The second phase will focus on developing exploits for the vulnerable binaries. While this may require some minimal manual analysis, we will automate this process by tailoring existing state-of-the-art binary analysis tools. Driller [2] (a finalist in the 2016 CGC) is an ideal candidate as it is available as open source and has shown to perform very well. However, Driller is currently configured for DARPA Experimental Cyber Research Evaluation Environment (DECREE) [3] binaries). We will make modifications (and re-release) for the software to work in on a broader range of platforms. The final phase will focus on evaluation. We will run our benchmark on our architecture and document performance metrics. During this phase, we will also package and automate our methodology into a reusable and open source workflow that can be used to evaluate other architectures.