DOCSLIB.ORG

Empirical Performance Comparison of Hardware and Software Task Context Switching

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Empirical Performance Comparison of Hardware and Software Task Context Switching View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Calhoun, Institutional Archive of the Naval Postgraduate School Calhoun: The NPS Institutional Archive Theses and Dissertations Thesis Collection 2009-06 Empirical Performance Comparison of Hardware and Software Task Context Switching Schultz, Eric A. Monterey, California. Naval Postgraduate School http://hdl.handle.net/10945/46226 NAVAL POSTGRADUATE SCHOOL MONTEREY, CALIFORNIA THESIS EMPIRICAL PERFORMANCE COMPARISON OF HARDWARE AND SOFTWARE TASK CONTEXT SWITCHING by Eric A. Schultz June 2009 Thesis Advisor: Cynthia E. Irvine Second Reader: David J. Shifflett Approved for public release; distribution is unlimited THIS PAGE INTENTIONALLY LEFT BLANK ii Form Approved REPORT DOCUMENTATION PAGE OMB No. 0704–0188 The public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and Reports (0704–0188), 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202–4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to any penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number. PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS. 1. REPORT DATE (DD–MM–YYYY) 2. REPORT TYPE 3. DATES COVERED (From — To) 15–6–2009 Master’s Thesis 01-01-2009–06-19-2009 4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER 5b. GRANT NUMBER Empirical Performance Comparison of Hardware and Software Task Context Switching 5c. PROGRAM ELEMENT NUMBER 6. AUTHOR(S) 5d. PROJECT NUMBER 5e. TASK NUMBER Eric A. Schultz 5f. WORK UNIT NUMBER 7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION REPORT NUMBER Naval Postgraduate School Monterey, CA 93943 9. SPONSORING / MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S) Department of the Navy 11. SPONSOR/MONITOR’S REPORT NUMBER(S) 12. DISTRIBUTION / AVAILABILITY STATEMENT Approved for public release; distribution is unlimited 13. SUPPLEMENTARY NOTES 14. ABSTRACT There are many divergent opinions regarding possible differences between the performance of hardware and software context switching implementations. However, there are no concrete empirical measures of their true differences. Using an empirical testing methodology, this research performed seven experiments, collecting quantitative performance results on hardware and software-based context switch implementations with two and four hardware privilege level support. The implementations measured are the hardware-based Intel IA-32 context switch, the software-based MINIX 3 context switch, a software-based simulation of a MINIX 3 context switch with four hardware privileged level support, and a software-based simulation of an Intel IA-32 hardware context switch. Experiments were executed using the Trusted Computing Exemplar Least Privilege Separation Kernel and the Linux 2.6 Kernel. The results include the number of cycles and time required to complete processing of each implementation. This study concludes that the hardware-based context switching mechanism is significantly slower than software implementation, even those that simulate the elaborate checks of the hardware implementation. A possible reason for this is posited. 15. SUBJECT TERMS Performance, Context Switch, Task Switch, TCX, LPSK, Intel, IA-32, MINIX 3 16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF 18. NUMBER19a. NAME OF RESPONSIBLE PERSON a. REPORT b. ABSTRACTc.THIS PAGE ABSTRACT OF PAGES 19b. TELEPHONE NUMBER (include area code) Unclassified Unclassified Unclassified UU 176 Standard Form 298 (Rev. 8–98) i Prescribed by ANSI Std. Z39.18 THIS PAGE INTENTIONALLY LEFT BLANK ii Approved for public release; distribution is unlimited EMPIRICAL PERFORMANCE COMPARISON OF HARDWARE AND SOFTWARE TASK CONTEXT SWITCHING Eric A. Schultz Civilian, Naval Postgraduate School B.S., Rocky Mountain College, 2007 Submitted in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE IN COMPUTER SCIENCE from the NAVAL POSTGRADUATE SCHOOL June 2009 Author: Eric A. Schultz Approved by: Cynthia E. Irvine Thesis Advisor David J. Shifflett Second Reader Peter J. Denning Chair, Department of Computer Science iii THIS PAGE INTENTIONALLY LEFT BLANK iv ABSTRACT There are many divergent opinions regarding possible differences between the performance of hardware and software context switching implementations. However, there are no concrete empirical measures of their true differences. Using an empirical testing methodology, this re- search performed seven experiments, collecting quantitative performance results on hardware and software-based context switch implementations with two and four hardware privilege level support. The implementations measured are the hardware-based Intel IA-32 context switch, the software-based MINIX 3 context switch, a software-based simulation of a MINIX 3 con- text switch with four hardware privileged level support, and a software-based simulation of an Intel IA-32 hardware context switch. Experiments were executed using the Trusted Comput- ing Exemplar Least Privilege Separation Kernel and the Linux 2.6 Kernel. The results include the number of cycles and time required to complete processing of each implementation. This study concludes that the hardware-based context switching mechanism is significantly slower than software implementation, even those that simulate the elaborate checks of the hardware implementation. A possible reason for this is posited. v THIS PAGE INTENTIONALLY LEFT BLANK vi Contents 1 Introduction1 1.1 Motivation.............................1 1.2 Purpose of Study..........................2 1.3 Organization of Thesis........................3 2 Background5 2.1 Multitasking Operating Systems Overview................5 2.2 Context Switches.......................... 12 2.3 Summary............................. 14 3 Methodologies and Testing Techniques 15 3.1 Operating Systems Selection...................... 16 3.2 Hardware Selection......................... 20 3.3 Context Switching Constructs..................... 21 3.4 Testing Strategies.......................... 31 3.5 Summary............................. 50 4 Results and Analysis 53 4.1 Measurements of RDTSC, CPUID and Cache Warming........... 53 4.2 Minimal Software Context Switch Results................ 54 4.3 MINIX 3 Software Context Switch Results................ 54 4.4 Intel IA-32 Hardware Context Switch Results............... 55 4.5 Modified Four Hardware Privilege Level Supported MINIX 3 Software Context Switch Results................ 55 4.6 Linux Software Simulation of Intel IA-32 Hardware Context Switch Results... 56 4.7 TCX LPSK Software Simulation of Intel IA-32 Hardware Context Switch Results 56 4.8 Single Execution of Intel IA-32 Hardware Context Switch Results....... 57 4.9 Final Analysis and Conclusions.................... 58 4.10 Summary............................. 62 5 Discussion and Conclusions 63 5.1 Future Work............................ 63 5.2 Related Work............................ 64 5.3 Summary and Conclusions...................... 66 vii Contents Contents List of References 69 Appendix A MINIX 3 Software Context Switch Source 73 A.1 Save Procedure........................... 73 A.2 Restart Procedure.......................... 74 Appendix B Experiments Source Code 75 B.1 RDTSC Measurement Source..................... 75 B.2 CPUID Measurement Source..................... 77 B.3 TCX LPSK Assembler Functions task switch asm and task switch dummy ......................... 78 B.4 Experiment One Source–Minimal Context Switch Cost........... 80 B.5 Experiment Two Source–MINIX 3 Software Context Switch......... 86 B.6 Experiment Three Source–Intel IA-32 Hardware Context Switch....... 95 B.7 Experiment Four Source–Modified MINIX 3 Four Hardware Privilege Level Sup- ported Software Context Switch.................... 103 B.8 Experiment Five Source–Linux Software Simulation of Intel IA-32 Hardware Con- text Switch............................. 112 B.9 Experiment Six Source–TCX LPSK Software Simulation of Intel IA-32 Hardware Context Switch........................... 122 B.10 Experiment Seven Source–Single Intel IA-32 Hardware Context Switch.... 131 Appendix C Experiment Data 139 C.1 RDTSC Instruction CPI Results.................... 139 C.2 CPUID Instruction CPI Results..................... 141 C.3 Experiment One Results–Minimal Context Switch Cost........... 142 C.4 Experiment Two Results–MINIX 3 Software Context Switch......... 143 C.5 Experiment Three Results–Intel IA-32 Hardware Context Switch....... 144 C.6 Experiment Four Results–Modified MINIX 3 Four Hardware Privilege Level Sup- ported Software Context Switch.................... 147 C.7 Experiment Five Results–Linux Software Simulation of Intel IA-32 Hardware Con- text Switch............................. 148 C.8 Experiment Six Results–TCX LPSK Software Simulation of Intel IA-32 Hardware Context Switch........................... 149 C.9 Experiment Seven Results–Single Intel IA-32 Hardware Context Switch.... 150 Referenced Authors 153 viii Contents
Load more

Recommended publications
  • Validated Products List, 1995 No. 3: Programming Languages, Database
    NISTIR 5693 (Supersedes NISTIR 5629) VALIDATED PRODUCTS LIST Volume 1 1995 No. 3 Programming Languages Database Language SQL Graphics POSIX Computer Security Judy B. Kailey Product Data - IGES Editor U.S. DEPARTMENT OF COMMERCE Technology Administration National Institute of Standards and Technology Computer Systems Laboratory Software Standards Validation Group Gaithersburg, MD 20899 July 1995 QC 100 NIST .056 NO. 5693 1995 NISTIR 5693 (Supersedes NISTIR 5629) VALIDATED PRODUCTS LIST Volume 1 1995 No. 3 Programming Languages Database Language SQL Graphics POSIX Computer Security Judy B. Kailey Product Data - IGES Editor U.S. DEPARTMENT OF COMMERCE Technology Administration National Institute of Standards and Technology Computer Systems Laboratory Software Standards Validation Group Gaithersburg, MD 20899 July 1995 (Supersedes April 1995 issue) U.S. DEPARTMENT OF COMMERCE Ronald H. Brown, Secretary TECHNOLOGY ADMINISTRATION Mary L. Good, Under Secretary for Technology NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY Arati Prabhakar, Director FOREWORD The Validated Products List (VPL) identifies information technology products that have been tested for conformance to Federal Information Processing Standards (FIPS) in accordance with Computer Systems Laboratory (CSL) conformance testing procedures, and have a current validation certificate or registered test report. The VPL also contains information about the organizations, test methods and procedures that support the validation programs for the FIPS identified in this document. The VPL includes computer language processors for programming languages COBOL, Fortran, Ada, Pascal, C, M[UMPS], and database language SQL; computer graphic implementations for GKS, COM, PHIGS, and Raster Graphics; operating system implementations for POSIX; Open Systems Interconnection implementations; and computer security implementations for DES, MAC and Key Management.
    [Show full text]
  • Formal Modelling of Separation Kernels
    The University of York Department of Computer Science Submitted in part fulfilment for the degree of MSc in Software Engineering. Formal Modelling of Separation Kernels Andrius Velykis 18th September 20091 Supervised by Dr Leo Freitas Number of words = 45327, as counted by detex <report.tex> j wc -w. This report consists of 98 pages in total. This includes the body of the report (without blank pages) and Appendix A, but not Appendices B, C, D, E and F. 1Updated transactional operation proofs, 21st September 2009. Abstract A separation kernel is an architecture for secure applications, which benefits from inherent security of distributed systems. Due to its small size and usage in high-integrity environments, it makes a good target for formal modelling and verification. This project presents results from mechanisation and modelling of separation kernel components: a process table, a process queue and a scheduler. The results have been developed as a part of the pilot project within the international Grand Challenge in Verified Software. This thesis covers full development life-cycle from project initiation through design and evaluation to successful completion. Important findings about kernel properties, formal modelling and design decisions are discussed. The developed formal specification is fully verified and contributes to the pilot project aim of creating a formal kernel model and refining it down to implementation code. Other reusable artefacts, such as general lemmas and a new technique of ensuring transactional properties of operations are defined. The results will be curated within the Verified Software Repository. i Robertai. Aˇci¯u. Acknowledgements I would like to thank Dr Leo Freitas for his supervision, encouragement and getting me hooked on formal methods.
    [Show full text]
  • RTI Data Distribution Service Platform Notes
    RTI Data Distribution Service The Real-Time Publish-Subscribe Middleware Platform Notes Version 4.5c © 2004-2010 Real-Time Innovations, Inc. All rights reserved. Printed in U.S.A. First printing. June 2010. Trademarks Real-Time Innovations and RTI are registered trademarks of Real-Time Innovations, Inc. All other trademarks used in this document are the property of their respective owners. Copy and Use Restrictions No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form (including electronic, mechanical, photocopy, and facsimile) without the prior written permission of Real- Time Innovations, Inc. The software described in this document is furnished under and subject to the RTI software license agreement. The software may be used or copied only under the terms of the license agreement. Technical Support Real-Time Innovations, Inc. 385 Moffett Park Drive Sunnyvale, CA 94089 Phone: (408) 990-7444 Email: [email protected] Website: http://www.rti.com/support Contents 1 Supported Platforms.........................................................................................................................1 2 AIX Platforms.....................................................................................................................................3 2.1 Changing Thread Priority.......................................................................................................3 2.2 Multicast Support ....................................................................................................................3
    [Show full text]
  • Research Purpose Operating Systems – a Wide Survey
    GESJ: Computer Science and Telecommunications 2010|No.3(26) ISSN 1512-1232 RESEARCH PURPOSE OPERATING SYSTEMS – A WIDE SURVEY Pinaki Chakraborty School of Computer and Systems Sciences, Jawaharlal Nehru University, New Delhi – 110067, India. E-mail: [email protected] Abstract Operating systems constitute a class of vital software. A plethora of operating systems, of different types and developed by different manufacturers over the years, are available now. This paper concentrates on research purpose operating systems because many of them have high technological significance and they have been vividly documented in the research literature. Thirty-four academic and research purpose operating systems have been briefly reviewed in this paper. It was observed that the microkernel based architecture is being used widely to design research purpose operating systems. It was also noticed that object oriented operating systems are emerging as a promising option. Hence, the paper concludes by suggesting a study of the scope of microkernel based object oriented operating systems. Keywords: Operating system, research purpose operating system, object oriented operating system, microkernel 1. Introduction An operating system is a software that manages all the resources of a computer, both hardware and software, and provides an environment in which a user can execute programs in a convenient and efficient manner [1]. However, the principles and concepts used in the operating systems were not standardized in a day. In fact, operating systems have been evolving through the years [2]. There were no operating systems in the early computers. In those systems, every program required full hardware specification to execute correctly and perform each trivial task, and its own drivers for peripheral devices like card readers and line printers.
    [Show full text]
  • Vxworks OS Changer Gives Developers the Ability to Reuse Vxworks Applications on Diff Erent Operating Systems
    VxWorks® OS Changer Change Your OS - Keep Your Code The OS Changer family of products gives developers the freedom to switch operating systems while leveraging on their existing code and knowledge base to protect their software investment. VxWorks OS Changer gives developers the ability to reuse VxWorks applications on diff erent operating systems. VxWorks OS Changer Highlights Protect your software investment by re-using your VxWorks code Reduce time to market by migrating VxWorks code to a standard OS interface architecture Protect your knowledge-base by using familiar APIs and eliminate the learning curve on the new OS platform Eliminate dependency on a single OS vendor and switch to - An OS that meets your performance and memory footprint needs - An OS that off ers better tools, middleware/drivers and support - An OS that supports your next generation silicon Reduce ongoing development and maintenance cost - Develop target specifi c code on a host platform - Re-use one set of code across multiple host & target OS platforms - Break down VxWorks applications into manageable pieces to reduce complexity and add module protection - Use same APIs for inter-task and inter-process communications OS Changer is highly optimized for each specifi c OS platform Eclipse-based host environment is available to port VxWorks applications using OS Changer in OS PAL (refer to the OS PAL datasheet) OS Changer includes access to the BASE OS Abstractor API features to allow development of highly portable applications (refer to the OS Abstractor datasheet) Additionally, POSIX or open source Linux code can be reused on a new OS platform with POSIX OS Abstractor (refer to the POSIX OS Abstractor datasheet) VxWorks OS Changer is off ered royalty-free with source code Using VxWorks OS Changer OS Changer is designed for use as a C library.
    [Show full text]
  • MILS Architectural Approach Supporting Trustworthiness of the Iiot Solutions
    MILS Architectural Approach Supporting Trustworthiness of the IIoT Solutions An Industrial Internet Consortium Whitepaper Rance J. DeLong (The Open Group); Ekaterina Rudina (Kaspersky) MILS Architectural Approach Context and Overview 1 Context and Overview ...................................................................................................... 4 1.1 Need for Trustworthy System Operation ............................................................................. 5 1.2 What is MILS today .............................................................................................................. 6 1.3 How MILS Addresses Safety ................................................................................................. 7 1.4 How MILS Addresses Security .............................................................................................. 8 1.5 How MILS Supports Reliability, Resilience, and Privacy ........................................................ 9 2 MILS Concepts .................................................................................................................. 9 2.1 Centralized vs Distributed Security Architecture .................................................................. 9 2.1.1 Domain Isolation .................................................................................................................................. 10 2.1.2 Isolation and Information Flow Control ............................................................................................... 11 2.1.3 Separation
    [Show full text]
  • Virtual Memory in X86
    Fall 2017 :: CSE 306 Virtual Memory in x86 Nima Honarmand Fall 2017 :: CSE 306 x86 Processor Modes • Real mode – walks and talks like a really old x86 chip • State at boot • 20-bit address space, direct physical memory access • 1 MB of usable memory • No paging • No user mode; processor has only one protection level • Protected mode – Standard 32-bit x86 mode • Combination of segmentation and paging • Privilege levels (separate user and kernel) • 32-bit virtual address • 32-bit physical address • 36-bit if Physical Address Extension (PAE) feature enabled Fall 2017 :: CSE 306 x86 Processor Modes • Long mode – 64-bit mode (aka amd64, x86_64, etc.) • Very similar to 32-bit mode (protected mode), but bigger address space • 48-bit virtual address space • 52-bit physical address space • Restricted segmentation use • Even more obscure modes we won’t discuss today xv6 uses protected mode w/o PAE (i.e., 32-bit virtual and physical addresses) Fall 2017 :: CSE 306 Virt. & Phys. Addr. Spaces in x86 Processor • Both RAM hand hardware devices (disk, Core NIC, etc.) connected to system bus • Mapped to different parts of the physical Virtual Addr address space by the BIOS MMU Data • You can talk to a device by performing Physical Addr read/write operations on its physical addresses Cache • Devices are free to interpret reads/writes in any way they want (driver knows) System Interconnect (Bus) : all addrs virtual DRAM Network … Disk (Memory) Card : all addrs physical Fall 2017 :: CSE 306 Virt-to-Phys Translation in x86 0xdeadbeef Segmentation 0x0eadbeef Paging 0x6eadbeef Virtual Address Linear Address Physical Address Protected/Long mode only • Segmentation cannot be disabled! • But can be made a no-op (a.k.a.
    [Show full text]
  • Altaapi Software User's Manual
    AltaAPI™ Software User’s Manual Part Number: 14301-00000-I4 Cage Code: 4RK27 ● NAICS: 334118 Alta Data Technologies LLC 4901 Rockaway Blvd, Building A Rio Rancho, NM 87124 USA (tel) 505-994-3111 ● www.altadt.com i AltaAPI™ Software User’s Manual ● 14301-00000-I4 Alta Data Technologies LLC ● www.altadt.com CUSTOMER NOTES: Document Information: Alta Software Version: 2.6.5.0 Rev I4 Release Date: November 10, 2014 Note to the Reader and End-User: This document is provided for information only and is copyright by © Alta Data Technologies LLC. While Alta strives to provide the most accurate information, there may be errors and omissions in this document. Alta disclaims all liability in document errors and any product usage. By using an Alta product, the customer or end user agrees (1) to accept Alta’s Standard Terms and Conditions of Sale, Standard Warranty and Software License and (2) to not hold Alta Members, Employees, Contractors or Sales & Support Representatives responsible for any loss or legal liability, tangible or intangible, from any document errors or any product usage. The product described in this document is not US ITAR controlled. Use of Alta products or documentation in violation of local usage, waste discard and export control rules, or in violation of US ITAR regulations, voids product warranty and shall not be supported. This document may be distributed to support government programs and projects. Third party person, company or consultant distribution is not allowed without Alta’s written permission. AltaCore, AltaCore-1553, AltaCore-ARINC, AltaAPI, AltaAPI-LV, AltaView, AltaRTVal, ENET- 1553, ENET-A429 & ENET-1553-EBR are Trademarks of Alta Data Technologies LLC, Rio Rancho, New Mexico USA Contact: We welcome comments and suggestions.
    [Show full text]
  • Introduction to Bioinformatics Introduction to Bioinformatics
    Introduction to Bioinformatics Introduction to Bioinformatics Prof. Dr. Nizamettin AYDIN [email protected] Introduction to Perl http://www3.yildiz.edu.tr/~naydin 1 2 Learning objectives Setting The Technological Scene • After this lecture you should be able to • One of the objectives of this course is.. – to enable students to acquire an understanding of, and understand : ability in, a programming language (Perl, Python) as the – sequence, iteration and selection; main enabler in the development of computer programs in the area of Bioinformatics. – basic building blocks of programming; – three C’s: constants, comments and conditions; • Modern computers are organised around two main – use of variable containers; components: – use of some Perl operators and its pattern-matching technology; – Hardware – Perl input/output – Software – … 3 4 Introduction to the Computing Introduction to the Computing • Computer: electronic genius? • In theory, computer can compute anything – NO! Electronic idiot! • that’s possible to compute – Does exactly what we tell it to, nothing more. – given enough memory and time • All computers, given enough time and memory, • In practice, solving problems involves are capable of computing exactly the same things. computing under constraints. Supercomputer – time Workstation • weather forecast, next frame of animation, ... PDA – cost • cell phone, automotive engine controller, ... = = – power • cell phone, handheld video game, ... 5 6 Copyright 2000 N. AYDIN. All rights reserved. 1 Layers of Technology Layers of Technology • Operating system... – Interacts directly with the hardware – Responsible for ensuring efficient use of hardware resources • Tools... – Softwares that take adavantage of what the operating system has to offer. – Programming languages, databases, editors, interface builders... • Applications... – Most useful category of software – Web browsers, email clients, web servers, word processors, etc..
    [Show full text]
  • Programming Fundamentals - I Basic Concepts Fall-Semester 2016
    Programming Fundamentals - I Basic Concepts Fall-Semester 2016 Prepared By: Rao Muhammad Umer Lecturer, Web: raoumer.github.io Department of Computer Science & IT, The University of Lahore. What is computer? The term "computer" was originally given to humans who performed numerical calculations using mechanical calculators, such as the abacus and slide rule. The term was later given to a mechanical device as they began replacing the human computers. Today's computers are electronic devices that accept data such as numbers, text, sound, image, animations, video, etc., (input), process that data (converts data to information) , produce output, and then store (storage) the results. A basic computer consists of 4 components: 1. Input devices 2. Central Processing Unit or CPU 3. Output devices 4. Memory Input Devices are used to provide input to the computer basic input devices include keyboard, mouse, touch screens etc. Central Processing Unit acts like a brain, it processes all instructions and data in the computer, the instructions are computer commands, these commands are given to CPU by input devices, some of the instructions are generated by the computer itself Output devices are used to receive computer output, the output, some basic output devices are hard drive disk (HDD, commonly known as hard disk), printers, computer screens (Monitors and LCDs) The computer memory is a temporary storage area. It holds the data and instructions that the Central Processing Unit (CPU) needs. Before a program can be run, the program is loaded from some storage device such as into the memory, the CPU loads the program or part of the program from the memory and executes it.
    [Show full text]
  • National Information Assurance Partnership
    National Information Assurance Partnership ® TM Common Criteria Evaluation and Validation Scheme Validation Report Green Hills Software INTEGRITY-178B Separation Kernel Report Number: CCEVS-VR-10119-2008 Dated: 01 September 2008 Version: 1.0 National Institute of Standards and Technology National Security Agency Information Technology Laboratory Information Assurance Directorate 100 Bureau Drive 9800 Savage Road STE 6757 Gaithersburg, MD 20899 Fort George G. Meade, MD 20755-6757 VALIDATION REPORT Green Hills Software INTEGRITY-178B Separation Kernel ACKNOWLEDGEMENTS Validation Team Shaun Gilmore Santosh Chokhani Ken Elliott Jerry Myers Paul Bicknell Common Criteria Testing Laboratory SAIC, Inc. Columbia, Maryland ii VALIDATION REPORT Green Hills Software INTEGRITY-178B Separation Kernel Table of Contents 1 Executive Summary................................................................1 1.1 Evaluation Details.............................................................2 2 Identification...........................................................................4 3 Threats to Security ..................................................................5 4 Security Policy........................................................................7 5 Assumptions............................................................................8 5.1 Physical Assumptions .......................................................8 5.2 Personnel Assumptions.....................................................8 5.3 Connectivity Assumptions................................................8
    [Show full text]
  • Windows Security Hardening Through Kernel Address Protection
    Windows Security Hardening Through Kernel Address Protection Mateusz \j00ru" Jurczyk August 2011 Abstract As more defense-in-depth protection schemes like Windows Integrity Control or sandboxing technologies are deployed, threats affecting local system components become a relevant issue in terms of the overall oper- ating system user's security plan. In order to address continuous develop- ment of Elevation of Privileges exploitation techniques, Microsoft started to enhance the Windows kernel security, by hardening the most sensitive system components, such as Kernel Pools with the Safe Unlinking mecha- nism introduced in Windows 7[19]. At the same time, the system supports numerous both official and undocumented services, providing valuable in- formation regarding the current state of the kernel memory layout. In this paper, we discuss the potential threats and problems concerning un- privileged access to the system address space information. In particular, we also present how subtle information leakages can prove useful in prac- tical attack scenarios. Further in the document, we conclusively provide some suggestions as to how problems related to kernel address information availability can be mitigated, or entirely eliminated. 1 Introduction Communication between distinct executable modules running at different priv- ilege levels or within separate security domains takes place most of the time, in numerous fields of modern computing. Both hardware- and software-enforced privilege separation mechanisms are designed to control the access to certain re- sources - grant it to modules with higher rights, while ensuring that unathorized entities are not able to reach the protected data. The discussed architecture is usually based on setting up a trusted set of modules (further referred to as \the broker") in the privileged area, while hav- ing the potentially malicious code (also called \the guest") executed in a con- trolled environment.
    [Show full text]