Memory Safety for Low- Level Software/Hardware Interactions John - - PowerPoint PPT Presentation

▶
memory safety for low level software hardware interactions
SMART_READER_LITE
LIVE PREVIEW

Memory Safety for Low- Level Software/Hardware Interactions John - - PowerPoint PPT Presentation

Mar 29, 2024 26 likes •560 views

Memory Safety for Low- Level Software/Hardware Interactions John Criswell Nicolas Geoffray Vikram Adve Montreal or Bust! Memory Safety Future is Bright User-space memory safety is improving Safe languages SAFECode, CCured, Baggy

slide-1
SLIDE 1

Memory Safety for Low- Level Software/Hardware Interactions

John Criswell Nicolas Geoffray Vikram Adve

Montreal or Bust!

slide-2
SLIDE 2

Memory Safety Future is Bright

User-space memory safety is improving

Safe languages SAFECode, CCured, Baggy bounds checking,

Softbound, etc

Memory safety for operating systems exists!

Singularity (C#), SPIN (Modula-3) Linux on Secure Virtual Architecture (C)

slide-3
SLIDE 3

A New Enemy Arises: Software/Hardware Interactions

What is a low-level software-hardware interaction?

Instruction that manipulates hardware resources Below semantics of the programming language

Perfectly type-safe code! But:

Can corrupt control-flow or data-flow

Examples:

Processor State I/O Objects MMU mappings

slide-4
SLIDE 4

Memory Safety: Processor State

Operating systems explicitly manage Processor State

Processor states saved in memory buffers

Type-safe stores can modify a saved processor state

Can subvert control/data-flow integrity

R1 R2 R3 PC SP P Memory Pointer in OS

slide-5
SLIDE 5

Memory Safety: Processor State

Operating systems explicitly manage Processor State

Processor states saved in memory buffers

Type-safe stores can modify a saved processor state

Can subvert control/data-flow integrity

R1 R2 R3 PC SP P Memory Pointer in OS

slide-6
SLIDE 6

Memory Safety: Processor State

Operating systems explicitly manage Processor State

Processor states saved in memory buffers

Type-safe stores can modify a saved processor state

Can subvert control/data-flow integrity

R1 R2 R3 PC SP P R1 R2 R3 PC SP CPU Memory Context Switch Pointer in OS

slide-7
SLIDE 7

Memory Safety: I/O

I/O device memory and RAM in same address space However, I/O memory is different

 I/O memory incompatible with standard compiler analysis  I/O memory has side effects on hardware

 Intel E1000E Bug on Linux 2.6

 Invalid write on I/O memory  Damaged Intel E1000E Network Cards  Potential DoS Attack

slide-8
SLIDE 8

Memory Safety: MMU

Virtual Memory Physical Memory

T1* P1 T2* P2

Memory Pointers

MMU can violate type

safety

slide-9
SLIDE 9

Memory Safety: MMU

Virtual Memory Physical Memory

T1* P1 T2* P2

Memory Pointers

MMU can violate type

safety

slide-10
SLIDE 10

Memory Safety: MMU

MMU can make kernel pages

accessible to user-space

 BID9356, BID9686, BID18177

(www.securityfocus.com)

Virtual Memory Physical Memory Virtual Memory Physical Memory User Kernel

T1* P1 T2* P2

Memory Pointers

MMU can violate type

safety

slide-11
SLIDE 11

Memory Safety: MMU

MMU can make kernel pages

accessible to user-space

 BID9356, BID9686, BID18177

(www.securityfocus.com)

Virtual Memory Physical Memory Virtual Memory Physical Memory User Kernel

T1* P1 T2* P2

Memory Pointers

MMU can violate type

safety

slide-12
SLIDE 12

It’s Already Here!

 Intel E1000E Bug  MMU exploits in Linux

Need solutions before these attacks become more sophisticated and commonplace!

slide-13
SLIDE 13

SVA-OS: Memory Safety for Low- Level Software-Hardware Interactions

First system to provide comprehensive memory

safety for low-level software/hardware interactions

Linux 2.4.22 on Secure Virtual Architecture (SVA)

Compiler analysis and runtime checks

Little overhead above and beyond traditional memory

safety Effective at preventing software/hardware exploits

slide-14
SLIDE 14

Outline

Motivation High-level Solutions Design of SVA-OS Experimental Results Future Work and Conclusions

slide-15
SLIDE 15

Foundations: What Do We Need?

System that provides traditional memory safety

SVA-OS will preserve memory safety

Examples

Type-safe languages, e.g. Singularity Compiler techniques for commodity operating

systems, e.g. Secure Virtual Architecture (SVA)

slide-16
SLIDE 16

Solution: Processor State

 New instruction to save old state and restore new state

 State saved in internal SVA-OS memory  State referenced by ID returned from VM

 Policy left to OS

 Scheduling, context switching, signal delivery

R1 R2 PC SP

Process 1: ID 1

R1 R2 PC SP CPU SVA-OS Memory OS Task Structures R1 R2 PC SP

ID1 ID2 ID3 Process 3: ID 2 Process 8: ID 3

slide-17
SLIDE 17

Solution: Memory Mapped I/O

 New instruction to map I/O memory into address space  New instructions to load/store I/O objects  Add run-time checks to ensure that:

 Regular load/stores access memory  I/O accesses access I/O memory

P1 Memory Pointer P2 I/O Pointer

store (v, *p2); iostore (v, *p1);

slide-18
SLIDE 18

Solution: Memory Mapped I/O

 New instruction to map I/O memory into address space  New instructions to load/store I/O objects  Add run-time checks to ensure that:

 Regular load/stores access memory  I/O accesses access I/O memory

P1 Memory Pointer P2 I/O Pointer

store (v, *p2); iostore (v, *p1);

slide-19
SLIDE 19

Solution: Memory Mapped I/O

 New instruction to map I/O memory into address space  New instructions to load/store I/O objects  Add run-time checks to ensure that:

 Regular load/stores access memory  I/O accesses access I/O memory

P1 Memory Pointer P2 I/O Pointer

store (v, *p2); iostore (v, *p1);

slide-20
SLIDE 20

Solution: MMU

 Add run-time checks on MMU updates

 Mapping kernel memory into user-space  Mapping data inconsistent with types

 Same mechanism as VMMs

 Finer-grain checks

Virtual Memory Physical Memory

T1* P1 T2* P2

Virtual Memory Physical Memory User Kernel

slide-21
SLIDE 21

Solution: MMU

 Add run-time checks on MMU updates

 Mapping kernel memory into user-space  Mapping data inconsistent with types

 Same mechanism as VMMs

 Finer-grain checks

Virtual Memory Physical Memory

T1* P1 T2* P2

Virtual Memory Physical Memory User Kernel

slide-22
SLIDE 22

Solution: MMU

 Add run-time checks on MMU updates

 Mapping kernel memory into user-space  Mapping data inconsistent with types

 Same mechanism as VMMs

 Finer-grain checks

Virtual Memory Physical Memory

T1* P1 T2* P2

Virtual Memory Physical Memory User Kernel

slide-23
SLIDE 23

Solution: MMU

 Add run-time checks on MMU updates

 Mapping kernel memory into user-space  Mapping data inconsistent with types

 Same mechanism as VMMs

 Finer-grain checks

Virtual Memory Physical Memory

T1* P1 T2* P2

Virtual Memory Physical Memory User Kernel

slide-24
SLIDE 24

Solution: MMU

 Add run-time checks on MMU updates

 Mapping kernel memory into user-space  Mapping data inconsistent with types

 Same mechanism as VMMs

 Finer-grain checks

Virtual Memory Physical Memory

T1* P1 T2* P2

Virtual Memory Physical Memory User Kernel

slide-25
SLIDE 25

Outline

Motivation High-level Solutions Design of SVA-OS Experimental Results Future Work and Conclusions

slide-26
SLIDE 26

Secure Virtual Architecture1

 Compiler-based virtual machine

 Hosts a commodity OS (e.g., Linux)  Provides traditional memory safety guarantees (control-flow and

data-flow integrity)

Memory Safety Run-time Library

Hardware

OS Memory Allocator

SVA Virtual Machine

OS Kernel

SVA ISA Native ISA

Native Code Generator SVA Run-time Library Safety Compiler

Hardware

1Criswell et al. [SOSP 2007]

slide-27
SLIDE 27

From SVA to SVA-OS

Extend the SVA software/hardware interface

New instructions control software/hardware

interactions

Enforce memory safety for low-level operations

Use static analysis when possible Add run-time checks when necessary

slide-28
SLIDE 28

Solution: Processor State

 Save old state and place new state in a single instruction

 sva_swap_integer

 Return opaque handle  Buffer saved in SVA-OS memory

 Buffer released on sva_swap_integer call

R1 R2 PC SP

Process 1: ID 1

CPU SVA-OS Memory OS Task Structures R1 R2 PC SP

ID1 ID2

PC SP R1 R2

ID3 Process 3: ID 2 Process 8: ID 3

slide-29
SLIDE 29

Solution: Processor State

 Save old state and place new state in a single instruction

 sva_swap_integer

 Return opaque handle  Buffer saved in SVA-OS memory

 Buffer released on sva_swap_integer call

R1 R2 PC SP

Process 1: ID 1

R1 R2 PC SP CPU SVA-OS Memory OS Task Structures R1 R2 PC SP

ID1 ID2 Process 3: ID 2 Process 8: ID 3

slide-30
SLIDE 30

Solution: Memory Mapped I/O

Operating system uses a pseudo-allocator

Map I/O objects into virtual address space

New instructions for I/O reads and writes

sva_io_readb, sva_io_writeb

Compiler marks I/O memory as type-unknown

Load/store check on each access Load/store checks on memory objects that alias

slide-31
SLIDE 31

Solution: MMU

VMM-like interface to declare and update MMU mappings

 sva_declare_l1_page, sva_declare_l2_page  sva_update_l1_mapping, sva_update_l2_mapping

Runtime checks for typed memory

 Pointer analysis in SVA segregates data by types  SVA-OS ensures this stays consistent

Run-time checks for dividing memory

 SVA-OS memory and kernel memory  Kernel memory and user-space memory  I/O memory and regular kernel memory

slide-32
SLIDE 32

Linux 2.4 Port on SVA-OS

Less than 100 lines changes from original SVA

Linux port

switch_to ➞ sva_swap_integer readb ➞ sva_io_readb set_pte ➞ sva_update_l1_mapping pte_alloc_one ➞ sva_declare_l1_page

Compiler changes:

Allocation of I/O objects: ioremap

slide-33
SLIDE 33

Outline

Motivation High-level Solutions Design of SVA-OS Experimental Results Future Work and Conclusions

slide-34
SLIDE 34

Does It Work?

Tested two real world MMU exploits

BID9356, BID9686 on Linux 2.4 BID18177 exploit code not available

Injected errors into our Linux 2.4 port

New system calls

Studied the E1000E Intel Network bug

Paper study because only on Linux 2.6

slide-35
SLIDE 35

MMU Exploits on Linux 2.4

Virtual Memory Physical Memory User Kernel Map count = 1

BID9356

 fork, mmap

slide-36
SLIDE 36

MMU Exploits on Linux 2.4

Virtual Memory Physical Memory User Kernel Map count = 2

BID9356

 fork, mmap

slide-37
SLIDE 37

MMU Exploits on Linux 2.4

Virtual Memory Physical Memory User Kernel Map count = 3

BID9356

 fork, mmap

slide-38
SLIDE 38

MMU Exploits on Linux 2.4

Virtual Memory Physical Memory User Kernel Map count = 4

BID9356

 fork, mmap

slide-39
SLIDE 39

MMU Exploits on Linux 2.4

Virtual Memory Physical Memory User Kernel Map count = 0

BID9356

 fork, mmap

slide-40
SLIDE 40

MMU Exploits on Linux 2.4

Virtual Memory Physical Memory User Kernel Map count = 0

BID9356

 fork, mmap

slide-41
SLIDE 41

MMU Exploits on Linux 2.4

Virtual Memory Physical Memory User Kernel Map count = 0

BID9356

 fork, mmap

slide-42
SLIDE 42

MMU Exploits on Linux 2.4

BID9686

 Missing error check on mremap  MMU mappings not cleared

Virtual Memory Physical Memory User Kernel Map count = 0

BID9356

 fork, mmap

slide-43
SLIDE 43

MMU Exploits on Linux 2.4

BID9686

 Missing error check on mremap  MMU mappings not cleared

Virtual Memory Physical Memory User Kernel Map count = 0

Both bugs were detected by SVA-OS, not SVA

BID9356

 fork, mmap

slide-44
SLIDE 44

Error Injection

Modification of Processor State Double mapping of a type-safe memory object Modify metadata of SVA with incorrect bounds

slide-45
SLIDE 45

Error Injection

Modification of Processor State Double mapping of a type-safe memory object Modify metadata of SVA with incorrect bounds

SVA-OS: Caught as an invalid integer to pointer cast SVA: control flow changed

slide-46
SLIDE 46

Error Injection

Modification of Processor State Double mapping of a type-safe memory object Modify metadata of SVA with incorrect bounds

SVA-OS: Caught as an invalid integer to pointer cast SVA-OS: Second mapping caught by MMU checks SVA: control flow changed SVA: Subsequent store succeeds

slide-47
SLIDE 47

Error Injection

Modification of Processor State Double mapping of a type-safe memory object Modify metadata of SVA with incorrect bounds

SVA-OS: Caught as an invalid integer to pointer cast SVA-OS: Second mapping caught by MMU checks SVA: Memory safety guarantees disabled SVA: control flow changed SVA: Subsequent store succeeds SVA-OS:Access to SVA memory caught by MMU checks

slide-48
SLIDE 48

E1000E Bug on Linux 2.6

cmpxchg on dangling pointer

Instruction thought it was code memory Unpredictable behavior on I/O memory Network card damaged

With SVA-OS

No I/O memory mapped on code page Load/Store checks on I/O memory

slide-49
SLIDE 49

Web Server Bandwidth: thttpd

0.2500 0.5000 0.7500 1.0000 1 2 4 8 16 32 64 128 256 512 1024

Web Server Bandwidth Normalized to Native

File Size (KB) SVA SVA-OS

 Athlon 2100+, 1GB of RAM, 1Gb/s network  Higher is better  Micro-benchmark overheads in paper

slide-50
SLIDE 50

User-Application Benchmarks

Benchmark i386 (s) SVA (s) SVA-OS (s) % Increase (i386 to SVA-OS) bzip2 18.7 18.3 18.0 0.0% lame 133.3 132.0 126.0

  • 0.1%

perl 22.3 22.3 22.3 0.0%

 Negligible overhead on user-space applications

slide-51
SLIDE 51

Outline

Motivation High-level Solutions Design of SVA-OS Experimental Results Future Work and Conclusions

slide-52
SLIDE 52

Future Work

Improve Static Analysis

Reduce run-time checks

Additional Security Properties

Information flow control

Apply to other systems

Type-safe language OS, e.g. Singularity JVMs, hypervisors

slide-53
SLIDE 53

Contributions

Identified memory-safety violations from low-

level software/hardware operations

First system to provide comprehensive safety

guarantees for such operations

Leaves control under OS Incurs little run-time overhead above SVA

Questions?

See what we do at http://sva.cs.uiuc.edu