DOCSLIB.ORG

Extending the ELF Core Format for Forensics Snapshots

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Extending the ELF Core Format for Forensics Snapshots Leviathan Research Extending the ELF Core Format for Forensics Snapshots Ryan O’Neill Security Consultant 10 November 2014 limitless innovation. no compromise © 2014 Leviathan Security Group Incorporated. All Rights Reserved. This document contains information, which is protected by copyright. Disclaimer No trademark, copyright, or patent licenses are expressly or implicitly granted (herein) with this analysis, report, or white paper. All brand names and product names used in this document are trademarks, registered trademarks, or trade names of their respective holders. Leviathan Security Group is not associated with any other vendors or products mentioned in this document. Contents 1 Abstract 3 2 Introduction 4 2.1 ELF Core Files (ET_CORE) 5 2.2 What do I mean by forensic analysis? 6 3 The Extended Core File Snapshot Format 8 3.1 Design Goals 8 3.2 Implementation Details 12 3.2.1 Section Header Table Reconstruction 12 3.2.2 Symbol Table Reconstruction 14 3.3 Process specific information found in /proc 16 3.4 Forensic Analysis Using the ECFS Format 17 3.5 Infection Types 18 3.5.1 PLTGOT hooks 18 3.5.2 Function Trampolines 19 3.5.3 Shared Library Injection 19 3.5.4 Malicious Code Modifications 19 4 Making ECFS Snapshot Utility Available 20 5 References 21 1 Abstract Malware authors often apply advanced techniques to execute and hide malicious activity on victim Linux systems. ELF runtime infections are among those techniques; they mutate the memory of a victim process to then modify its workings while maintaining stealth against disk-based forensics. To detect ELF runtime infections, analysts combine live debugging of the victim process and dumping a core file or taking a memory snapshot for offline analysis. This pervasive approach and the various methods used for detection are unwieldy and were never intended for use in forensic investigation; they demand room for improvement. In this paper I describe my Extended Core File Snapshot (ECFS) format, an extension to the Linux ELF core file format. I show that ECFS accurately captures all relevant, in-memory forensic information necessary for an analyst to diagnose common ELF memory injection attacks, and I explain its application in real-world scenarios. ECFS allows for both offline debugger (GDB) analysis of snapshot files and interoperability with pervasive static ELF Binary analysis tools. In addition to capturing available information via existing techniques, such as with Volatility [9] process dumps, ECFS uses a novel technique to aid analysis by identifying dynamic symbols and local function entry points that are generally stripped away in production binaries. I will provide an open source implementation of ECFS and supporting tools in January of 2015. 3 2 Introduction The actors behind UNIX-based malware attacks have a diverse set of goals, from bitcoin mining to staging targeted attacks against large institutions. While not all malware requires the use of sophisticated methods, the majority of traditional malware attacks aim to achieve stealth, persistence, and elevation of privilege by exploiting resident components of the victim system. Perhaps the most well publicized technique for opening a malicious backdoor in a Linux machine is via the notorious kernel rootkit. However, in cases where installing a kernel rootkit isn't feasible or desired, attackers are increasingly looking towards other techniques such as ELF runtime infections. ELF runtime infections infect process memory in an attempt to backdoor or modify the workings of a running process, often without requiring root privileges while evading disk-based forensics techniques. There are very few types of software that are capable of ascertaining the complexities and nuances of these ELF runtime infections and performing the analysis by hand is a resource-consuming task, even for the expert. As it stands there are approximately four standard approaches used by defenders to analyze the memory of a running process for ELF runtime infections: 1. Use the ptrace system call or ptrace-assisted debugger such as GDB to analyze a running instance of the suspect process 2. Dump /proc/<pid>/mem into a file for offline analysis 3. Generate a core file for offline analysis with GDB 4. Generate a process memory dump using Volatility for analysis Ideally, the dynamic and static analysis techniques listed above are used in combination to identify ELF runtime infections, but sometimes the realities of forensic analysis requires using them in isolation. Specifically, it may not be feasible to leave a victim process running or to maintain access to a victim Linux system to allow thorough dynamic analysis. Even when both static analysis and dynamic analysis of a victim process are possible, automating forensics analysis of existing information in its various locations and formats can be cumbersome. My research and this paper provide tools to address these shortcomings. The ECFS format discussed in this paper was originally designed as the native snapshot format for VMA Vudu [1], which is a process memory and binary forensics analysis tool for Linux that also may also act as a host-based intrusion detection system. While I designed ECFS specifically as the file format for VMA Vudu [1], it became clear during its development that it could also be instrumental for manual offline forensics analysis of process memory and that a broader audience could make use of it with Linux binutils [10]. This is because ECFS is compatible with common ELF specifications, and includes detailed information about a respective process. The forensic-relevant information is stored in such a way that common GNU utilities such as objdump and readelf will suffice for analyzing an ECFS snapshot when looking for the presence of an attacker within a process. ECFS modifies the ELF design of the core file format to support both storing of forensic-relevant information and analysis via ELF binary analysis tools. As a core file, an ECFS file can be readily analyzed via a debugger (such as GDB) after modifying a single field in its ELF header. Otherwise it is readable via any tool capable of viewing ELF section headers, program headers, and symbol tables. The ECFS tool, 4 which I specifically designed to create process memory snapshot files, has been forked from VMA Vudu and is maintained as a standalone project. 2.1 ELF Core Files (ET_CORE) Currently every UNIX flavor operating system that supports ELF adopts the ELF core file format and will generate a core file upon signaling a process with signal 11 SIGSEGV. The output file is a perfect snapshot of all the memory mappings from the process image with an ELF header of type ET_CORE. In the PT_NOTE segment a plethora of information is stored about what shared libraries are mapped, the CPU registers, signal information, process state, and personality. These are all stored as ELF notes. The ELF notes segment is a good place to pass auxiliary information and is the location that GDB looks to find this data when debugging a core file. This data can be viewed in a core file by reading the notes section with the readelf utility. Each OS will have a slight variation of the way this information is stored in the notes of the file. The notes from a regular Core file in Linux: ryan@elfmaster:~$ readelf -n core Displaying notes found at file offset 0x00000430 with length 0x00000b74: Owner Data size Description CORE 0x00000150 NT_PRSTATUS (prstatus structure) CORE 0x00000088 NT_PRPSINFO (prpsinfo structure) CORE 0x00000080 NT_SIGINFO (siginfo_t data) CORE 0x00000130 NT_AUXV (auxiliary vector) CORE 0x0000021f NT_FILE (mapped files) Page size: 4096 Start End Page Offset 0x0000000000400000 0x0000000000401000 0x0000000000000000 /home/ryan/host 0x0000000000600000 0x0000000000601000 0x0000000000000000 /home/ryan/host 0x0000000000601000 0x0000000000602000 0x0000000000000001 /home/ryan/host 0x00007f579d462000 0x00007f579d61d000 0x0000000000000000 /lib/x86_64-linux-gnu/libc-2.19.so 0x00007f579d61d000 0x00007f579d81d000 0x00000000000001bb /lib/x86_64-linux-gnu/libc-2.19.so 0x00007f579d81d000 0x00007f579d821000 0x00000000000001bb /lib/x86_64-linux-gnu/libc-2.19.so 0x00007f579d821000 0x00007f579d823000 0x00000000000001bf /lib/x86_64-linux-gnu/libc-2.19.so 5 0x00007f579d828000 0x00007f579d84b000 0x0000000000000000 /lib/x86_64-linux-gnu/ld-2.19.so 0x00007f579da4a000 0x00007f579da4b000 0x0000000000000022 /lib/x86_64-linux-gnu/ld-2.19.so CORE 0x00000200 NT_FPREGSET (floating point registers) LINUX 0x00000340 NT_X86_XSTATE (x86 XSAVE extended state) From this readelf output you can see that the prstatus structure, the prpsinfo structure, and siginfo_t are stored in the notes. The auxiliary vector contains information about the setup of the stack at program loading time. The Linux source code files fs/binfmt_elf.c and fs/binfmt_fdpic_elf.c contain the code that handle all ELF loading and core dumps. For every memory mapping in the process image that is dumped into the ELF core file there is a program header in the program header table. This includes all of the shared libraries and any memory mapped segments or mapped files. The Linux kernel adheres to contingencies when deciding to dump memory mappings. For instance, it will not dump memory mapped IO devices. The Virtual Dynamic Shared Object (VDSO), stack, and heap are all dumped. Shared memory mappings and anonymous mappings that have been written to are also dumped. It is true that ELF core files are extremely useful when debugging, especially when there are debugging information and symbols present in the original file, but they do not lend themselves well to in-depth forensics analysis, nor were they ever intended to serve as such. Also they are not very useful as a standalone file; you must load the original executable and the core file into GDB together in order to make real use of a core file. The objdump utility which usually relies strictly on ELF section headers will actually allow you to read a core file even in the absence of section headers but only in the simplest way (using phdr's), which would be nearly useless for forensics.
Load more

Recommended publications
  • Introduction to Debugging the Freebsd Kernel
    Introduction to Debugging the FreeBSD Kernel John H. Baldwin Yahoo!, Inc. Atlanta, GA 30327 [email protected], http://people.FreeBSD.org/˜jhb Abstract used either directly by the user or indirectly via other tools such as kgdb [3]. Just like every other piece of software, the The Kernel Debugging chapter of the FreeBSD kernel has bugs. Debugging a ker- FreeBSD Developer’s Handbook [4] covers nel is a bit different from debugging a user- several details already such as entering DDB, land program as there is nothing underneath configuring a system to save kernel crash the kernel to provide debugging facilities such dumps, and invoking kgdb on a crash dump. as ptrace() or procfs. This paper will give a This paper will not cover these topics. In- brief overview of some of the tools available stead, it will demonstrate some ways to use for investigating bugs in the FreeBSD kernel. FreeBSD’s kernel debugging tools to investi- It will cover the in-kernel debugger DDB and gate bugs. the external debugger kgdb which is used to perform post-mortem analysis on kernel crash dumps. 2 Kernel Crash Messages 1 Introduction The first debugging service the FreeBSD kernel provides is the messages the kernel prints on the console when the kernel crashes. When a userland application encounters a When the kernel encounters an invalid condi- bug the operating system provides services for tion (such as an assertion failure or a memory investigating the bug. For example, a kernel protection violation) it halts execution of the may save a copy of the a process’ memory current thread and enters a “panic” state also image on disk as a core dump.
    [Show full text]
  • Process and Memory Management Commands
    Process and Memory Management Commands This chapter describes the Cisco IOS XR software commands used to manage processes and memory. For more information about using the process and memory management commands to perform troubleshooting tasks, see Cisco ASR 9000 Series Aggregation Services Router Getting Started Guide. • clear context, on page 2 • dumpcore, on page 3 • exception coresize, on page 6 • exception filepath, on page 8 • exception pakmem, on page 12 • exception sparse, on page 14 • exception sprsize, on page 16 • follow, on page 18 • monitor threads, on page 25 • process, on page 29 • process core, on page 32 • process mandatory, on page 34 • show context, on page 36 • show dll, on page 39 • show exception, on page 42 • show memory, on page 44 • show memory compare, on page 47 • show memory heap, on page 50 • show processes, on page 54 Process and Memory Management Commands 1 Process and Memory Management Commands clear context clear context To clear core dump context information, use the clear context command in the appropriate mode. clear context location {node-id | all} Syntax Description location{node-id | all} (Optional) Clears core dump context information for a specified node. The node-id argument is expressed in the rack/slot/module notation. Use the all keyword to indicate all nodes. Command Default No default behavior or values Command Modes Administration EXEC EXEC mode Command History Release Modification Release 3.7.2 This command was introduced. Release 3.9.0 No modification. Usage Guidelines To use this command, you must be in a user group associated with a task group that includes appropriate task IDs.
    [Show full text]
  • Also Includes Slides and Contents From
    The Compilation Toolchain Cross-Compilation for Embedded Systems Prof. Andrea Marongiu ([email protected]) Toolchain The toolchain is a set of development tools used in association with source code or binaries generated from the source code • Enables development in a programming language (e.g., C/C++) • It is used for a lot of operations such as a) Compilation b) Preparing Libraries Most common toolchain is the c) Reading a binary file (or part of it) GNU toolchain which is part of d) Debugging the GNU project • Normally it contains a) Compiler : Generate object files from source code files b) Linker: Link object files together to build a binary file c) Library Archiver: To group a set of object files into a library file d) Debugger: To debug the binary file while running e) And other tools The GNU Toolchain GNU (GNU’s Not Unix) The GNU toolchain has played a vital role in the development of the Linux kernel, BSD, and software for embedded systems. The GNU project produced a set of programming tools. Parts of the toolchain we will use are: -gcc: (GNU Compiler Collection): suite of compilers for many programming languages -binutils: Suite of tools including linker (ld), assembler (gas) -gdb: Code debugging tool -libc: Subset of standard C library (assuming a C compiler). -bash: free Unix shell (Bourne-again shell). Default shell on GNU/Linux systems and Mac OSX. Also ported to Microsoft Windows. -make: automation tool for compilation and build Program development tools The process of converting source code to an executable binary image requires several steps, each with its own tool.
    [Show full text]
  • Post Mortem Crash Analysis
    Post Mortem Crash Analysis Johan Heander & Magnus Malmborn January 14, 2007 Abstract To improve the quality and reliability of embedded systems it is important to gather information about errors in units already sold and deployed. To achieve this, a system for transmitting error information from the customer back to the developers is needed, and the developers must also have a set of tools to analyze the error reports. The purpose of this master thesis was to develop a fully functioning demon- stration system for collection, transmission and interpretation of error reports from Axis network cameras using the Linux operating system. The system has been shown to handle both kernel and application errors and conducts automatic analysis of received data. It also uses standard HTTP protocol for all network transfers making it easy to use even on firewalled net- works. i ii Acknowledgement We would like to thank our LTH supervisor Jonas Skeppstedt for all he has taught us about computer science in general and operating systems and the C programming language in particular. We would also like to thank Mikael Starvik at Axis Communications for quickly providing us with all hardware and information we needed to complete this thesis, and for providing us with support during our implementation and writing. Finally we thank all the developers working at Axis Communications, many of whom have provided input and reflections on our work. iii iv Contents 1 Introduction 1 1.1 Problem description . 1 1.2 Problem analysis . 1 2 Background 3 2.1 Kernel crashes . 3 2.2 User space crashes .
    [Show full text]
  • Riscv-Software-Stack-Tutorial-Hpca2015
    Software Tools Bootcamp RISC-V ISA Tutorial — HPCA-21 08 February 2015 Albert Ou UC Berkeley [email protected] Preliminaries To follow along, download these slides at http://riscv.org/tutorial-hpca2015.html 2 Preliminaries . Shell commands are prefixed by a “$” prompt. Due to time constraints, we will not be building everything from source in real-time. - Binaries have been prepared for you in the VM image. - Detailed build steps are documented here for completeness but are not necessary if using the VM. Interactive portions of this tutorial are denoted with: $ echo 'Hello world' . Also as a reminder, these slides are marked with an icon in the upper-right corner: 3 Software Stack . Many possible combinations (and growing) . But here we will focus on the most common workflows for RISC-V software development 4 Agenda 1. riscv-tools infrastructure 2. First Steps 3. Spike + Proxy Kernel 4. QEMU + Linux 5. Advanced Cross-Compiling 6. Yocto/OpenEmbedded 5 riscv-tools — Overview “Meta-repository” with Git submodules for every stable component of the RISC-V software toolchain Submodule Contents riscv-fesvr RISC-V Frontend Server riscv-isa-sim Functional ISA simulator (“Spike”) riscv-qemu Higher-performance ISA simulator riscv-gnu-toolchain binutils, gcc, newlib, glibc, Linux UAPI headers riscv-llvm LLVM, riscv-clang submodule riscv-pk RISC-V Proxy Kernel (riscv-linux) Linux/RISC-V kernel port riscv-tests ISA assembly tests, benchmark suite All listed submodules are hosted under the riscv GitHub organization: https://github.com/riscv 6 riscv-tools — Installation . Build riscv-gnu-toolchain (riscv*-*-elf / newlib target), riscv-fesvr, riscv-isa-sim, and riscv-pk: (pre-installed in VM) $ git clone https://github.com/riscv/riscv-tools $ cd riscv-tools $ git submodule update --init --recursive $ export RISCV=<installation path> $ export PATH=${PATH}:${RISCV}/bin $ ./build.sh .
    [Show full text]
  • Project 0) Inside Your 354 Directory
    Assignment 0 1. Learning Goals 1. Learn some basic unix/linux commands. 2. Start using a text editor of your choice. 3. Become familiar with the build process. 4. Modify a simple C program. 5. Learn how to submit your assignments. 2. Logistics 1. All work for this assignment is to be done on one of the department's instructional Unix/Linux machines. You are welcome to remotely login using ssh, putty, etc., but you will have to figure out those details on your own. It is not that hard really. 2. All assignments in this course will be graded only on CS departmental machines (e.g. Galapagos lab at CS first floor, Room No: 1366) running Linux Operating System. It is your responsibility to make sure that your code runs on these machines correctly. 3. General Advice If you are not using the CS departmental machines with Linux Operating System and would like to code using your laptop then: 1. Please DON’T use an Integrated Development Environment (IDE) for learning to code in C. It’ll hide many of the low­level details from you. You can become a good C programmer only if you understand all these low­level details. 2. Avoid using Windows Operating System for writing C code since the compiler that we’ll use for grading your assignments is gcc (GNU C Compiler) which is a Unix/Linux based C compiler. 3. If you still want to use a computer which already has a Windows OS, then you should have a virtual machine (VMware or Virtualbox) to run a Linux OS or Cygwin (which contains tools like gcc) installed on your Windows machine.
    [Show full text]
  • Linux Core Dumps
    Linux Core Dumps Kevin Grigorenko [email protected] Many Interactions with Core Dumps systemd-coredump abrtd Process Crashes Ack! 4GB File! Most Interactions with Core Dumps Poof! Process Crashes systemd-coredump Nobody abrtd Looks core kdump not Poof! Kernel configured Crashes So what? ● Crashes are problems! – May be symptoms of security vulnerabilities – May be application bugs ● Data corruption ● Memory leaks – A hard crash kills outstanding work – Without automatic process restarts, crashes lead to service unavailability ● With restarts, a hacker may continue trying. ● We shouldn't be scared of core dumps. – When a dog poops inside the house, we don't just `rm -f $poo` or let it pile up, we try to figure out why or how to avoid it again. What is a core dump? ● It's just a file that contains virtual memory contents, register values, and other meta-data. – User land core dump: Represents state of a particular process (e.g. from crash) – Kernel core dump: Represents state of the kernel (e.g. from panic) and process data ● ELF-formatted file (like a program) User Land User Land Crash core Process 1 Process N Kernel Panic vmcore What is Virtual Memory? ● Virtual Memory is an abstraction over physical memory (RAM/swap) – Simplifies programming – User land: process isolation – Kernel/processor translate virtual address references to physical memory locations 64-bit Process Virtual 8GB RAM Address Space (16EB) (Example) 0 0 16 8 EB GB How much virtual memory is used? ● Use `ps` or similar tools to query user process virtual memory usage (in KB): – $ ps -o pid,vsz,rss -p 14062 PID VSZ RSS 14062 44648 42508 Process 1 Virtual 8GB RAM Memory Usage (VSZ) (Example) 0 0 Resident Page 1 Resident Page 2 16 8 EB GB Process 2 How much virtual memory is used? ● Virtual memory is broken up into virtual memory areas (VMAs), the sum of which equal VSZ and may be printed with: – $ cat /proc/${PID}/smaps 00400000-0040b000 r-xp 00000000 fd:02 22151273 /bin/cat Size: 44 kB Rss: 20 kB Pss: 12 kB..
    [Show full text]
  • The Complete Freebsd
    The Complete FreeBSD® If you find errors in this book, please report them to Greg Lehey <grog@Free- BSD.org> for inclusion in the errata list. The Complete FreeBSD® Fourth Edition Tenth anniversary version, 24 February 2006 Greg Lehey The Complete FreeBSD® by Greg Lehey <[email protected]> Copyright © 1996, 1997, 1999, 2002, 2003, 2006 by Greg Lehey. This book is licensed under the Creative Commons “Attribution-NonCommercial-ShareAlike 2.5” license. The full text is located at http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode. You are free: • to copy, distribute, display, and perform the work • to make derivative works under the following conditions: • Attribution. You must attribute the work in the manner specified by the author or licensor. • Noncommercial. You may not use this work for commercial purposes. This clause is modified from the original by the provision: You may use this book for commercial purposes if you pay me the sum of USD 20 per copy printed (whether sold or not). You must also agree to allow inspection of printing records and other material necessary to confirm the royalty sums. The purpose of this clause is to make it attractive to negotiate sensible royalties before printing. • Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. • For any reuse or distribution, you must make clear to others the license terms of this work. • Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above.
    [Show full text]
  • Exniffer: Learning to Rank Crashes by Assessing the Exploitability from Memory Dump
    Exniffer: Learning to Rank Crashes by Assessing the Exploitability from Memory Dump Thesis submitted in partial fulfillment of the requirements for the degree of MS in Computer Science & Engineering by Research by Shubham Tripathi 201407646 [email protected] International Institute of Information Technology Hyderabad - 500 032, INDIA March 2018 Copyright c Shubham Tripathi, March 2018 All Rights Reserved International Institute of Information Technology Hyderabad, India CERTIFICATE It is certified that the work contained in this thesis, titled “Exniffer: Learning to Rank Crashes by Assessing the Exploitability from Memory Dump” by Shubham Tripathi, has been carried out under my supervision and is not submitted elsewhere for a degree. Date Adviser: Prof. Sanjay Rawat “Contemplate and reflect upon knowledge, and you will become a benefactor to others.” To my parents Acknowledgments I would like to express my gratitude to my adviser, Dr. Sanjay Rawat. Sanjay sir helped me staying focused on problems and provided new directions to approach them. Working with him, I have devel- oped my problem solving skills, learnt about research, about life in general. I would be thankful to him for all my life, for providing me the guidance on various matters, always motivating and boosting me with confidence, which really helped me in shaping my life. I must also thank all my lab-mates who are working or have worked earlier in CSTAR - Vijayendra, Spandan, Satwik, Charu, Teja, Ishan and Lokesh. I really enjoyed working with them in the lab. I would like to thank all my friends in IIIT, for making my stay in the campus a memorable one.
    [Show full text]
  • Chapter 2: Operating-System Structures
    Chapter 2: Operating-System Structures Operating System Concepts – 10th Edition Silberschatz, Galvin and Gagne ©2018 Chapter 2: Operating-System Structures Operating System Services User and Operating System-Interface System Calls System Services Linkers and Loaders Why Applications are Operating System Specific Operating-System Design and Implementation Operating System Structure Building and Booting an Operating System Operating System Debugging Operating System Concepts – 10th Edition 2.2 Silberschatz, Galvin and Gagne ©2018 Objectives Identify services provided by an operating system Illustrate how system calls are used to provide operating system services Compare and contrast monolithic, layered, microkernel, modular, and hybrid strategies for designing operating systems Illustrate the process for booting an operating system Apply tools for monitoring operating system performance Design and implement kernel modules for interacting with a Linux kernel Operating System Concepts – 10th Edition 2.3 Silberschatz, Galvin and Gagne ©2018 Operating System Services Operating systems provide an environment for execution of programs and services to programs and users One set of operating-system services provides functions that are helpful to the user: User interface - Almost all operating systems have a user interface (UI). Varies between Command-Line (CLI), Graphics User Interface (GUI), touch-screen, Batch Program execution - The system must be able to load a program into memory and to run that program, end execution, either normally or abnormally (indicating error) I/O operations - A running program may require I/O, which may involve a file or an I/O device Operating System Concepts – 10th Edition 2.4 Silberschatz, Galvin and Gagne ©2018 Operating System Services (Cont.) One set of operating-system services provides functions that are helpful to the user (Cont.): File-system manipulation - The file system is of particular interest.
    [Show full text]
  • Comparing the Robustness of POSIX Operating Systems
    Comparing the Robustness of POSIX Operating Systems http://www.ices.cmu.edu/ballista Philip Koopman & John DeVale ECE Department [email protected] - (412) 268-5225 - http://www.ices.cmu.edu/koopman ,QVWLWXWH IRU &RPSOH[ (QJLQHHUHG 6\VWHPV Overview: Ballista Automated Robustness Testing ◆ Generic robustness testing • Based on data types ◆ OS Testing results • Raw results for 15 Operating Systems • System calls vs. C Library ◆ Exception Handling Diversity • Does everyone core dump on the same exceptions? (no) ◆ Approximating “Silent” failure rates (missing error codes) A Ballista is an ancient siege ◆ Conclusions/Future work weapon for hurling objects at fortified defenses. 2 Ballista: Software Testing + Fault Injection Ideas ◆ SW Testing requires: Ballista uses: • Test case “Bad” value combinations • Module under test Module under Test • Oracle (a “specification”) Watchdog timer/core dumps SPECIFIED INPUT RESPONSE BEHAVIOR SPACE SPACE ROBUST SHOULD VAL I D OPERATION WORK INPUTS MO DULE REPRODUCIBLE UNDEFINED UNDER FAILURE TEST SHOULD INVALID INPUTS UNREPRODUCIBLE RETURN FAILURE ERROR ◆ Ballista combines ideas from: • Domain testing ideas / Syntax testing ideas • Fault injection at the API level 3 Scalable Test Generation API write(int filedes, const void *buffer, size_t nbytes) FILE MEMORY SIZE TESTING DESCRIPTOR BUFFER TEST OBJECTS TEST OBJECT TEST OBJECT OBJECT FD_CLOSED BUF_SMALL_1 SIZE_1 FD_OPEN_READ BUF_MED_PAGESIZE SIZE_16 FD_OPEN_WRITE BUF_LARGE_512MB SIZE_PAGE FD_DELETED BUF_XLARGE_1GB SIZE_PAGEx16 FD_NOEXIST BUF_HUGE_2GB SIZE_PAGEx16plus1
    [Show full text]
  • Chapter 2 Operating System Structures
    Operating Systems Associate Prof. Yongkun Li 中科大-计算机学院 副教授 http://staff.ustc.edu.cn/~ykli Chapter 2 Operating System Structures 1 Objectives • Operating System Services – User Operating System Interface – System Calls • Operating System Structure • Operating System Design and Implementation • MISC: Debugging, Generation & System Boot 2 Operating System Services Services Overview, User Interface 3 Operating System Services • Operating systems provide – an environment for execution of programs and – services to programs and users • Services may differ from one OS to another • What are the common classes? – Convenience of the user – Efficiency of the system 4 Overview of Operating System Services 5 OS Services for Helping Users • User interface - Almost all operating systems have a user interface (UI). – Three forms • Command-Line (CLI) – Shell command • Batch – Shell script • Graphics User Interface (GUI) – Windows system 6 OS Services for Helping Users • Program execution – Load a program into memory – Run the program – End execution • either normally or • abnormally (indicating error) 7 OS Services for Helping Users • I/O operations - A running program may require I/O, which may involve a file or an I/O device – Common I/Os: read, write, etc. – Special functions: recording CD/DVD • Notes: Users usually cannot control I/O devices directly, so OS provides a mean to do I/O – Mainly for efficiency and protection 8 OS Services for Helping Users • File-system manipulation - The file system is of particular interest – OS provides a variety of file systems • Major services – read and write files and directories – create and delete files and directories – search for a given file – list file Information – permission management: allow/deny access 9 OS Services for Helping Users • Communications: information exchange between processes – Processes on the same computer – Processes between computers over a network • Implementations – Shared memory • Two or more processes read/write to a shared section of mem.
    [Show full text]