DOCSLIB.ORG

Practical Low-Overhead Enforcement of Memory Safety for C Programs

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Practical Low-Overhead Enforcement of Memory Safety for C Programs PRACTICAL LOW-OVERHEAD ENFORCEMENT OF MEMORY SAFETY FOR C PROGRAMS Santosh Ganapati Nagarakatte A DISSERTATION in Computer and Information Science Presented to the Faculties of the University of Pennsylvania in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy 2012 Milo M. K. Martin, Associate Professor of Computer and Information Science Supervisor of Dissertation Val Tannen, Professor of Computer and Information Science Graduate Group Chairperson Dissertation Committee Rajeev Alur, Professor of Computer and Information Science Andre´ DeHon, Professor of Electrical and System Engineering Steve Zdancewic, Associate Professor of Computer and Information Science Emery Berger, Associate Professor, University of Massachusetts Amherst PRACTICAL LOW-OVERHEAD ENFORCEMENT OF MEMORY SAFETY FOR C PROGRAMS COPYRIGHT 2012 Santosh Ganapati Nagarakatte This dissertation is dedicated to my parents. Without them, this would not have been possible. iii Acknowledgments This dissertation is a direct result of constant support and encouragement from my parents who had more confidence in my abilities than I had, at times, in my ability. Apart from my parents, there are numerous people who have been instrumental in the growth of my research career and my development as an individual. My adviser, Milo Martin has had a transformative influence on me as a researcher. I am fortunate to have worked with him for the last five years. Milo provided me the initial insights, the motivation to work on the problem, and eventually has nourished my ideas. He was generous with his time and wisdom. He provided me an excellent platform where I could excel. Apart from the research under him, he gave me freedom to collaborate with other researchers independently. I have also learned a great deal about teaching, presentations, and mentoring that will be amazingly useful in my future career. Among the other faculty members at Penn, Steve Zdancewic was like a second adviser to me. Collaborating with Steve kept my programming language interests active and thriving. Amir Roth convinced me to join Penn. I had a great time working with Amir for the first two years. I would like to thank other faculty members—Rajeev Alur, Benjamin Pierce, Boon Thau Loo, Andreas Haeberlen, and Sudipto Guha—for their great courses, advice, encouragement and discussions on various topics. I would like to thank my committee—Rajeev Alur, Steve Zdancewic, Andre DeHon, and Emery Berger—for carefully reading my dissertation, providing great feedback, useful advice and sugges- tions along the way. I would also like to thank Madanlal Musuvathi and Sebastian Burckhardt for mentoring during my internship at MSR and for the subsequent collaboration over the last few years. I would also like to thank my adviser at IISc, R. Govindarajan for encouraging me to pursue this path in my initial years. iv Jianzhou Zhao and Andrew Hilton have been two of my closest collaborators. I learned a great deal about computer architecture, programming, and a passion for teaching from Drew. Jianzhou has been my primary collaborator from my first day at Penn. We did course projects, research projects, and papers together. He inspired and amazed me with his devotion to work, work ethics, and the constant focus on the task at hand. Other members of the safety project—Jianzhou Zhao, Christian Delozier, Peter Michael Osera and Richard Eisenberg—have provided me help, encour- agement, and have spent time polishing and refining ideas together. I also thank the past and the present members of ACG group—Tingting Sha, Andrew Hilton, Colin Blundell, Vivek Rane, Arun Raghavan, Christian Delozier, Sela Mador Haim, Abhishek Udupa, James Anderson, and Laurel Emurian—for the interesting reading groups, numerous dis- cussions, and for attending my practice talks. I have had many amazing friends here, who made graduate school pleasant. Numerous dis- cussions with Arun Raghavan on a wide variety of topics—cricket, politics, books, research, and many others—was stimulating and fun. I also enjoyed spending time with other friends—Adam Aviv, Michael Greenberg, Marie Jacob, Changbin Liu, Annie Louis, Emily Pitler, Sudeepa Roy, and Wenchao Zhao. Thank you all. I want to thank the LLVM community for building a robust and a modular compiler, answering our questions, and for the entire ecosystem. I also thank Mike Felker, who single handedly managed numerous things for me and many others in the department. I also want to thank all other faculty members at Penn, other students at Penn, Moore business office, and the CIS departmental staff for the various activities at Penn. I also want to thank Penn recreation for the great squash courts and my numerous squash partners: Rick Titlebaum, Richard Burgos, John Hansen, Vivek Rane, Riju Ray, Shivjit Patil, Christina Castelino, and many others. I had a great time playing squash with you all. The dissertation research at Penn was also funded in part from grants by numerous fund- ing agencies1: National Science Foundation (NSF) grants CNS-0524059, CCF-0644197, CNS- 1116682, CCF-1065166, and CCF-0810947, Defense Advanced Research Projects Agency (DARPA) 1This research was funded in part by the U.S. Government. The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of the U.S. Government. v contracts HR0011-10-9-0008, Office of Naval Research (ONR) award N000141110596, and dona- tions from Intel Corporation. Finally, I would like to thank my family for all their sacrifices, motivation, and encouragement. I would like to thank my parents for providing me good education throughout my childhood. vi ABSTRACT PRACTICAL LOW-OVERHEAD ENFORCEMENT OF MEMORY SAFETY FOR C PROGRAMS Santosh Ganapati Nagarakatte Milo M. K. Martin The serious bugs and security vulnerabilities that result from C’s lack of bounds checking and unsafe manual memory management are well known, yet C remains in widespread use. Unfortunately, C’s arbitrary pointer arithmetic, conflation of pointers and arrays, and programmer-visible memory layout make retrofitting C with memory safety guarantees challenging. Existing approaches suffer from incompleteness, have high runtime overhead, or require non-trivial changes to the C source code. Thus far, these deficiencies have prevented widespread adoption of such techniques. This dissertation proposes mechanisms to provide comprehensive memory safety that works with mostly unmodified C code with a low performance overhead. We use a pointer-based ap- proach where we maintain metadata with pointers and check every pointer dereference. To enable compatibility with existing code, we maintain the metadata for the pointers in memory in a disjoint metadata space leaving the memory layout of the program intact. For detecting spatial violations, we maintain bounds metadata with every pointer. For detecting temporal violations, we maintain a unique identifier with each pointer. This pointer metadata is propagated with pointer operations and checked on pointer dereferences. Coupling disjoint metadata with a pointer-based approach enables comprehensive detection of all memory safety violations in unmodified C programs. This dissertation demonstrates the compatibility of this approach by hardening legacy C/C++ code with minimal source code changes. Further, this dissertation shows the effectiveness of the approach by detecting new memory safety errors and previously known memory safety errors in large code bases. To attain low performance overheads, this dissertation proposes efficient instantiations of this approach (1) within a compiler, (2) within hardware, and (3) with a hybrid hardware acceler- ated compiler instrumentation that reduces the overhead of enforcing memory safety, and thereby enabling their use in deployed systems. vii Contents 1 Introduction 1 1.1 Challenges with Existing Proposals . 4 1.2 Pointer-Based Checking with Disjoint Metadata . 5 1.3 Can Pointer-Based Checking be Performed within the Compiler? . 6 1.4 Can Pointer-Based Checking be Performed within the Hardware? . 7 1.5 Can Pointer-Based Checking be Performed with a Hardware/Compiler Hybrid? . 8 1.6 Contributions of this Dissertation . 9 1.7 Dissertation Structure . 10 1.8 Differences from Previously Published Versions of this Work . 11 2 Overview of Memory Safety Enforcement 12 2.1 The Problem of Memory Safety in C . 13 2.1.1 Spatial and Temporal Safety Violations . 13 2.1.2 Why are Memory Safety Violations Common with C? . 14 2.1.3 Consequences of Memory Safety Violations . 15 2.2 Enforcing Memory Safety . 16 2.2.1 Relationship Between Type Safety and Memory Safety . 16 2.2.2 Memory Safety with Safe Languages . 17 2.2.3 Design Alternatives in Enforcing Memory Safety for C . 17 2.2.4 Bug Finding vs Always-on Dynamic Checking Tools . 18 2.3 Detecting Spatial Safety Violations . 19 2.3.1 Tripwire Approaches . 19 2.3.2 Object-Based Approaches . 20 viii 2.3.3 Pointer-Based Approaches . 22 2.3.4 Source Incompatibility with Fat Pointers and Arbitrary Type Casts . 23 2.3.5 Comparison of Spatial Safety Approaches . 24 2.4 Detecting Temporal Safety Violations . 26 2.4.1 Garbage Collection in Safe Languages . 26 2.4.2 Garbage Collection in Type-Unsafe Languages like C . 27 2.4.3 Location-Based Temporal Checking . 28 2.4.4 Identifier-Based Temporal Checking . 29 2.4.5 Analysis of the Temporal Checking Design Space . 30 2.5 Program Instrumentation . 31 2.6 Summary . 32 3 Pointer-Based Checking with Disjoint Metadata 34 3.1 Approach Overview . 34 3.2 Metadata with Pointers . 35 3.3 Spatial Memory Safety Metadata and Checking . 36 3.4 Temporal Memory Safety Metadata and Checking . 37 3.4.1 Lock and Key Metadata . 37 3.4.2 Temporal Safety Checks . 40 3.5 Control Flow Integrity Checks . 40 3.6 Propagation on Pointer Arithmetic and Assignment . 41 3.7 Optional Narrowing of Pointer Bounds . 42 3.8 Disjoint Metadata . 43 3.8.1 Mapping Pointers to their Metadata .
Load more

Recommended publications
  • Safety Properties Liveness Properties
    Computer security Goal: prevent bad things from happening PLDI’06 Tutorial T1: Clients not paying for services Enforcing and Expressing Security Critical service unavailable with Programming Languages Confidential information leaked Important information damaged System used to violate laws (e.g., copyright) Andrew Myers Conventional security mechanisms aren’t Cornell University up to the challenge http://www.cs.cornell.edu/andru PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 2 Harder & more important Language-based security In the ’70s, computing systems were isolated. Conventional security: program is black box software updates done infrequently by an experienced Encryption administrator. Firewalls you trusted the (few) programs you ran. System calls/privileged mode physical access was required. Process-level privilege and permissions-based access control crashes and outages didn’t cost billions. The Internet has changed all of this. Prevents addressing important security issues: Downloaded and mobile code we depend upon the infrastructure for everyday services you have no idea what programs do. Buffer overruns and other safety problems software is constantly updated – sometimes without your knowledge Extensible systems or consent. Application-level security policies a hacker in the Philippines is as close as your neighbor. System-level security validation everything is executable (e.g., web pages, email). Languages and compilers to the rescue! PLDI Tutorial: Enforcing
    [Show full text]
  • An In-Depth Study with All Rust Cves
    Memory-Safety Challenge Considered Solved? An In-Depth Study with All Rust CVEs HUI XU, School of Computer Science, Fudan University ZHUANGBIN CHEN, Dept. of CSE, The Chinese University of Hong Kong MINGSHEN SUN, Baidu Security YANGFAN ZHOU, School of Computer Science, Fudan University MICHAEL R. LYU, Dept. of CSE, The Chinese University of Hong Kong Rust is an emerging programing language that aims at preventing memory-safety bugs without sacrificing much efficiency. The claimed property is very attractive to developers, and many projects start usingthe language. However, can Rust achieve the memory-safety promise? This paper studies the question by surveying 186 real-world bug reports collected from several origins which contain all existing Rust CVEs (common vulnerability and exposures) of memory-safety issues by 2020-12-31. We manually analyze each bug and extract their culprit patterns. Our analysis result shows that Rust can keep its promise that all memory-safety bugs require unsafe code, and many memory-safety bugs in our dataset are mild soundness issues that only leave a possibility to write memory-safety bugs without unsafe code. Furthermore, we summarize three typical categories of memory-safety bugs, including automatic memory reclaim, unsound function, and unsound generic or trait. While automatic memory claim bugs are related to the side effect of Rust newly-adopted ownership-based resource management scheme, unsound function reveals the essential challenge of Rust development for avoiding unsound code, and unsound generic or trait intensifies the risk of introducing unsoundness. Based on these findings, we propose two promising directions towards improving the security of Rust development, including several best practices of using specific APIs and methods to detect particular bugs involving unsafe code.
    [Show full text]
  • Project Snowflake: Non-Blocking Safe Manual Memory Management in .NET
    Project Snowflake: Non-blocking Safe Manual Memory Management in .NET Matthew Parkinson Dimitrios Vytiniotis Kapil Vaswani Manuel Costa Pantazis Deligiannis Microsoft Research Dylan McDermott Aaron Blankstein Jonathan Balkind University of Cambridge Princeton University July 26, 2017 Abstract Garbage collection greatly improves programmer productivity and ensures memory safety. Manual memory management on the other hand often delivers better performance but is typically unsafe and can lead to system crashes or security vulnerabilities. We propose integrating safe manual memory management with garbage collection in the .NET runtime to get the best of both worlds. In our design, programmers can choose between allocating objects in the garbage collected heap or the manual heap. All existing applications run unmodified, and without any performance degradation, using the garbage collected heap. Our programming model for manual memory management is flexible: although objects in the manual heap can have a single owning pointer, we allow deallocation at any program point and concurrent sharing of these objects amongst all the threads in the program. Experimental results from our .NET CoreCLR implementation on real-world applications show substantial performance gains especially in multithreaded scenarios: up to 3x savings in peak working sets and 2x improvements in runtime. 1 Introduction The importance of garbage collection (GC) in modern software cannot be overstated. GC greatly improves programmer productivity because it frees programmers from the burden of thinking about object lifetimes and freeing memory. Even more importantly, GC prevents temporal memory safety errors, i.e., uses of memory after it has been freed, which often lead to security breaches. Modern generational collectors, such as the .NET GC, deliver great throughput through a combination of fast thread-local bump allocation and cheap collection of young objects [63, 18, 61].
    [Show full text]
  • Ensuring the Spatial and Temporal Memory Safety of C at Runtime
    MemSafe: Ensuring the Spatial and Temporal Memory Safety of C at Runtime Matthew S. Simpson, Rajeev K. Barua Department of Electrical & Computer Engineering University of Maryland, College Park College Park, MD 20742-3256, USA fsimpsom, [email protected] Abstract—Memory access violations are a leading source of dereferencing pointers obtained from invalid pointer arith- unreliability in C programs. As evidence of this problem, a vari- metic; and dereferencing uninitialized, NULL or “manufac- ety of methods exist that retrofit C with software checks to detect tured” pointers.1 A temporal error is a violation caused by memory errors at runtime. However, these methods generally suffer from one or more drawbacks including the inability to using a pointer whose referent has been deallocated (e.g. with detect all errors, the use of incompatible metadata, the need for free) and is no longer a valid object. The most well-known manual code modifications, and high runtime overheads. temporal violations include dereferencing “dangling” point- In this paper, we present a compiler analysis and transforma- ers to dynamically allocated memory and freeing a pointer tion for ensuring the memory safety of C called MemSafe. Mem- more than once. Dereferencing pointers to automatically allo- Safe makes several novel contributions that improve upon previ- ous work and lower the cost of safety. These include (1) a method cated memory (stack variables) is also a concern if the address for modeling temporal errors as spatial errors, (2) a compati- of the referent “escapes” and is made available outside the ble metadata representation combining features of object- and function in which it was defined.
    [Show full text]
  • Cyclone: a Type-Safe Dialect of C∗
    Cyclone: A Type-Safe Dialect of C∗ Dan Grossman Michael Hicks Trevor Jim Greg Morrisett If any bug has achieved celebrity status, it is the • In C, an array of structs will be laid out contigu- buffer overflow. It made front-page news as early ously in memory, which is good for cache locality. as 1987, as the enabler of the Morris worm, the first In Java, the decision of how to lay out an array worm to spread through the Internet. In recent years, of objects is made by the compiler, and probably attacks exploiting buffer overflows have become more has indirections. frequent, and more virulent. This year, for exam- ple, the Witty worm was released to the wild less • C has data types that match hardware data than 48 hours after a buffer overflow vulnerability types and operations. Java abstracts from the was publicly announced; in 45 minutes, it infected hardware (“write once, run anywhere”). the entire world-wide population of 12,000 machines running the vulnerable programs. • C has manual memory management, whereas Notably, buffer overflows are a problem only for the Java has garbage collection. Garbage collec- C and C++ languages—Java and other “safe” lan- tion is safe and convenient, but places little con- guages have built-in protection against them. More- trol over performance in the hands of the pro- over, buffer overflows appear in C programs written grammer, and indeed encourages an allocation- by expert programmers who are security concious— intensive style. programs such as OpenSSH, Kerberos, and the com- In short, C programmers can see the costs of their mercial intrusion detection programs that were the programs simply by looking at them, and they can target of Witty.
    [Show full text]
  • Cs164: Introduction to Programming Languages and Compilers
    Lecture 19 Flow Analysis flow analysis in prolog; applications of flow analysis Ras Bodik Hack Your Language! CS164: Introduction to Programming Ali and Mangpo Languages and Compilers, Spring 2013 UC Berkeley 1 Today Static program analysis what it computes and how are its results used Points-to analysis analysis for understanding flow of pointer values Andersen’s algorithm approximation of programs: how and why Andersen’s algorithm in Prolog points-to analysis expressed via just four deduction rules Andersen’s algorithm via CYK parsing (optional) expressed as CYK parsing of a graph representing the pgm Static Analysis of Programs definition and motivation 3 Static program analysis Computes program properties used by a range of clients: compiler optimizers, static debuggers, security audit tools, IDEs, … Static analysis == at compile time – that is, prior to seeing the actual input ==> analysis answer must be correct for all possible inputs Sample program properties: does variable x has a constant value (for all inputs)? does foo() return a table (whenever called, on all inputs)? 4 Client 1: Program Optimization Optimize program by finding constant subexpressions Ex: replace x[i] with x[1] if we know that i is always 1. This optimizations saves the address computation. This analysis is called constant propagation i = 2 … i = i+2 … if (…) { …} … x[i] = x[i-1] 5 Client 2: Find security vulnerabilities One specific analysis: find broken sanitization In a web server program, as whether a value can flow from POST (untrusted source) to the SQL interpreter (trusted sink) without passing through the cgi.escape() sanitizer? This is taint analysis.
    [Show full text]
  • Memory Tagging and How It Improves C/C++ Memory Safety Kostya Serebryany, Evgenii Stepanov, Aleksey Shlyapnikov, Vlad Tsyrklevich, Dmitry Vyukov Google February 2018
    Memory Tagging and how it improves C/C++ memory safety Kostya Serebryany, Evgenii Stepanov, Aleksey Shlyapnikov, Vlad Tsyrklevich, Dmitry Vyukov Google February 2018 Introduction 2 Memory Safety in C/C++ 2 AddressSanitizer 2 Memory Tagging 3 SPARC ADI 4 AArch64 HWASAN 4 Compiler And Run-time Support 5 Overhead 5 RAM 5 CPU 6 Code Size 8 Usage Modes 8 Testing 9 Always-on Bug Detection In Production 9 Sampling In Production 10 Security Hardening 11 Strengths 11 Weaknesses 12 Legacy Code 12 Kernel 12 Uninitialized Memory 13 Possible Improvements 13 Precision Of Buffer Overflow Detection 13 Probability Of Bug Detection 14 Conclusion 14 Introduction Memory safety in C and C++ remains largely unresolved. A technique usually called “memory tagging” may dramatically improve the situation if implemented in hardware with reasonable overhead. This paper describes two existing implementations of memory tagging: one is the full hardware implementation in SPARC; the other is a partially hardware-assisted compiler-based tool for AArch64. We describe the basic idea, evaluate the two implementations, and explain how they improve memory safety. This paper is intended to initiate a wider discussion of memory tagging and to motivate the CPU and OS vendors to add support for it in the near future. Memory Safety in C/C++ C and C++ are well known for their performance and flexibility, but perhaps even more for their extreme memory unsafety. This year we are celebrating the 30th anniversary of the Morris Worm, one of the first known exploitations of a memory safety bug, and the problem is still not solved.
    [Show full text]
  • Memory Management with Explicit Regions by David Edward Gay
    Memory Management with Explicit Regions by David Edward Gay Engineering Diploma (Ecole Polytechnique F´ed´erale de Lausanne, Switzerland) 1992 M.S. (University of California, Berkeley) 1997 A dissertation submitted in partial satisfaction of the requirements for the degree of Doctor of Philosophy in Computer Science in the GRADUATE DIVISION of the UNIVERSITY of CALIFORNIA at BERKELEY Committee in charge: Professor Alex Aiken, Chair Professor Susan L. Graham Professor Gregory L. Fenves Fall 2001 The dissertation of David Edward Gay is approved: Chair Date Date Date University of California at Berkeley Fall 2001 Memory Management with Explicit Regions Copyright 2001 by David Edward Gay 1 Abstract Memory Management with Explicit Regions by David Edward Gay Doctor of Philosophy in Computer Science University of California at Berkeley Professor Alex Aiken, Chair Region-based memory management systems structure memory by grouping objects in regions under program control. Memory is reclaimed by deleting regions, freeing all objects stored therein. Our compiler for C with regions, RC, prevents unsafe region deletions by keeping a count of references to each region. RC's regions have advantages over explicit allocation and deallocation (safety) and traditional garbage collection (better control over memory), and its performance is competitive with both|from 6% slower to 55% faster on a collection of realistic benchmarks. Experience with these benchmarks suggests that modifying many existing programs to use regions is not difficult. An important innovation in RC is the use of type annotations that make the structure of a program's regions more explicit. These annotations also help reduce the overhead of reference counting from a maximum of 25% to a maximum of 12.6% on our benchmarks.
    [Show full text]
  • An Operational Semantics and Type Safety Proof for Multiple Inheritance in C++
    An Operational Semantics and Type Safety Proof for Multiple Inheritance in C++ Daniel Wasserrab Tobias Nipkow Gregor Snelting Frank Tip Universitat¨ Passau Technische Universitat¨ Universitat¨ Passau IBM T.J. Watson Research [email protected] Munchen¨ [email protected] Center passau.de [email protected] passau.de [email protected] Abstract pected type, or end with an exception. The semantics and proof are formalized and machine-checked using the Isabelle/HOL theorem We present an operational semantics and type safety proof for 1 multiple inheritance in C++. The semantics models the behaviour prover [15] and are available online . of method calls, field accesses, and two forms of casts in C++ class One of the main sources of complexity in C++ is a complex hierarchies exactly, and the type safety proof was formalized and form of multiple inheritance, in which a combination of shared machine-checked in Isabelle/HOL. Our semantics enables one, for (“virtual”) and repeated (“nonvirtual”) inheritance is permitted. Be- the first time, to understand the behaviour of operations on C++ cause of this complexity, the behaviour of operations on C++ class class hierarchies without referring to implementation-level artifacts hierarchies has traditionally been defined informally [29], and in such as virtual function tables. Moreover, it can—as the semantics terms of implementation-level constructs such as v-tables. We are is executable—act as a reference for compilers, and it can form only aware of a few formal treatments—and of no operational the basis for more advanced correctness proofs of, e.g., automated semantics—for C++-like languages with shared and repeated mul- program transformations.
    [Show full text]
  • Chapter 8 Automation Using Powershell
    Chapter 8 Automation Using PowerShell Virtual Machine Manager is one of the first Microsoft software products to fully adopt Windows PowerShell and offer its users a complete management interface tailored for script- ing. From the first release of VMM 2007, the Virtual Machine Manager Administrator Console was written on top of Windows PowerShell, utilizing the many cmdlets that VMM offers. This approach made VMM very extensible and partner friendly and allows customers to accomplish anything that VMM offers in the Administrator Console via scripts and automation. Windows PowerShell is also the only public application programming interface (API) that VMM offers, giving both developers and administrators a single point of reference for managing VMM. Writing scripts that interface with VMM, Hyper-V, or Virtual Server can be made very easy using Windows PowerShell’s support for WMI, .NET, and COM. In this chapter, you will learn to: ◆ Describe the main benefits that PowerShell offers for VMM ◆ Use the VMM PowerShell cmdlets ◆ Create scheduled PowerShell scripts VMM and Windows PowerShell System Center Virtual Machine Manager (VMM) 2007, the first release of VMM, was one of the first products to develop its entire graphical user interface (the VMM Administrator Con- sole) on top of Windows PowerShell (previously known as Monad). This approach proved very advantageous for customers that wanted all of the VMM functionality to be available through some form of an API. The VMM team made early bets on Windows PowerShell as its public management interface, and they have not been disappointed with the results. With its consis- tent grammar, the great integration with .NET, and the abundance of cmdlets, PowerShell is quickly becoming the management interface of choice for enterprise applications.
    [Show full text]
  • Mastering Powershellpowershell
    CopyrightCopyright © 2009 BBS Technologies ALL RIGHTS RESERVED. No part of this work covered by the copyright herein may be reproduced, transmitted, stored, or used in any form or by any means graphic, electronic, or mechanical, including but not limited to photocopying, recording, scanning, digitizing, taping, Web distribution, information networks, or information storage and retrieval systems except as permitted under Section 107 or 108 of the 1976 United States Copyright Act without the prior written permission of the publisher. For permission to use material from the text please contact Idera at [email protected]. Microsoft® Windows PowerShell® and Microsoft® SQL Server® are registered trademarks of Microsoft Corporation in the United Stated and other countries. All other trademarks are the property of their respective owners. AboutAbout thethe AuthorAuthor Dr. Tobias Weltner is one of the most visible PowerShell MVPs in Europe. He has published more than 80 books on Windows and Scripting Techniques with Microsoft Press and other publishers, is a regular speaker at conferences and road shows and does high level PowerShell and Scripting trainings for companies throughout Europe. He created the powershell.com website and community in an effort to help people adopt and use PowerShell more efficiently. As software architect, he created a number of award-winning scripting tools such as SystemScripter (VBScript), the original PowerShell IDE and PowerShell Plus, a comprehensive integrated PowerShell development system. AcknowledgmentsAcknowledgments First and foremost, I’d like to thank my family who is always a source of inspiration and encouragement. A special thanks to Idera, Rick Pleczko, David Fargo, Richard Giles, Conley Smith and David Twamley for helping to bring this book to the English speaking world.
    [Show full text]
  • An Evolutionary Study of Linux Memory Management for Fun and Profit Jian Huang, Moinuddin K
    An Evolutionary Study of Linux Memory Management for Fun and Profit Jian Huang, Moinuddin K. Qureshi, and Karsten Schwan, Georgia Institute of Technology https://www.usenix.org/conference/atc16/technical-sessions/presentation/huang This paper is included in the Proceedings of the 2016 USENIX Annual Technical Conference (USENIX ATC ’16). June 22–24, 2016 • Denver, CO, USA 978-1-931971-30-0 Open access to the Proceedings of the 2016 USENIX Annual Technical Conference (USENIX ATC ’16) is sponsored by USENIX. An Evolutionary Study of inu emory anagement for Fun and rofit Jian Huang, Moinuddin K. ureshi, Karsten Schwan Georgia Institute of Technology Astract the patches committed over the last five years from 2009 to 2015. The study covers 4587 patches across Linux We present a comprehensive and uantitative study on versions from 2.6.32.1 to 4.0-rc4. We manually label the development of the Linux memory manager. The each patch after carefully checking the patch, its descrip- study examines 4587 committed patches over the last tions, and follow-up discussions posted by developers. five years (2009-2015) since Linux version 2.6.32. In- To further understand patch distribution over memory se- sights derived from this study concern the development mantics, we build a tool called MChecker to identify the process of the virtual memory system, including its patch changes to the key functions in mm. MChecker matches distribution and patterns, and techniues for memory op- the patches with the source code to track the hot func- timizations and semantics. Specifically, we find that tions that have been updated intensively.
    [Show full text]