reference monitor (RM) enforces a policy that specifies legal memory accesses [1]. When a core ... CPU and an AES encryp
Project Title: Implementing Memory Protection Primitives on Reconfigurable Hardware Project Web Site: http://www.cs.ucsb.edu/~huffmire/protection/ Authors: Brett Brotherton, Nick Callegari, and Ted Huffmire E-mails: bbrother@ece, nick_callegari@umail, huffmire@cs Overview: The goal of this project is to understand the practical issues of implementing memory protection on FPGA systems consisting of multiple cores on a single device. This will help us to develop realistic policies that drive real systems. To allow cores to share memory securely, a reconfigurable reference monitor (RM) enforces a policy that specifies legal memory accesses [1]. When a core makes a request to access memory, the RM makes a decision to either allow the access or deny it. To ensure that the RM is tamper-proof, we have developed moats, a spatial isolation technique that can also be used for the cores [2]. The architecture must also ensure that the RM is not bypassable (i.e., every memory access must be decided on by the RM). To this end we have developed interconnect tracing, a static technique that ensures that a core cannot route around the reference monitor [2]. We have also developed a TDMA bus architecture to prevent snooping on the memory bus traffic [2]. The RM can provide protection for both on-chip BRAM and off-chip DRAM. For example, a MicroBlaze CPU and an AES encryption core can share a block of BRAM. The CPU encrypts plaintext by copying the plaintext to the BRAM and then signaling to the AES core via a control word. The AES core retrieves the plaintext from the BRAM and encrypts the plaintext using a symmetric key. After encrypting the plaintext, the AES core places the ciphertext into the BRAM and then signals to the CPU via another control word. Finally, the CPU retrieves the ciphertext from the BRAM. A similar process is used for decryption. A simple memory access policy can be constructed with two states: one state that gives the CPU exclusive access to the shared buffer and another state that gives the AES core exclusive access to the buffer. The transitions between these two states occur when the cores signal to each other via the control words. We will build such a system with a reference monitor that enforces a meaningful policy. To facilitate the encryption and decryption of files, we will provide a better interface to the system than the current HyperTerminal interface. Our interface will allow a program to send any type of file over the RS-232 connection. In the above scenario involving BRAM, the cores are directly connected. Communication with external DRAM, on the other hand, requires utilizing a shared bus. A bus (OPB) can connect the CPU, external DRAM, RS232 (serial port), general-purpose I/O (to access the external pins), shared BRAM, and DMA. To prevent two cores from utilizing the bus at the same time, a TDMA arbiter sits between the modules and the bus. Figure 1 shows two alternative memory protection architectures. The reference monitor can be placed between the bus and the DRAM. Alternatively, the reference monitor can snoop on the bus. Our goal is to make sure that our memory protection primitive achieves efficient memory system performance. This will also be an opportunity to design meaningful policies for systems that employ a shared bus. The DMA (direct memory access) controller introduces a new security challenge because of its ability to independently copy blocks of memory. The development of a secure DMA controller requires understanding tradeoffs between security and performance. In addition, memory access policies may need to be constructed differently for systems that use a DMA controller. For example, the request to the DMA could include the requesting module’s ID.
M2
M1
M1
M2
TDMA Arbiter
TDMA Arbiter
Bus
Bus
RM
MEM
RM
Buf
MEM
Figure 1: Two alternative memory protection architectures. Division of Labor: Nick will be responsible for developing the improved interface allowing programs to encrypt or decrypt any type of file. Brett will be responsible for integrating the reference monitor into the system architecture. Ted will be responsible for developing policies for the system and writing the project documents. Ted will work with Brett on improving the reference monitor for each of the proposed architectures. Project Milestones: We will have weekly project meetings to update each other with the status of our assigned tasks. The first system architecture we will implement will not use a bus: the reference monitor will protect a small number of BRAM blocks. Next, we will move on to the more complex architecture involving a bus. First, we will develop a system in which the reference monitor sits between the bus and external memory. Once this is successful, we will work to optimize the memory system performance, developing a snooping reference monitor if necessary. If time permits, we will incorporate the TDMA arbiter and secure DMA controller into our bus architecture. References: [1] Ted Huffmire, Shreyas Prasad, Tim Sherwood, and Ryan Kastner. Policy-Driven Memory Protection for Reconfigurable Systems. Proceedings of the European Symposium on Research in Computer Security (ESORICS), Hamburg, Germany, September 2006. [2] Ted Huffmire, Brett Brotherton, Gang Wang, Tim Sherwood, Ryan Kastner, Timothy Levin, Thuy Nguyen, and Cynthia Irvine. Moats and Drawbridges: An Isolation Primitive for Reconfigurable Hardware Based Systems. Proceedings of the 2007 IEEE Symposium on Security and Privacy, Oakland, CA, USA, May 2007.
