End-To-End Verification of Memory Isolation

Total Page:16

File Type:pdf, Size:1020Kb

End-To-End Verification of Memory Isolation Secure System Virtualization: End-to-End Verification of Memory Isolation HAMED NEMATI Doctoral Thesis Stockholm, Sweden 2017 TRITA-CSC-A-2017:18 KTH Royal Institute of Technology ISSN 1653-5723 School of Computer Science and Communication ISRN-KTH/CSC/A--17/18-SE SE-100 44 Stockholm ISBN 978-91-7729-478-8 SWEDEN Akademisk avhandling som med tillstånd av Kungl Tekniska högskolan framlägges till offentlig granskning för avläggande av teknologie doktorsexamen i datalogi fre- dagen den 20 oktober 2017 klockan 14.00 i Kollegiesalen, Kungl Tekniska högskolan, Brinellvägen 8, Stockholm. © Hamed Nemati, October 2017 Tryck: Universitetsservice US AB iii Abstract Over the last years, security kernels have played a promising role in re- shaping the landscape of platform security on today’s ubiquitous embedded devices. Security kernels, such as separation kernels, enable constructing high-assurance mixed-criticality execution platforms. They reduce the soft- ware portion of the system’s trusted computing base to a thin layer, which enforces isolation between low- and high-criticality components. The reduced trusted computing base minimizes the system attack surface and facilitates the use of formal methods to ensure functional correctness and security of the kernel. In this thesis, we explore various aspects of building a provably secure separation kernel using virtualization technology. In particular, we examine techniques related to the appropriate management of the memory subsystem. Once these techniques were implemented and functionally verified, they pro- vide reliable a foundation for application scenarios that require strong guar- antees of isolation and facilitate formal reasoning about the system’s overall security. We show how the memory management subsystem can be virtualized to enforce isolation of system components. Virtualization is done by using direct paging that enables a guest software under some circumstances to manage its own memory configuration. We demonstrate the soundness of our approach by verifying that the high-level model of the system fulfills the desired security properties. Through refinement, we then propagate these properties (semi-) automatically to the machine-code of the virtualization mechanism. An application of isolating platforms is to provide external protection to an untrusted guest operating system to restrict its attack surface. We show how a runtime monitor can be securely deployed alongside a Linux guest on a hypervisor to prevent code injection attacks targeting Linux. The monitor takes advantage of the provided separation to protect itself and to retain a complete view of the guest software. Separating components using a low-level software, while important, is not by itself enough to guarantee security. Indeed, current processors ar- chitecture involves features, such as caches, that can be utilized to violate the isolation of components. In this thesis, we present a new low noise at- tack vector constructed by measuring cache effects. The vector is capable of breaching isolation between components of different criticality levels, and it invalidates the verification of software that has been verified on a mem- ory coherent (cacheless) model. To restore isolation, we provide a number of countermeasures. Further, we propose a new methodology to repair the verification of the software by including data-caches in the statement of the top-level security properties of the system. Sammanfattning Inbyggda system finns överallt idag. Under senare år har utvecklingen av platformssäkerhet för inbyggda system spelat en allt större roll. Säker- hetskärnor, likt isoleringskärnor, möjliggör konstruktion av tillförlitliga exe- kveringsplatformar ämnade för både kritiska och icke-kritiska tillämpningar. Säkerhetskärnor reducerar systemets kritiska kodmängd i ett litet tunt mjuk- varulager. Detta mjukvarulager upprättar en tillförlitlig isolering mellan olika mjukvarukomponenter, där vissa mjukvarukomponenter har kritiska roller och andra inte. Det tunna mjukvarulagret minimerar systemets attackyta och un- derlättar användningen av formella metoder för att försäkra mjukvarulagrets funktionella korrekthet och säkerhet. I denna uppsats utforskas olika aspekter för att bygga en isoleringskärna med virtualiseringsteknik sådant att det går att bevisa att isoleringskärnan är säker. I huvudsak undersöks tekniker för säker hantering av minnessystemet. Implementering och funktionell verifiering av dessa minneshanteringstekniker ger en tillförlitlig grund för användningsområden med höga krav på isolering och underlättar formell argumentation om att systemet är säkert. Det visas hur minneshanteringssystemet kan virtualiseras i syfte om att isolera systemkomponenter. Virtualiseringstekniken bakom minnessystemet är direkt paging och möjliggör gästmjukvara, under vissa begränsningar, att konfigurera sitt eget minne. Denna metods sundhet demonstreras genom veri- fiering av att högnivåmodellen av systemet satisfierar de önskade säkerhetse- genskaperna. Genom förfining överförs dessa egenskaper (semi-) automatiskt till maskinkoden som utgör virtualiseringsmekanismen. En isolerad gästapplikation ger externt skydd för ett potentiellt angri- pet gästoperativsystem för att begränsa den senares attackyta. Det visas hur en körningstidsövervakare kan köras säkert i systemet ovanpå en hypervi- sor bredvid en Linuxgäst för att förhindra kodinjektionsattacker mot Linux. Övervakaren utnyttjar systemets isoleringsegenskaper för att skydda sig själv och för att ha en korrekt uppfattning av gästmjukvarans status. Isolering av mjukvarukomponenter genom lågnivåmjukvara är inte i sig tillräckligt för att garantera säkerhet. Dagens processorarkitekturer har funk- tioner, som exempelvis cacheminnen, som kan utnyttjas för att kringgå iso- leringen mellan mjukvarukomponenter. I denna uppsats presenteras en ny attack som inte är störningskänslig och som utförs genom att analysera cache- operationer. Denna attack kan kringgå isoleringen mellan olika mjukvarukom- ponenter, där vissa komponenter har kritiska roller och andra inte. Attacken ogiltigförklarar också verifiering av mjukvara om verifieringen antagit en min- neskoherent (cachefri) modell. För att motverka denna attack presenteras ett antal motmedel. Utöver detta föreslås också en ny metodik för att återvalidera mjukvaruverifieringen genom att inkludera data-cacheminnen i formuleringen av systemets säkerhetsegenskaper. v Acknowledgements I would like to express my sincere gratitude and appreciation to my main super- visor, Prof. Mads Dam for his encouragement and support, which brought to the completion of this thesis. Mads’ high standards have significantly enriched my research. I am deeply grateful to my colleagues Roberto Guanciale, Oliver Schwarz (you are one of “the best” ;)), Christoph Baumann, Narges Khakpour, Arash Vahidi, and Viktor Do for their supports, valuable comments, and advices during the entire progress of this thesis. I would also like to thank all people I met at TCS, especially Adam Schill Collberg, Andreas Lindner, Benjamin Greschbach, Cenny Wenner, Cyrille Artho (thanks for reading the thesis draft and providing good suggestions), Daniel Bosk (trevligt att träffas Daniel), Emma Enström, Hojat Khosrowjerdi, Ilario Bonacina, Jan Elffers, Jesús Giráldez Crú, Jonas Haglund (thanks for helping with the ab- stract), Joseph Swernofsky, Linda Kann, Marc Vinyals, Mateus de Oliveira Oliveira, Mika Cohen, Mladen Mikša, Muddassar Azam Sindhu, Musard Balliu, Pedro de Carvalho Gomes, Roelof Pieters (I like you too :)), Sangxia Huang, Susanna Figueiredo de Rezende, Thatchaphol Saranurak, Thomas Tuerk, and Xin Zhao for lunch company and making TCS a great place. I am truly thankful to my dear friends Vahid Mosavat, Mohsen Khosravi, Guillermo Rodríguez Cano, and Ali Jafari, who made my stay in Sweden more pleasant. Last but not the least, huge thanks to my parents, my sister and Razieh for their endless love, moral support and encouragement, without which I would have never been able to complete this important step of my life. Contents Contents vi I Introduction and Summary 1 Abbreviations 3 1 Introduction 5 1.1 Overview . 5 1.2 Thesis Statement . 7 1.3 Thesis Outline . 9 2 Background 11 2.1 Platform Security . 12 2.2 Formal Verification . 24 2.3 Summary . 36 3 Related Work 37 3.1 Verification of Security-Kernels . 37 3.2 Trustworthy Runtime Monitoring . 40 3.3 Attack On Isolation . 41 3.4 Summary . 41 4 Contributions 43 4.1 Summary of Included Papers . 43 4.2 Further Publications . 48 5 Conclusions 49 5.1 Contribution . 49 5.2 Concluding Remarks and Future Work . 50 vi CONTENTS vii II Included Papers 53 A Provably secure memory isolation for Linux on ARM 55 A.1 Introduction . 55 A.2 Related Work . 58 A.3 Verification Approach . 60 A.4 The ARMv7 CPU . 66 A.5 The Memory Virtualization API . 70 A.6 Formalizing the Proof Goals . 77 A.7 TLS Consistency . 83 A.8 Refinement . 87 A.9 Binary Verification . 88 A.10 Implementation . 98 A.11 Evaluation . 102 A.12 Applications . 103 A.13 Concluding Remarks . 107 B Trustworthy Prevention of Code Injection in Linux on Embed- ded Devices 109 B.1 Introduction . 109 B.2 Background . 111 B.3 Design . 116 B.4 Formal Model of MProsper . 118 B.5 Verification Strategy . 121 B.6 Evaluation . 124 B.7 Related Work . 125 B.8 Concluding Remarks . 126 C Cache Storage Channels: Alias-Driven Attacks and Verified Coun- termeasures 129 C.1 Introduction . 129 C.2 Background . 131 C.3 The New Attack Vectors: Cache Storage Channels . 133 C.4 Case Studies . 139 C.5 Countermeasures . 146 C.6
Recommended publications
  • Real-Time, Safe and Certified OS
    Real-Time, Safe and Certified OS Roman Kapl <[email protected]> drivers, customer projects, development Tomas Martinec <[email protected]> testing and certification © SYSGO AG · INTERNAL 1 Introduction • PikeOS – real-time, safety certified OS • Desktop and Server vs. • Embedded • Real-Time • Safety-Critical • Certified • Differences • Scheduling • Resource management • Features • Development © SYSGO AG · INTERNAL 2 Certification • Testing • Analysis • Lot of time • Even more paper • Required for safety-critical systems • Trains • Airplanes © SYSGO AG · INTERNAL 3 PikeOS • Embedded, real-time, certified OS • ~150 people (not just engineers) • Rail • Avionics • Space • This presentation is not about PikeOS specifically © SYSGO AG · INTERNAL 4 PikeOS technical • Microkernel • Inspired by L4 • Memory protection (MMU) • More complex than FreeRTOS • Virtualization hypervisor • X86, ARM, SPARC, PowerPC • Eclipse IDE for development © SYSGO AG · INTERNAL 5 Personalities • General • POSIX • Linux • Domain specific • ARINC653 • PikeOS native • Other • Ada, RT JAVA, AUTOSAR, ITRON, RTEMS © SYSGO AG · INTERNAL 6 PikeOS Architecture App. App. App. App. App. App. Volume Syste m Provider Partition PikeOS Para-Virtualized HW Virtualized File System (Native, POSIX, Guest OS PikeOS Native ARINC653, ...) Guest OS Linux, Android Linux, Android Device Driver User Space / Partitions Syste m PikeOS System Software ExtensionSyste m Extension PikeOS Microkernel Kernel Space / Hypervisor Architecture Platform Kernel Level Support Package Support Package Driver SoC /
    [Show full text]
  • Memory Protection at Option
    Memory Protection at Option Application-Tailored Memory Safety in Safety-Critical Embedded Systems – Speicherschutz nach Wahl Auf die Anwendung zugeschnittene Speichersicherheit in sicherheitskritischen eingebetteten Systemen Der Technischen Fakultät der Universität Erlangen-Nürnberg zur Erlangung des Grades Doktor-Ingenieur vorgelegt von Michael Stilkerich Erlangen — 2012 Als Dissertation genehmigt von der Technischen Fakultät Universität Erlangen-Nürnberg Tag der Einreichung: 09.07.2012 Tag der Promotion: 30.11.2012 Dekan: Prof. Dr.-Ing. Marion Merklein Berichterstatter: Prof. Dr.-Ing. Wolfgang Schröder-Preikschat Prof. Dr. Michael Philippsen Abstract With the increasing capabilities and resources available on microcontrollers, there is a trend in the embedded industry to integrate multiple software functions on a single system to save cost, size, weight, and power. The integration raises new requirements, thereunder the need for spatial isolation, which is commonly established by using a memory protection unit (MPU) that can constrain access to the physical address space to a fixed set of address regions. MPU-based protection is limited in terms of available hardware, flexibility, granularity and ease of use. Software-based memory protection can provide an alternative or complement MPU-based protection, but has found little attention in the embedded domain. In this thesis, I evaluate qualitative and quantitative advantages and limitations of MPU-based memory protection and software-based protection based on a multi-JVM. I developed a framework composed of the AUTOSAR OS-like operating system CiAO and KESO, a Java implementation for deeply embedded systems. The framework allows choosing from no memory protection, MPU-based protection, software-based protection, and a combination of the two.
    [Show full text]
  • Sistemi Operativi Real-Time Marco Cesati Lezione R13 Sistemi Operativi Real-Time – II Schema Della Lezione
    Sistemi operativi real-time Marco Cesati Lezione R13 Sistemi operativi real-time – II Schema della lezione Caratteristiche comuni VxWorks LynxOS Sistemi embedded e real-time QNX eCos Windows Linux come RTOS 15 gennaio 2013 Marco Cesati Dipartimento di Ingegneria Civile e Ingegneria Informatica Università degli Studi di Roma Tor Vergata SERT’13 R13.1 Sistemi operativi Di cosa parliamo in questa lezione? real-time Marco Cesati In questa lezione descriviamo brevemente alcuni dei più diffusi sistemi operativi real-time Schema della lezione Caratteristiche comuni VxWorks LynxOS 1 Caratteristiche comuni degli RTOS QNX 2 VxWorks eCos 3 LynxOS Windows Linux come RTOS 4 QNX Neutrino 5 eCos 6 Windows Embedded CE 7 Linux come RTOS SERT’13 R13.2 Sistemi operativi Caratteristiche comuni dei principali RTOS real-time Marco Cesati Corrispondenza agli standard: generalmente le API sono proprietarie, ma gli RTOS offrono anche compatibilità (compliancy) o conformità (conformancy) allo standard Real-Time POSIX Modularità e Scalabilità: il kernel ha una dimensione Schema della lezione Caratteristiche comuni (footprint) ridotta e le sue funzionalità sono configurabili VxWorks Dimensione del codice: spesso basati su microkernel LynxOS QNX Velocità e Efficienza: basso overhead per cambi di eCos contesto, latenza delle interruzioni e primitive di Windows sincronizzazione Linux come RTOS Porzioni di codice non interrompibile: generalmente molto corte e di durata predicibile Gestione delle interruzioni “separata”: interrupt handler corto e predicibile, ISR lunga
    [Show full text]
  • Performance Study of Real-Time Operating Systems for Internet Of
    IET Software Research Article ISSN 1751-8806 Performance study of real-time operating Received on 11th April 2017 Revised 13th December 2017 systems for internet of things devices Accepted on 13th January 2018 E-First on 16th February 2018 doi: 10.1049/iet-sen.2017.0048 www.ietdl.org Rafael Raymundo Belleza1 , Edison Pignaton de Freitas1 1Institute of Informatics, Federal University of Rio Grande do Sul, Av. Bento Gonçalves, 9500, CP 15064, Porto Alegre CEP: 91501-970, Brazil E-mail: [email protected] Abstract: The development of constrained devices for the internet of things (IoT) presents lots of challenges to software developers who build applications on top of these devices. Many applications in this domain have severe non-functional requirements related to timing properties, which are important concerns that have to be handled. By using real-time operating systems (RTOSs), developers have greater productivity, as they provide native support for real-time properties handling. Some of the key points in the software development for IoT in these constrained devices, like task synchronisation and network communications, are already solved by this provided real-time support. However, different RTOSs offer different degrees of support to the different demanded real-time properties. Observing this aspect, this study presents a set of benchmark tests on the selected open source and proprietary RTOSs focused on the IoT. The benchmark results show that there is no clear winner, as each RTOS performs well at least on some criteria, but general conclusions can be drawn on the suitability of each of them according to their performance evaluation in the obtained results.
    [Show full text]
  • Using an MPU to Enforce Spatial Separation
    HighIntegritySystems Using an MPU to Enforce Spatial Separation Issue 1.3 - November 26, 2020 Copyright WITTENSTEIN aerospace & simulation ltd date as document, all rights reserved. WITTENSTEIN high integrity systems v Americas: +1 408 625 4712 ROTW: +44 1275 395 600 Email: [email protected] Web: www.highintegritysystems.com HighIntegritySystems Contents Contents..........................................................................................................................................2 List Of Figures.................................................................................................................................3 List Of Notation...............................................................................................................................3 CHAPTER 1 Introduction.....................................................................................................4 1.1 Introduction..............................................................................................................................4 1.2 Use Case - An Embedded System...........................................................................................5 CHAPTER 2 System Architecture and its Effect on Spatial Separation......................6 2.1 Spatial Separation with a Multi-Processor System....................................................................6 2.2 Spatial Separation with a Multi-Core System............................................................................6 2.3 Spatial Separation
    [Show full text]
  • Strict Memory Protection for Microcontrollers
    Master Thesis Spring 2019 Strict Memory Protection for Microcontrollers Erlend Sveen Supervisor: Jingyue Li Co-supervisor: Magnus Själander Sunday 17th February, 2019 Abstract Modern desktop systems protect processes from each other with memory protection. Microcontroller systems, which lack support for memory virtualization, typically only uses memory protection for areas that the programmer deems necessary and does not separate processes completely. As a result the application still appears monolithic and only a handful of errors may be detected. This thesis presents a set of solutions for complete separation of processes, unleash- ing the full potential of the memory protection unit embedded in modern ARM-based microcontrollers. The operating system loads multiple programs from disk into indepen- dently protected portions of memory. These programs may then be started, stopped, modified, crashed etc. without affecting other running programs. When loading pro- grams, a new allocation algorithm is used that automatically aligns the memories for use with the protection hardware. A pager is written to satisfy additional run-time demands of applications, and communication primitives for inter-process communication is made available. Since every running process is unable to get access to other running processes, not only reliability but also security is improved. An application may be split so that unsafe or error-prone code is separated from mission-critical code, allowing it to be independently restarted when an error occurs. With executable and writeable memory access rights being mutually exclusive, code injection is made harder to perform. The solution is all transparent to the programmer. All that is required is to split an application into sub-programs that operates largely independently.
    [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]
  • Security Target Pikeos Separation Kernel V4.2.2
    Security Target PikeOS Separation Kernel v4.2.2 Document ID Revision DOORS Baseline Date State 00101-8000-ST 20.6 N.A. 2018-10-10 App Author: Dominic Eschweiler SYSGO AG Am Pfaffenstein 14, D-55270 Klein-Winternheim Notice: The contents of this document are proprietary to SYSGO AG and shall not be disclosed, disseminated, copied, or used except for purposes expressly authorized in writing by SYSGO AG. Doc. ID: 00101-8000-ST Revision: 20.6 This page intentionally left blank Copyright 2018 Page 2 of 47 All rights reserved. SYSGO AG Doc. ID: 00101-8000-ST Revision: 20.6 This page intentionally left blank Copyright 2018 Page 3 of 47 All rights reserved. SYSGO AG Doc. ID: 00101-8000-ST Revision: 20.6 Table of Contents 1 Introduction .................................................................................................................... 6 1.1 Purpose of this Document ........................................................................................... 6 1.2 Document References ................................................................................................ 6 1.2.1 Applicable Documents......................................................................................... 6 1.2.2 Referenced Documents ....................................................................................... 6 1.3 Abbreviations and Acronyms ....................................................................................... 6 1.4 Terms and Definitions................................................................................................
    [Show full text]
  • Memory Protection in Embedded Systems Lanfranco Lopriore Dipartimento Di Ingegneria Dell’Informazione, Università Di Pisa, Via G
    CORE Metadata, citation and similar papers at core.ac.uk Provided by Archivio della Ricerca - Università di Pisa Memory protection in embedded systems Lanfranco Lopriore Dipartimento di Ingegneria dell’Informazione, Università di Pisa, via G. Caruso 16, 56126 Pisa, Italy E-mail: [email protected] Abstract — With reference to an embedded system featuring no support for memory manage- ment, we present a model of a protection system based on passwords and keys. At the hardware level, our model takes advantage of a memory protection unit (MPU) interposed between the processor and the complex of the main memory and the input-output devices. The MPU sup- ports both concepts of a protection context and a protection domain. A protection context is a set of access rights for the memory pages; a protection domain is a set of one or more protection contexts. Passwords are associated with protection domains. A process that holds a key match- ing a given password can take advantage of this key to activate the corresponding domain. A small set of protection primitives makes it possible to modify the composition of the domains in a strictly controlled fashion. The proposed protection model is evaluated from a number of salient viewpoints, which include key distribution, review and revocation, the memory requirements for storage of the information concerning protection, and the time necessary for key validation. Keywords: access right; embedded system; protection; revocation. 1. INTRODUCTION We shall refer to a typical embedded system architecture featuring a microprocessor inter- facing both volatile and non-volatile primary memory devices, as well as a variety of input/out- put devices including sensors and actuators.
    [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]
  • Us 2019 / 0319868 A1
    US 20190319868A1 ( 19) United States (12 ) Patent Application Publication ( 10) Pub . No. : US 2019 /0319868 A1 Svennebring et al. ( 43 ) Pub . Date : Oct. 17 , 2019 ( 54 ) LINK PERFORMANCE PREDICTION (52 ) U . S . CI. TECHNOLOGIES CPC .. .. H04L 43/ 0882 (2013 . 01 ); H04W 24 /08 ( 2013 . 01 ) (71 ) Applicant : Intel Corporation , Santa Clara , CA (57 ) ABSTRACT (US ) Various systems and methods for determining and commu nicating Link Performance Predictions (LPPs ), such as in ( 72 ) Inventors : Jonas Svennebring , Sollentuna (SE ) ; connection with management of radio communication links, Antony Vance Jeyaraj, Bengaluru ( IN ) are discussed herein . The LPPs are predictions of future network behaviors /metrics ( e . g . , bandwidth , latency , capac (21 ) Appl . No. : 16 /452 , 352 ity , coverage holes , etc . ) . The LPPs are communicated to applications and /or network infrastructure, which allows the applications/ infrastructure to make operational decisions for ( 22 ) Filed : Jun . 25 , 2019 improved signaling / link resource utilization . In embodi ments , the link performance analysis is divided into multiple layers that determine their own link performance metrics, Publication Classification which are then fused together to make an LPP. Each layer (51 ) Int . Cl. runs different algorithms, and provides respective results to H04L 12 / 26 ( 2006 .01 ) an LPP layer /engine that fuses the results together to obtain H04W 24 / 08 (2006 .01 ) the LPP . Other embodiments are described and / or claimed . 700 Spatio - Temporal History Data Tx1 : C1 TIDE _ 1, DE _ 2 . .. Txt : C2 T2 DE _ 1 , DE _ 2 , . .. win Txs : C3 122 T : DE _ 1, DE _ 2 , .. TN DE _ 1 , DE _ 2 .. TxN : CN CELL LOAD MODEL 710 Real- Time Data 744 704 Patent Application Publication Oct.
    [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]