Goanna

1
Goanna

• Rapid OS Development Using ptrace

Rick Spillane, Charles P. Wright, Gopalan
Sivathanu, and Erez Zadok Stony Brook University
2
Outline

• The Problem
• Monitor Design
• Complexity Evaluation
• Performance Evaluation
• Conclusions and Future Work

3
The Problem

• OS development is hard
• OS prototyping is opportunity-risk
• Need proof-of-concept before deeper work
• Even proof-of-concept is hard
• Thus use prototyping framework
• But some problems need
• Rapid Prototyping AND
• Powerful Prototyping
• E.g., transaction rollback on VFS caches

4
Our Solution

• Intercepts system service requests
• ptrace is great for this
• can implement service handlers in user space
• is modular
• insulated from lower-level abstractions
• developers can start from scratch
• easily fall back on OS at any time
• is powerful
• can intercept all system calls and signals, even
  single instructions

5
Qualitative Comparison

• In-Kernel difficult but high performance
• FUSE lacks powerful prototypes

6
Outline

• The Problem
• Monitor Design
• Complexity Evaluation
• Performance Evaluation
• Conclusions and Future Work

7
Birds Eye View

• Uses ptrace to monitor processes
• Uses another user process to intercept system
  calls, modify arguments, and write back to
  processs memory
• APIs run natively in address space of monitor
• Each monitor instance can handle multiple
  processes
• Cons context switches, architecture dependent,
  and memory-copies
• 353 of 12,187 lines of the monitor reference
  80x86 registers

8
Goanna Organization

• The monitor forks a child, and monitors all of
  its descendants
• For each monitored process we create a process
  control block (PCB)
• The PCB contains process state
• Analogous to OS PCB (e.g., task_struct)
• InUser, InCall, InForceRet, RedoCall
• Per system call states
• Present working directory
• Open file table

9
Goanna Architecture
int 0x80
KERNEL
User Process 1
iret

User Process 2

int 0x80
User Process N
iret
wait
Goanna Monitor
ptrace
10
Fundamental Tracing Primitives

• attach
• Connect to a process
• syscall
• Run until the next system call
• getregs, setregs
• Examine and manipulate system call number,
  arguments and return values
• peek, poke
• Read or write from the processs memory

11
Primitives for Read
(1) int 0x80
KERNEL
(2) wait
(3) getregs
(4) setregs
(5) poke
Goanna Monitor
User Process
(6) syscall
(7) wait
(8) setregs
(9) syscall
(10) iret
12
Example File Systems

• Pass Through
• Do nothing but name translation by mount
• AES Encryption
• (De/En)crypt data read and written to FS
• ISO 9660
• Transparently access an ISO CD-ROM without
  administrator intervention

13
Outline

• The Problem
• Monitor Design
• Complexity Evaluation
• Performance Evaluation
• Conclusions and Future Work

14
Monitor Complexity

• Throughout this work the monitor has saved us
  development time
• Avoids kernel changes
• Leverages user-level APIs (BDB, libiso, openssl,
  etc)
• Permits simple debugging
• Still only a qualitative assessment
• We will quantify how much is saved by developing
  file systems using Goanna

15
Complexity Metrics

• Lines of Code
• Rough estimate
• Related to programmer productivity
• McCabe Cyclomatic Complexity
• Number of linearly independent paths
• Strongly related to number of test cases required
  for complete coverage
• Does not count assignment or operators

16
Framework Complexity
17
Pass-through Complexity
18
Encryption Complexity
19
ISO9660 Complexity
20
Outline

• The Problem
• Monitor Design
• Complexity Evaluation
• Performance Evaluation
• Conclusions and Future Work

21
Performance Evaluation

• Evaluated Goanna on a 1.7Ghz Pentium IV with 1GB
  of RAM
• Fedora Core 4 (Updated as of 7/19/05)
• Evaluated each file system example
• Pass-through
• Encryption
• Postmark Create, delete, read and append to
  files

22
Performance Stats

• MONPASS 18.3 overhead compared to XFS256
• XFS uses 512-byte inodes to improve EA
• MONCRYPT overhead 43.1 compared to XFS512

23
Outline

• The Problem
• Monitor Design
• Complexity Evaluation
• Performance Evaluation
• Conclusions and Future Work

24
Conclusions

• Research projects often require rapid prototyping
  and powerful prototypes
• Modularity facilitates fast development
• Goanna provides excellent flexible framework for
  development
• Performance overheads are competitive with other
  systems
• Clear complexity reductions result in saved time
  in development

25
Future Work

• Improve support so that almost all applications
  can run through Goanna
• Explore potential performance gains

26
Questions?

• Rapid File System Development Using ptrace

Rick Spillane, Charles P. Wright, Gopalan
Sivathanu, and Erez Zadok Stony Brook University
27
LD_PRELOAD or libc?

• LD_PRELOAD
• Can handle read(3) and write(3)
• fprintf also needs to be interposed, because libc
  wont use our new replaced read and write!
• C Library
• On Linux, the most compatible libc is glibc
• Dietlibc is the main competitor, and it
  purposefully focuses on being a small libc,
  rather than compatibility/implementation of every
  feature
• Glibc is big and unwieldy 852,429 lines
• Circular dependencies between BDB and glibc
• Both are less transparent than ptrace!

28
ptrace context switches

• Application transfers control to kernel with int
  0x80
• Kernel transfers control to monitor with wait
• Monitor examines the process registers w/
  GETREGS
• Kernel returns to monitor.
• Monitor nullifies the registers (SETREGS)
• Kernel returns to monitor.
• Monitor calls PTRACE_SYSCALL
• Kernel returns to monitor.
• Monitor issues wait.
• Kernel returns to monitor.
• Monitor forces a return value (SETREGS)
• Kernel returns to monitor.
• Monitor calls PTRACE_SYSCALL
• Kernel returns to monitor.
• Monitor issues wait.
• Kernel transfers control back to the user
  process.

29
CHECKEMU context switches

• Application transfers control to kernel with int
  0x80
• Kernel transfers control to monitor with wait
• Monitor examines the process registers w/
  GETREGS
• Kernel returns to monitor.
• Monitor forces a return value (SETREGS)
• Kernel returns to monitor.
• Monitor calls PTRACE_CHECKEMU
• Kernel returns to monitor.
• Monitor issues wait.
• Kernel transfers control back to the user
  process.

30
Related Work

• Ufo
• Built a FTP/HTTP file system using a ptrace
  monitor on Solaris
• Only handled open, close, stat, etc.
• Janus is another ptrace monitor that sandboxes
  applications
• UML implements an OS using ptrace
• SLIC is a toolkit that lets user-level servers
  register handlers for many OS entry points (e.g.,
  system calls, signals)