Software Defined Memory Ownership System by Alexander Huang B.S., Massachusetts Institute of Technology (2019) Submitted to the Department of Electrical Engineering and Computer Science in partial fulfillment of the requirements for the degree of Master of Engineering in Computer Science and Engineering at the MASSACHUSETTS INSTITUTE OF TECHNOLOGY September 2020 ⃝c Massachusetts Institute of Technology 2020. All rights reserved. Author.............................................................. Department of Electrical Engineering and Computer Science August 13, 2020 Certified by. Dr. Howard Shrobe Principal Research Scientist, MIT CSAIL Thesis Supervisor Certified by. Dr. Hamed Okhravi Senior Staff Member, MIT Lincoln Laboratory Thesis Supervisor Certified by. Dr. Nathan Burow Technical Staff, MIT Lincoln Laboratory Thesis Supervisor Accepted by . Katrina LaCurts Chair, Master of Engineering Thesis Committee DISTRIBUTION STATEMENT A. Approved for public release. Distribution is unlimited. This material is based upon work supported by the Assistant Secretary of Defense for Research and Engineering under Air Force Contract No. FA8702-15- D-0001. Any opinions, findings, conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the Assistant Secretary of Defense for Research and Engineering. 2 Software Defined Memory Ownership System by Alexander Huang Submitted to the Department of Electrical Engineering and Computer Science on August 13, 2020, in partial fulfillment of the requirements for the degree of Master of Engineering in Computer Science and Engineering Abstract Memory corruption bugs account for 70% of existing vulnerabilities. Such bugs pro- liferate because critical code such as operating systems is still implemented in unsafe languages like C and C++. To address this, memory safe languages such as Rust have been developed. Rust provides memory safety in its default usage by perform- ing static and dynamic checks to ensure code conforms to its safety model. However, these checks may be too restrictive for certain OS code. In these cases, programmers must write unsafe code to escape the safety guarantees. Even for kernels developed in Rust, guaranteeing safety for memory mapped input output (MMIO) device inter- actions remains a challenge given these interactions necessitate unsafe Rust to access addresses that appear arbitrary to the compiler. We build the Software Defined Memory Ownership System, or SDMOS, that enforces safe MMIO interactions in the Zero-Kernel Operating System (ZKOS), an operating system written in Rust. SDMOS leverages a tagged architecture to embed semantic metadata with IO memory regions and low-level device driver code in addi- tion to policies that define proper MMIO access at varying levels of granularity. We also implement a pipeline to apply tags at the compiler level, minimizing the amount of manual tagging. Our results show that SDMOS eliminates memory corruption resulting from buggy user space applications and device drivers. The main factor that dictates performance of SDMOS is the total number of rules installed to the tag cache. Our evaluations show that SDMOS’s cache load should not exceed the capacity of most cache implementations. Thesis Supervisor: Dr. Howard Shrobe Title: Principal Research Scientist, MIT CSAIL Thesis Supervisor: Dr. Hamed Okhravi Title: Senior Staff Member, MIT Lincoln Laboratory Thesis Supervisor: Dr. Nathan Burow Title: Technical Staff, MIT Lincoln Laboratory 3 4 Acknowledgments I would like to express the utmost gratitude to those who have helped me through every step of the MEng process. Thanks to Dr. Howard Shrobe and Dr. Hamed Okhravi for providing the opportunity to this project as well as crucial guidance. They have created a lab atmosphere that is supportive and collaborative, which has benefited my learning greatly. Thanks to Dr. Nathan Burow for the numerous technical advice that he has given, without which this project could not have been completed. In addition, his incredible patience and well-thought-out feedback throughout the writing process has been a tremendous help. Thanks to other mentors at Lincoln Laboratory and colleagues from the lab group for their support and useful pointers: Dr. Samuel Jero, Dr. Bryan Ward, Baltazar Ortiz, Claire Nord, Elijah Rivera, Ashley Kim, Josh Hilke and everyone else. Special thanks to Justin Restivo for giving me a jump start at the early stages of this project and providing guidance at critical moments. Thank you 媽媽 for inculcating me with the importance of education and encour- aging me to pursue whatever inspires me. I would not have the opportunities I do without you and I hope I get to tell you all about them someday. Thank you 光旭 舅舅 and 秀運阿姨 for the encouragements and support. Thank you for taking care of 媽媽 when I was so far away, I would not have completed my education without your help. Thank you 爸爸 for supporting me through school. Thank you Diane for helping me through some rough times and believing in me. Special shout out to Sid and David for always having my back. Thanks to Jiji the cat for making quarantine bearable and keeping my stress at bay. Lastly, there are countless others who enabled me to be where I am today. Thank you all! 5 6 Contents 1 Introduction 13 2 Background 17 2.1 Rust .................................... 17 2.1.1 Memory Safety Problems ..................... 18 2.1.2 Attempts to Secure C/C++ ................... 18 2.1.3 Safe vs. Unsafe Rust ....................... 19 2.2 ZKOS ................................... 20 2.2.1 Tock ................................ 21 2.2.2 MMIO Devices .......................... 21 2.3 Tagged Architecture ........................... 24 2.3.1 Dover’s Implementation ..................... 24 2.3.2 Policy ............................... 25 2.4 Threat model ............................... 27 3 Design 29 3.1 Goals .................................... 30 3.2 Policy Design ............................... 32 3.2.1 Level 1 Policy: MMIO Space Ownership ............ 33 3.2.2 Level 2 Policy: Device Driver Ownership ............ 34 3.2.3 Level 3 Policy: Register Ownership ............... 35 4 Implementation 37 7 4.1 Tagging .................................. 37 4.1.1 Initial approach: Instruction Tagging .............. 38 4.1.2 Function Entry and Exit Tagging ................ 39 4.1.3 Compiler Support ......................... 40 4.1.4 Driver Refactor .......................... 41 4.2 Policy ................................... 42 4.2.1 Ownership Assignment ...................... 42 4.2.2 Compartmentalization ...................... 42 4.2.3 Limitations ............................ 43 5 Evaluation 45 5.1 Security .................................. 45 5.1.1 Userspace access ......................... 46 5.1.2 Compromised Driver ....................... 47 5.2 Performance ................................ 47 5.2.1 Level 1 Ownership ........................ 48 5.2.2 Level 2 Ownership ........................ 49 5.2.3 Level 3 Ownership ........................ 50 6 Future Work 53 6.1 Device Instances ............................. 53 6.1.1 Dynamic Memory Ownership .................. 53 6.2 Fault Isolation ............................... 54 6.3 Peripheral Description Language ..................... 54 7 Related Work 55 8 Conclusion 59 8 List of Figures 2-1 Depiction of ROP attack ......................... 19 2-2 Tock’s Kernel Structure ......................... 21 2-3 Example MMIO memory layout ..................... 22 2-4 The e1000e bug .............................. 23 2-5 Example read, write, execute Policy ................... 26 3-1 Ownership of memory regions by device drivers ............ 30 3-2 Examples of MMIO writes ........................ 31 3-3 Property and owner tags used in sandbox mechanism ......... 33 3-4 Available ownership levels ........................ 33 4-1 Call stack of a UART driver in ZKOS .................. 38 4-2 Tags applied at the entry and exit point of an MMIO function .... 39 4-3 Flow of input program to tagged binary ................ 41 5-1 Miss rate (log scale) vs. cache size at level 1 ownership ........ 48 5-2 Miss rate (log scale) vs. cache size at level 2 ownership with policies running in isolation and combined .................... 51 5-3 Miss rate (log scale) vs. cache size at level 3 ownership with the UART Policy running in isolation ........................ 51 9 10 List of Tables 5.1 Number of unique tags available to each tag site for a level 1 policy . 49 5.2 Number of unique tags available to each tag site for a level 2 policy . 49 5.3 Examples of cache keys shared by the level 2 GPIO and UART policies 50 5.4 Number of unique tags available to each tag site for a level 3 policy . 50 11 12 Chapter 1 Introduction Memory corruption bugs introduced by unsafe languages serve as a common attack vector that can grant adversaries abilities ranging from crashing programs to exe- cuting arbitrary code [36]. C and C++ are popular unsafe systems programming languages that are still widely used due to the performance and flexibility they offer. These unsafe languages are able to achieve performance due to the lack of abstrac- tions that guarantee static and run time memory safety [5]. Similarly, they are flexible in that no restrictions are placed on how programmers can allocate memory or how pointers should be manipulated, leading to undefined behavior when an invalid ad- dress is inevitably referenced [47, 16, 48]. Lack of memory safety is especially problematic in operating systems,