DOCSLIB.ORG

Intel X84 64 Mechanisms

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Intel X84 64 Mechanisms Hardware-assisted Run-time Protection N. Asokan†‡ https://asokan.org/asokan/ @nasokan Acknowledgements: Thomas Nyman‡, Hans Liljestrand†, Lachlan J Gunn‡, Jan-Erik Ekberg‡, § †) University of Waterloo, ‡) Aalto University, §) Huawei Technologies You will be learning Part 1: Memory-related run-time attacks • Common attack techniques against C/C++ Part 2: Hardware-assisted defenses • Emerging mechanisms in CotS processors Part 3: Theory of run-time attacks • What are “weird machines”? 2 Example: Buffer overflows caused by missing bounds checks Software Developer 08048464 <main>: 8048464: 55 push %ebp 8048465: 89 e5 mov %esp,%ebp 8048467: 68 20 85 04 08 push $0x8048520 804846c: e8 9f fe ff ff call 8048310 <puts@plt> 8048471: 83 c4 04 add $0x4,%esp 8048474: 8b 45 0c mov 0xc(%ebp),%eax 8048477: 83 c0 04 add $0x4,%eax 804847a: 8b 00 mov (%eax),%eax 804847c: 50 push %eax 804847d: 0804843be8 b9 <doit>:ff ff ff call 804843b <doit> int main(int argc, char *argv[]) 8048482: 804843b:83 c4 04 55 add $0x4,%esp push %ebp { 8048485: 804843c:68 31 85 04 8908 e5push $0x8048531 mov %esp,%ebp puts("So... The End..."); 804848a: 804843e:e8 81 fe ff 83ff eccall 0c 8048310 sub <puts@plt>$0xc,%esp doit(argv[1]); 804848f: 8048441:83 c4 04 8d 45add f4 $0x4,%esp lea -0xc(%ebp),%eax 8048492: b8 00 00 00 00 mov $0x0,%eax puts("or... maybe not?"); Source Executable 8048444: 89 45 fc mov %eax,-0x4(%ebp) 8048497: 8048447:c9 ff 75leave 08 pushl 0x8(%ebp) 8048498: 804844a:c3 8d 45ret f4 lea -0xc(%ebp),%eax return 0; code File 8048499: 804844d:66 90 50 xchg %ax,%ax push %eax } 804849b: 804844e:66 90 e8 adxchg fe ff %ax,%ax ff call 8048300 <strcpy@plt> void doit(char *str) 804849d: 8048453:66 90 83 c4xchg 08 %ax,%ax add $0x8,%esp { 804849f: 8048456:90 ff 75nop fc pushl -0x4(%ebp) char buf[8]; 8048459: e8 b2 fe ff ff call 8048310 <puts@plt> 804845e: 83 c4 04 add $0x4,%esp char *ptr = buf; 8048461: 90 nop Compiler & Linker 8048462: c9 leave strcpy(buf, str); 8048463: c3 ret puts(ptr); } missing bounds-checks in call to strcpy! 3 void doit(char *str) { char buf[8]; Run-time behaviour char *ptr = buf; strcpy(buf, str); puts(ptr); User } 0xffffffff parent stack frame $ ./a.out “Hello !” Kernel Space Kernel space 0xc0000000 Stack (grows down) =TASK_SIZE 08048464 <main>: ... User Space 8048474: 8b 45 0c mov 0xc(%ebp),%eax 8048477: 83 c0 04 add $0x4,%eax 0xbfffceb8 804847a: 8b 00 mov (%eax),%eax arguments: 0xbfffd18a (argv[1]) 804847c: 50 push %eax 0xbfffceb4 804847d: e8 b9 ff ff ff call 804843b <doit> return address: 0x08048482 (saved eip) 0xbfffceb0 Memory Mapping 8048482:0804843b83 <doit>:c4 04 add $0x4,%esp frame pointer: 0xbfffceb8 (saved ebp) Region 8048485:804843b:68 31 8555 04 08 push push$0x8048531 %ebp 0xbfffceac 0x40000000 804848a:804843c:e8 81 fe89 ffe5 ff call mov8048310 %esp,%ebp <puts@plt> ptr: 0xbfffcea0 (&buf) 804848f: 83 c4 04 add $0x4,%esp 0xbfffcea8 804843e: 83 ec 0c sub $0xc,%esp ’\0’ ’!’ ’ ’ ’O’ 8048492:8048441:b8 00 008d 0045 00f4 mov lea$0x0,%eax-0xc(%ebp),%eax 0xbfffcea4 8048497:8048444:c9 89 45 fc leave mov %eax,-0x4(%ebp) buf: ’L’ ’L’ ’E’ ’H’ 8048498: c3 ret 0xbfffcea0 8048447: ff 75 08 pushl 0x8(%ebp) 0xbfffcea0 (ptr) Heap (grows up) 8048499: 66 90 xchg %ax,%ax arguments: 804844a: 8d 45 f4 lea -0xc(%ebp),%eax 0xbfffce9c Bss segment 804849b:804844d:66 90 50 xchg push%ax,%ax%eax 0xbfffd18a (str) 0xbfffce98 804849d:804844e:66 90 e8 ad fe xchgff ff call%ax,%ax8048300 <strcpy@plt> strcpy stack frame Data segment 804849f:8048453:90 83 c4 08 nop add $0x8,%esp 8048456: ff 75 fc pushl -0x4(%ebp) Text segment 8048459: e8 b2 fe ff ff call 8048310 <puts@plt> 804845e: 83 c4 04 add $0x4,%esp 0x0804000 8048461: 90 nop 0x00000000 8048462: c9 leave 8048463: c3 ret 4 void doit(char *str) { char buf[8]; Control-flow hijacking char *ptr = buf; strcpy(buf, str); puts(ptr); $ ./a.out $(perl -e 'print "A"x8 \ } .""\x??\x??\x04\x08" \ 0xffffffff ."A"x4"A"x4 \ parent stack frame Kernel Space Kernel space .""\x64\x84\x04\x08"')x08" 0xc0000000 Stack (grows down) =TASK_SIZE libc init: User Space 0xbfffceb8 arguments: 0xbfffd18a (argv[1]) 08048464: 0xbfffceb4 return address: 0x080484640x08048482 (saved (main) eip) <main>: 0xbfffceb0 Memory Mapping frame pointer: 0xffffceb8’A’ ’A’ (saved’A’ ebp)’A’ Region 0xbfffceac 0x40000000 ptr: 0x0804????0xffffcea0 (&buf) (data) 0xbfffcea8 0804843b: ’A’’\0’ ’A’’!’ ’A’’ ’ ’A’’O’ <doit>: 0xbfffcea4 buf: ’A’’L’ ’A’’L’ ’A’’E’ ’A’’H’ 0xbfffcea0 0xbfffcea0 (ptr) Heap (grows up) 0xbfffce9c 0xbfffd18a (str) Bss segment 0x8048300: 8048310: strcpy stack frame Data segment <strcpy>: puts: Text segment 0x08040000 0x00000000 corrupt code pointer / control flow 5 Memory-related run-time attacks Memory-related run-time attacks Software written in memory unsafe languages such as C/C++ • Suffer from various memory-related errors Memory errors may allow run-time attacks to compromise program behaviour • Control-flow hijacking / code injection • Return-Oriented Programming (ROP) • Non-control-data attacks • Data-Oriented Programming (DOP) 7 Run-time attacks compromise program behaviour Adversary exploits bug 1 if (authenticated != true) then: call unprivileged() else: call privileged() 1 … 2 unprivileged() { … } 3 3 privileged() { … } 2 3 shellcode … 8 (i) Code-injection attacks Exploit memory error (e.g. buffer overflow) to: • Inject shellcode into writable memory (usually stack) • Corrupt code pointer (usually return address) to redirect execution flow to shellcode shellcode Countermeasures: • Stack canaries (1990) frame- badreturn return address address record frame-pointer Detect sequential overwrites that corrupt ret. addr. FP • W X memory access control policy (2003) stackframe Prevent⊕ execution of shellcode by ensuring that buffer memory pages are either writable or executable SP Elias Levy (as Aleph One), Smashing the stack for fun and profit, Phrack 7 (1996) Cowan et al., StackGuard: Automatic adaptive detection and prevention of buffer-overflow attacks, USENIX Security (1998) 9 Szekeres et al., SoK: Eternal War in Memory, IEEE SP (2013) void doit(char *str) { char buf[8]; Classic code-injection char *ptr = buf; strcpy(buf, str); $ ./a.out $(perl -e 'print "A"x8 \ puts(ptr); } .""\x??\x??\x04\x08" \ ."A"x4"A"x4 \ 0xffffffff parent stack frame .""\xb8\xce\xff\xfb"xfb" \ Kernel space ..""\x80\xcd" ..""\x40“ \ 0xc0000000 ..""\xc0\x31" ..""\x80\xcd" \ 0xbfffcebc Stack (grows down) =TASK_SIZE libc init: ..""\x0b\xb0" ..""\xc2\x89" \ ..""\xc1\x89" ..""\xe3\x89" \ shellcode 0xbfffceb8 ..""\x6e\x69\x62\x2f\x68" \ 0xffffd18a (argv[1]) 08048464: 0xbfffceb4 ..""\x68\x73\x2f\x2f\x68" \ 0xbfffceb80x08048482 (saved eip) <main>: ..""\x50" ..""\xc0\x31") 0xbfffceb0 Memory Mapping 0xffffceb8’A’ ’A’ (saved’A’ ebp)’A’ Region 0xbfffceac 0x40000000 0x0804????0xffffcea0 (&buf) (data) 0xbfffcea8 0804843b: ’A’’\0’ ’A’’!’ ’A’’ ’ ’A’’O’ <doit>: :0xffffceb8 0xbfffcea4 :<shellcode> ’A’’L’ ’A’’L’ ’A’’E’ ’A’’H’ 0xbfffcea0 0xbfffcea0 (ptr) Heap (grows up) 0xbfffce9c 0xbfffd18a (str) Bss segment 0x8048300: 8048310: strcpy stack frame Data segment <strcpy>: puts: Text segment 0x0804000 0x00000000 10 Return-oriented programming (high-level idea) Re t u r n o r ien t ed Pro g ra mm ing 11 Return-oriented programming Attacker arranges call stack with code pointers to existing code sequences (“gadgets”) • Given a suitable gadget set, arbitrary return-oriented programs can be constructed … push edi Adversary leave ret exploits bug … cmp eax,edi leave ret … … mov eax,[ebp+0x8] cmp [esi+0x74],edi leave … leave ret add $0x4,%esp ret leave 12 ret (ii) Code-reuse attacks … gadget 3: Exploit memory error without injecting code: br <puts> ret • Corrupt code pointer (usually return address) to … address of gadget 3 redirect execution flow to existing code: gadget 2: • Library functions (return-into-libc) forged data load x0, x0 • Pre-existing instruction sequences (gadgets) address of gadget 2 ret … forged data function:gadget 1: Countermeasures: frame- addressaddressreturn ofof address functiongadget 1 …load x0, sp record frame-pointer ret • Control-flow Integrity (2005) FP Detect control-flow transfers outside static SP+size control-flow graph or mismatched returns stack frame buffer (shadow stack) SP • Address space randomization (2001) Hide locations of useful gadgets in memory A. Peslyak (as Solar Designer), Getting around non-executable stack (and fix), Bugtraq (1997) H. Shacham, The geometry of innocent flesh on the bone: return-into-libc without function calls (on the x86), ACM CCS (2007) T. Kornau, Return Oriented Programming for the ARM Architecture, MSc Thesis, RUB (2009) 13 M. Abadi, Control-flow integrity, ACM CCS (2005) CFI: High-level idea CFI check at A CFI violation at D Allowed edges: (A,B), (A,F) A Disallowed edge: (F,D) CFI check at B CFI check at D Allowed edges: (B,A), (B,C), (B,D) B Allowed edges: (D,B), (D,G) CFI check at C CFI check at F Allowed edges: (C,B), (C,G) C D F Allowed edges: (F,A) CFI check at G G Allowed edges: (G,C), (G,D) Legend: intended forward-edge in CFG initial node in CFG intended backward-edge in CFG node in CFG malicious edge not part of CFG 15 Shadow Stack: High-level idea “Shadow stack” Adversary A tampers with shadow stack →C B A→B C 16 void doit(char *str) { char buf[8]; Non-control data attack char *ptr = buf; strcpy(buf, str); puts(ptr); $ ./a.out $(perl -e 'print "A"x8 \ } .""\x08\xb0\xc4\x09" ) 0xffffffff parent stack frame Kernel space 0xc0000000 Stack (grows down) =TASK_SIZE libc init: 0xbfffceb80xffffceb8 arguments: 0xbfffd18a (argv[1]) 08048464: 0xbfffceb4 return address: 0x08048482 (saved eip) <main>: 0xbfffceb0
Load more

Recommended publications
  • Deciding Memory Safety for Single-Pass Heap-Manipulating Programs
    Deciding Memory Safety for Single-Pass Heap-Manipulating Programs UMANG MATHUR, University of Illinois, Urbana-Champaign, USA ADITHYA MURALI, University of Illinois, Urbana-Champaign, USA PAUL KROGMEIER, University of Illinois, Urbana-Champaign, USA P. MADHUSUDAN, University of Illinois, Urbana-Champaign, USA MAHESH VISWANATHAN, University of Illinois, Urbana-Champaign, USA We investigate the decidability of automatic program verification for programs that manipulate heaps, andin particular, decision procedures for proving memory safety for them. We extend recent work that identified a decidable subclass of uninterpreted programs to a class of alias-aware programs that can update maps. We 35 apply this theory to develop verification algorithms for memory safetyÐ determining if a heap-manipulating program that allocates and frees memory locations and manipulates heap pointers does not dereference an unallocated memory location. We show that this problem is decidable when the initial allocated heap forms a forest data-structure and when programs are streaming-coherent, which intuitively restricts programs to make a single pass over a data-structure. Our experimental evaluation on a set of library routines that manipulate forest data-structures shows that common single-pass algorithms on data-structures often fall in the decidable class, and that our decision procedure is efficient in verifying them. CCS Concepts: • Theory of computation → Logic and verification; Automated reasoning. Additional Key Words and Phrases: Memory Safety, Program Verification, Aliasing, Decidability, Uninterpreted Programs, Streaming-Coherence, Forest Data-Structures ACM Reference Format: Umang Mathur, Adithya Murali, Paul Krogmeier, P. Madhusudan, and Mahesh Viswanathan. 2020. Deciding Memory Safety for Single-Pass Heap-Manipulating Programs. Proc. ACM Program.
    [Show full text]
  • Intra-Unikernel Isolation with Intel Memory Protection Keys
    Intra-Unikernel Isolation with Intel Memory Protection Keys Mincheol Sung Pierre Olivier∗ Virginia Tech, USA The University of Manchester, United Kingdom [email protected] [email protected] Stefan Lankes Binoy Ravindran RWTH Aachen University, Germany Virginia Tech, USA [email protected] [email protected] Abstract ACM Reference Format: Mincheol Sung, Pierre Olivier, Stefan Lankes, and Binoy Ravin- Unikernels are minimal, single-purpose virtual machines. dran. 2020. Intra-Unikernel Isolation with Intel Memory Protec- This new operating system model promises numerous bene- tion Keys. In 16th ACM SIGPLAN/SIGOPS International Conference fits within many application domains in terms of lightweight- on Virtual Execution Environments (VEE ’20), March 17, 2020, Lau- ness, performance, and security. Although the isolation be- sanne, Switzerland. ACM, New York, NY, USA, 14 pages. https: tween unikernels is generally recognized as strong, there //doi.org/10.1145/3381052.3381326 is no isolation within a unikernel itself. This is due to the use of a single, unprotected address space, a basic principle 1 Introduction of unikernels that provide their lightweightness and perfor- Unikernels have gained attention in the academic research mance benefits. In this paper, we propose a new design that community, offering multiple benefits in terms of improved brings memory isolation inside a unikernel instance while performance, increased security, reduced costs, etc. As a keeping a single address space. We leverage Intel’s Memory result,
    [Show full text]
  • “Sok: Eternal War in Memory”
    “SoK: Eternal War in Memory” Presented by Mengjia Yan MIT 6.888 Fall 2020 Overview • Discuss the paper “SoK: Eternal War in Memory” with concrete examples • Recent progress on memory safety • With a focus on hardware/architecture 2 Motivation • C/C++ is unsafe • EveryboDy runs C/C++ coDe • They surely have exploitable vulnerabilities 3 Low-level Language Basics (C/C++/Assembly) 0x00..0000 • Programmers have more control + Efficient OS memory - Bugs - Programming productivity TEXT (code) Global/Static • Pointers DATA • Address of variables (uint64): index of memory location where variable is stored Heap • Programmers need to do pointer check, e.g. NULL, out-of-bound, use-after-free Stack 0xFF..FFFF 4 Low-level Language Basics 0x00..0000 TEXT (code) Heap Stack 0xFF..FFFF 5 Low-level Language Basics TEXT (code) stack 6 Attacks Code Injection Attack Example TEXT (code) int func (char *str) { Shell code: char buffer[12]; strncpy(buffer, str, len(str)); PUSH “/bin/sh” CALL system stack return 1; } int main() { …. func (input); … } 8 Code Injection Attack TEXT (code) TEXT (code) stack stack buffer Shell code … … Return addr Return addr 9 Attacks 10 Return-Oriented Programming (ROP) int func (char *str) { TEXT (code) TEXT (code) char buffer[12]; strncpy(buffer, str, len(str)); stack stack return 1; } …. int main() { buffer …. … … func (input); Return addr Return addr … } 11 Attacks 12 HeartBleed Vulnerability • Publicly DiscloseD in April 2014 • Bug in the OpenSSL cryptographic software library heartbeat extension • Missing a bound check 13 Attacks
    [Show full text]
  • MPTEE: Bringing Flexible and Efficient Memory Protection to Intel
    MPTEE: Bringing Flexible and Efficient Memory Protection to Intel SGX Wenjia Zhao Kangjie Lu* Yong Qi* Saiyu Qi Xi’an Jiaotong University University of Minnesota Xi’an Jiaotong University Xidian University University of Minnesota Abstract code, emerge in today’s market. In particular, Intel has pro- Intel Software Guard eXtensions (SGX), a hardware-based vided SGX in its commodity processors, which supports a se- Trusted Execution Environment (TEE), has become a promis- cure region, namely enclave, to protect the internally loaded ing solution to stopping critical threats such as insider attacks code and data. Given its important and practical protection, and remote exploits. SGX has recently drawn extensive re- SGX has been extensively studied and used in practice. For search in two directions—using it to protect the confidentiality example, SCONE [1] uses it to effectively enhance the secu- and integrity of sensitive data, and protecting itself from at- rity of containers with low overhead. JITGuard [17] leverages tacks. Both the applications and defense mechanisms of SGX it to protect the security-critical just-in-time compiler oper- have a fundamental need—flexible memory protection that ations. SGXCrypter[49] utilizes it to securely unpack and updates memory-page permissions dynamically and enforces execute Windows binaries. There are many other useful appli- the least-privilege principle. Unfortunately, SGX does not pro- cations [35], [34], [31],[6], which confirm the practical and vide such a memory-protection mechanism due to the lack of promising applications of SGX. hardware support and the untrustedness of operating systems. Another line of research is to protect SGX itself from at- This paper proposes MPTEE, a memory-protection mech- tacks.
    [Show full text]
  • Intel® Xeon® E3-1200 V5 Processor Family
    Intel® Xeon® E3-1200 v5 Processor Family Specification Update May 2020 Revision 033 Reference Number: 333133-033US Intel technologies’ features and benefits depend on system configuration and may require enabled hardware, software or service activation. Learn more at Intel.com, or from the OEM or retailer. No computer system can be absolutely secure. Intel does not assume any liability for lost or stolen data or systems or any damages resulting from such losses. You may not use or facilitate the use of this document in connection with any infringement or other legal analysis concerning Intel products described herein. You agree to grant Intel a non-exclusive, royalty-free license to any patent claim thereafter drafted which includes subject matter disclosed herein. No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document. The products described may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade. Intel® Turbo Boost Technology requires a PC with a processor with Intel Turbo Boost Technology capability. Intel Turbo Boost Technology performance varies depending on hardware, software and overall system configuration. Check with your PC manufacturer on whether your system delivers Intel Turbo Boost Technology. For more information, see http://www.intel.com/ content/www/us/en/architecture-and-technology/turbo-boost/turbo-boost-technology.html Copies of documents which have an order number and are referenced in this document may be obtained by calling 1-800-548- 4725 or by visiting www.intel.com/design/literature.htm.
    [Show full text]
  • Sok: Hardware Security Support for Trustworthy Execution
    SoK: Hardware Security Support for Trustworthy Execution Lianying Zhao1, He Shuang2, Shengjie Xu2, Wei Huang2, Rongzhen Cui2, Pushkar Bettadpur2, and David Lie2 1Carleton Universityz, Ottawa, ON, Canada 2University of Toronto, Toronto, ON, Canada Abstract—In recent years, there have emerged many new hard- contribute to lowering power consumption, which is critical ware mechanisms for improving the security of our computer for resource-constrained devices. systems. Hardware offers many advantages over pure software Furthermore, hardware is the Root of Trust (RoT) [48], as approaches: immutability of mechanisms to software attacks, better execution and power efficiency and a smaller interface it bridges the physical world (where human users reside) and allowing it to better maintain secrets. This has given birth to the digital world (where tasks run as software). To securely a plethora of hardware mechanisms providing trusted execution perform a task or store a secret, the user trusts at least part of environments (TEEs), support for integrity checking and memory the computer hardware. safety and widespread uses of hardware roots of trust. Dedicated hardware security support has seen its prolif- In this paper, we systematize these approaches through the lens eration since the early days of computers. It can take a of abstraction. Abstraction is key to computing systems, and the interface between hardware and software contains many abstrac- straightforward form as discrete components to assist the tions. We find that these abstractions, when poorly designed, can CPU, ranging from the industrial-grade tamper-responding both obscure information that is needed for security enforcement, IBM Cryptocards (e.g., 4758 [37]), Apple’s proprietary secure as well as reveal information that needs to be kept secret, leading enclave processor (SEP [84]) for consumer electronics, to the to vulnerabilities.
    [Show full text]
  • Operating System Support for Run-Time Security with a Trusted Execution Environment
    Operating System Support for Run-Time Security with a Trusted Execution Environment - Usage Control and Trusted Storage for Linux-based Systems - by Javier Gonz´alez Ph.D Thesis IT University of Copenhagen Advisor: Philippe Bonnet Submitted: January 31, 2015 Contents Preface2 1 Introduction4 1.1 Context.......................................4 1.2 Problem.......................................6 1.3 Approach......................................7 1.4 Contribution....................................9 1.5 Thesis Structure.................................. 10 I State of the Art 12 2 Trusted Execution Environments 14 2.1 Smart Cards.................................... 15 2.1.1 Secure Element............................... 17 2.2 Trusted Platform Module (TPM)......................... 17 2.3 Intel Security Extensions.............................. 20 2.3.1 Intel TXT.................................. 20 2.3.2 Intel SGX.................................. 21 2.4 ARM TrustZone.................................. 23 2.5 Other Techniques.................................. 26 2.5.1 Hardware Replication........................... 26 2.5.2 Hardware Virtualization.......................... 27 2.5.3 Only Software............................... 27 2.6 Discussion...................................... 27 3 Run-Time Security 30 3.1 Access and Usage Control............................. 30 3.2 Data Protection................................... 33 3.3 Reference Monitors................................. 36 3.3.1 Policy Enforcement............................. 36 3.3.2
    [Show full text]
  • ERIM: Secure, Efficient In-Process Isolation with Protection Keys (MPK)
    ERIM: Secure, Efficient In-process Isolation with Protection Keys (MPK) AnjoVahldiek-Oberwagner EslamElnikety NunoO.Duarte Michael Sammler Peter Druschel Deepak Garg Max Planck Institute for Software Systems (MPI-SWS), Saarland Informatics Campus Abstract prevent control-flow hijacks [30], which could circumvent Isolating sensitive state and data can increase the security the bounds checks. On x86-64, pointer masking-based SFI and robustness of many applications. Examples include pro- techniques like Native Client [42] incur overheads of up to tecting cryptographic keys against exploits like OpenSSL’s 42% on the execution of untrusted code [30]. Even with Heartbleed bug or protecting a language runtime from na- hardware-supported bounds checks, like those supported by tive libraries written in unsafe languages. When runtime the IntelMPX ISA extension[26], the overheadis up to 30%, references across isolation boundaries occur relatively in- as shown in by Koning et al. [30] and later in Section 6.5. frequently, then conventional page-based hardware isola- Another approach is to use hardware page protection for tion can be used, because the cost of kernel- or hypervisor- memory isolation [9, 10, 13, 32, 33, 34]. Here, access checks mediated domain switching is tolerable. However, some are performed in hardware as part of the address translation applications, such as the isolation of cryptographic session with no additional overhead on execution within a compo- keys in network-facing services, require very frequent do- nent. However, transferring control between components main switching. In such applications, the overheadof kernel- requires a switch to kernel or hypervisor mode in order to or hypervisor-mediated domain switching is prohibitive.
    [Show full text]
  • Securing Intel Sgx Against Side-Channel Attacks Via Load-Time Synthesis
    SECURING INTEL SGX AGAINST SIDE-CHANNEL ATTACKS VIA LOAD-TIME SYNTHESIS A Dissertation Presented to The Academic Faculty By Ming-Wei Shih In Partial Fulfillment of the Requirements for the Degree Doctor of Philosophy in the School of Georgia Institute of Technology Georgia Institute of Technology December 2019 Copyright © Ming-Wei Shih 2019 SECURING INTEL SGX AGAINST SIDE-CHANNEL ATTACKS VIA LOAD-TIME SYNTHESIS Approved by: Dr. Taesoo Kim, Advisor Dr. Michael Steiner School of Computer Science Security and Privacy Research Georgia Institute of Technology Group Intel Labs Dr. Wenke Lee School of Computer Science Dr. Brendan Saltaformaggio Georgia Institute of Technology School of Computer Science Georgia Institute of Technology Dr. Marcus Peinado Cloud and Infrastructure Security Date Approved: Octobor 23, 2019 Group Microsoft Research To my dear wife, Tiffany, and my family. ACKNOWLEDGEMENTS Foremost, I would like to express my sincere gratitude to my advisor Dr. Taesoo Kim for all the support and guidance he provided to me throughout my Ph.D. study. He has taught me how to conduct research in system security since my first year—when I literally know nothing about how to do so. His solid technical background and logical, critical thinking have always inspired me. I would also like to thank Dr. Marcus Peinado for always providing constructive comments when we collaborated on T-SGX and SGX-Armor. I have learned a lot from working with him. Besides, I would like to thank the rest of my thesis committee: Dr. Wenke Lee, Dr. Michael Steiner, and Dr. Brendan Saltaformaggio for their insightful comments that helped me improve this thesis.
    [Show full text]
  • Lessons Learned from Porting Helenos to RISC-V
    Lessons Learned from Porting HelenOS to RISC-V Martin Děcký [email protected] February 2019 Who Am I Passionate programmer and operating systems enthusiast With a specific inclination towards multiserver microkernels HelenOS developer since 2004 Research Scientist from 2006 to 2018 Charles University (Prague), Distributed Systems Research Group Senior Research Engineer since 2017 Huawei Technologies (Munich), German Research Center, Central Software Institute, OS Kernel Lab Martin Děcký, FOSDEM, February 2nd 2019 Lessons Learned from Porting HelenOS to RISC-V 2 HelenOS in a Nutshell open source general-purpose multiplatform microkernel multiserver operating system designed and implemented from scratch Martin Děcký, FOSDEM, February 2nd 2019 Lessons Learned from Porting HelenOS to RISC-V 4 HelenOS in a Nutshell open source general-purpose multiplatform microkernel multiserver operating system designed and implemented from scratch Custom microkernel Custom user space http://www.helenos.org Martin Děcký, FOSDEM, February 2nd 2019 Lessons Learned from Porting HelenOS to RISC-V 5 HelenOS in a Nutshell open source general-purpose multiplatform microkernel multiserver operating system designed and implemented from scratch 3-clause BSD permissive license https://github.com/HelenOS Martin Děcký, FOSDEM, February 2nd 2019 Lessons Learned from Porting HelenOS to RISC-V 6 HelenOS in a Nutshell open source general-purpose multiplatform microkernel multiserver operating system designed and implemented from scratch Breath-first rather than depth-first
    [Show full text]
  • Memory Corruption Mitigation Via Hardening and Testing
    Memory corruption mitigation via hardening and testing A Dissertation presented by László Szekeres to The Graduate School in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy in Computer Science Stony Brook University May 2017 Copyright by László Szekeres 2017 Stony Brook University The Graduate School László Szekeres We, the dissertation committe for the above candidate for the Doctor of Philosophy degree, hereby recommend acceptance of this dissertation Dr. R. Sekar – Dissertation Advisor Professor, Department of Computer Science Dr. Scott Stoller – Chairperson of Defense Professor, Department of Computer Science Dr. Long Lu – Committee Member Assistant Professor, Department of Computer Science Dr. Franjo Ivančić – External Committee Member Staff Software Engineer, Google Adjunct Assistant Professor, Columbia University This dissertation is accepted by the Graduate School Charles Taber Dean of the Graduate School ii Abstract of the Dissertation Memory corruption mitigation via hardening and testing by László Szekeres Doctor of Philosophy in Computer Science Stony Brook University 2017 Despite decades of research, memory corruption vulnerabilities continue to be at the fore- front of today’s security threats. There are two main avenues for automating defenses against these vulnerabilities: (a) develop automated analysis/testing techniques to find these bugs, or (b) develop software transformations that block their exploitation, or at least make them more difficult (hardening). This dissertation explores both of these avenues. The thesis begins with a general model of memory corruption attacks and a systematic analysis of previous hardening techniques. We show that there none of the existing solutions protect against control-flow hijacks in a both effective and efficient manner.
    [Show full text]
  • Efficient Fault Tolerance Using Intel MPX And
    Efficient Fault Tolerance using Intel MPX and TSX Oleksii Oleksenko*, Dmitrii Kuvaiskii*, Pramod Bhatotia*, Christof Fetzer*, Pascal Felber** * Technische Universitat¨ Dresden, Germany ** University of Neuchatel,ˆ Switzerland Abstract—Hardware faults can cause data corruptions during Memory Memory computation, and they are especially harmful if these corruptions happen in data pointers. Existing solutions, however, incur high performance overheads, which is unacceptable for compute- out-of-bound access intensive applications. In this work, we present an efficient fault- tolerance approach against hardware faults by exploiting the new object bounds object bounds extensions to the x86 architecture. In particular, we propose that Intel MPX can be effectively used to detect faults in data pointers, while Intel TSX can provide roll-back recovery against these corruptions. Our preliminary evaluation supports this hypothesis, and we estimate the average overhead to be roughly around 50%. pointer corrupted pointer I. INTRODUCTION Critical components of the software stack such as operating (a) (b) systems, file systems, and databases are written in a low- level language (primarily, in C/C++) for improved performance Fig. 1: The concept of fault detection using MPX: (a) correct state, (b) a fault in pointer causes object bounds violation. and flexibility in memory management. However, the normal program flow can be arbitrarily corrupted by bit-flips in CPU protection and hardware transactional memory. In particu- or RAM during run-time. The resulting corruptions can lead lar, our approach is based on the new generations of Intel to catastrophic consequences; especially, if the corruption architecture—starting Skylake—with respective support for happens in data pointers—as they can cause the loss of the memory protection via MPX [4] and transactional memory whole data structure [1].
    [Show full text]