System Architectures to Improve Trust, Integrity and Resilience of Embedded Systems
Total Page:16
File Type:pdf, Size:1020Kb
Load more
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 / -
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 -
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. -
Improving the Reliability of Commodity Operating Systems
Improving the Reliability of Commodity Operating Systems MICHAEL M. SWIFT, BRIAN N. BERSHAD, and HENRY M. LEVY University of Washington Despite decades of research in extensible operating system technology, extensions such as device drivers remain a significant cause of system failures. In Windows XP, for example, drivers account for 85% of recently reported failures. This paper describes Nooks, a reliability subsystem that seeks to greatly enhance OS reliability by isolating the OS from driver failures. The Nooks approach is practical: rather than guaranteeing complete fault tolerance through a new (and incompatible) OS or driver architecture, our goal is to prevent the vast majority of driver-caused crashes with little or no change to existing driver and system code. Nooks isolates drivers within lightweight protection domains inside the kernel address space, where hardware and software prevent them from corrupting the kernel. Nooks also tracks a driver’s use of kernel resources to facilitate automatic clean-up during recovery. To prove the viability of our approach, we implemented Nooks in the Linux operating system and used it to fault-isolate several device drivers. Our results show that Nooks offers a substantial increase in the reliability of operating systems, catching and quickly recovering from many faults that would otherwise crash the system. Under a wide range and number of fault conditions, we show that Nooks recovers automatically from 99% of the faults that otherwise cause Linux to crash. While Nooks was designed for drivers, our techniques generalize to other kernel extensions. We demonstrate this by isolating a kernel-mode file system and an in-kernel Internet service. -
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................................................................................................ -
Elinos Product Overview
SYSGO Product Overview ELinOS 7 Industrial Grade Linux ELinOS is a SYSGO Linux distribution to help developers save time and effort by focusing on their application. Our Industrial Grade Linux with user-friendly IDE goes along with the best selection of software packages to meet our cog linux Qt LOCK customers needs, and with the comfort of world-class technical support. ELinOS now includes Docker support Feature LTS Qt Open SSH Configurator Kernel embedded Open VPN in order to isolate applications running on the same system. laptop Q Bug Shield-Virus Docker Eclipse-based QEMU-based Application Integrated Docker IDE HW Emulators Debugging Firewall Support ELINOS FEATURES MANAGING EMBEDDED LINUX VERSATILITY • Industrial Grade Creating an Embedded Linux based system is like solving a puzzle and putting • Eclipse-based IDE for embedded the right pieces together. This requires a deep knowledge of Linux’s versatility Systems (CODEO) and takes time for the selection of components, development of Board Support • Multiple Linux kernel versions Packages and drivers, and testing of the whole system – not only for newcomers. incl. Kernel 4.19 LTS with real-time enhancements With ELinOS, SYSGO offers an ‘out-of-the-box’ experience which allows to focus • Quick and easy target on the development of competitive applications itself. ELinOS incorporates the system configuration appropriate tools, such as a feature configurator to help you build the system and • Hardware Emulation (QEMU) boost your project success, including a graphical configuration front-end with a • Extensive file system support built-in integrity validation. • Application debugging • Target analysis APPLICATION & CONFIGURATION ENVIRONMENT • Runs out-of-the-box on PikeOS • Validated and tested for In addition to standard tools, remote debugging, target system monitoring and PowerPC, x86, ARM timing behaviour analyses are essential for application development. -
System Calls Instrumentation for Intrusion Detection In
System Calls Instrumentation for Intrusion Detection in Embedded Mixed-Criticality Systems Marine Kadar SYSGO GmbH, Klein-Winternheim, Germany [email protected] Sergey Tverdyshev SYSGO GmbH, Klein-Winternheim, Germany [email protected] Gerhard Fohler Technische Universität Kaiserslautern, Germany [email protected] Abstract System call relative information such as occurrences, type, parameters, and return values are well established metrics to reveal intrusions in a system software. Many Host Intrusion Detection Systems (HIDS) from research and industry analyze these data for continuous system monitoring at runtime. Despite a significant false alarm rate, this type of defense offers high detection precision for both known and zero-day attacks. Recent research focuses on HIDS deployment for desktop computers. Yet, the integration of such run-time monitoring solution in mixed-criticality embedded systems has not been discussed. Because of the cohabitation of potentially vulnerable non-critical software with critical software, securing mixed-criticality systems is a non trivial but essential issue. Thus, we propose a methodology to evaluate the impact of deploying system call instrumentation in such context. We analyze the impact in a concrete use-case with PikeOS real-time hypervisor. 2012 ACM Subject Classification Security and privacy → Embedded systems security; Security and privacy → Intrusion detection systems Keywords and phrases Instrumentation, Mixed-criticality, Real-Time, System Calls, Host Intrusion Detection Systems Digital Object Identifier 10.4230/OASIcs.CERTS.2019.2 Funding This work has received funding from the European Union’s Horizon 2020 research and innovation programme under the Marie Skłodowska-Curie grant agreement No. 764785, FORA—Fog Computing for Robotics and Industrial Automation. -
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. -
Debian \ Amber \ Arco-Debian \ Arc-Live \ Aslinux \ Beatrix
Debian \ Amber \ Arco-Debian \ Arc-Live \ ASLinux \ BeatriX \ BlackRhino \ BlankON \ Bluewall \ BOSS \ Canaima \ Clonezilla Live \ Conducit \ Corel \ Xandros \ DeadCD \ Olive \ DeMuDi \ \ 64Studio (64 Studio) \ DoudouLinux \ DRBL \ Elive \ Epidemic \ Estrella Roja \ Euronode \ GALPon MiniNo \ Gibraltar \ GNUGuitarINUX \ gnuLiNex \ \ Lihuen \ grml \ Guadalinex \ Impi \ Inquisitor \ Linux Mint Debian \ LliureX \ K-DEMar \ kademar \ Knoppix \ \ B2D \ \ Bioknoppix \ \ Damn Small Linux \ \ \ Hikarunix \ \ \ DSL-N \ \ \ Damn Vulnerable Linux \ \ Danix \ \ Feather \ \ INSERT \ \ Joatha \ \ Kaella \ \ Kanotix \ \ \ Auditor Security Linux \ \ \ Backtrack \ \ \ Parsix \ \ Kurumin \ \ \ Dizinha \ \ \ \ NeoDizinha \ \ \ \ Patinho Faminto \ \ \ Kalango \ \ \ Poseidon \ \ MAX \ \ Medialinux \ \ Mediainlinux \ \ ArtistX \ \ Morphix \ \ \ Aquamorph \ \ \ Dreamlinux \ \ \ Hiwix \ \ \ Hiweed \ \ \ \ Deepin \ \ \ ZoneCD \ \ Musix \ \ ParallelKnoppix \ \ Quantian \ \ Shabdix \ \ Symphony OS \ \ Whoppix \ \ WHAX \ LEAF \ Libranet \ Librassoc \ Lindows \ Linspire \ \ Freespire \ Liquid Lemur \ Matriux \ MEPIS \ SimplyMEPIS \ \ antiX \ \ \ Swift \ Metamorphose \ miniwoody \ Bonzai \ MoLinux \ \ Tirwal \ NepaLinux \ Nova \ Omoikane (Arma) \ OpenMediaVault \ OS2005 \ Maemo \ Meego Harmattan \ PelicanHPC \ Progeny \ Progress \ Proxmox \ PureOS \ Red Ribbon \ Resulinux \ Rxart \ SalineOS \ Semplice \ sidux \ aptosid \ \ siduction \ Skolelinux \ Snowlinux \ srvRX live \ Storm \ Tails \ ThinClientOS \ Trisquel \ Tuquito \ Ubuntu \ \ A/V \ \ AV \ \ Airinux \ \ Arabian -
Legacy Reuse
Faculty of Computer Science Institute for System Architecture, Operating Systems Group LEGACY REUSE CARSTEN WEINHOLD THIS LECTURE ... ■ So far ... ■ Basic microkernel concepts ■ Drivers, resource management ■ Today: ■ How to provide legacy OS personalities ■ How to reuse existing infrastructure ■ How to make applications happy TU Dresden Legacy Reuse 2 VIRTUALIZATION ■ Virtualization: ■ Reuse legacy OS + applications ■ Run applications in natural environment ■ Problem: Applications trapped in VMs ■ Different resource pools, namespaces ■ Cooperation is cumbersome (network, ...) ■ Full legacy OS in VM adds overhead ■ Multiple desktops? Bad user experience TU Dresden Legacy Reuse 3 MAKING THE CUT ■ Hardware level: Next week ■ Virtualize legacy OS on top of new OS ■ Operating System Personality: ■ Legacy OS interfaces reimplemented on top of – or ported to – new OS ■ Hybrid operating systems: Today ■ Run legacy OS virtualized … ■ … but tightly integrated with new OS TU Dresden Legacy Reuse 4 OPERATING SYSTEM PERSONALITIES TU Dresden Legacy Reuse 5 OS PERSONALITY ■ Idea: Adapt OS / application boundary ■ (Re-)Implement legacy APIs, not whole OS ■ May need to recompile application ■ Benefits: ■ Get desired application, established APIs ■ Good integration (namespaces, files, ...) ■ Smaller overhead than virtualization ■ Flexible, configurable, but more effort? TU Dresden Legacy Reuse 6 MONOLITHIC KERNELS App App Monolithic Kernel System Call Entry Ext2 VFAT IP Stack Disk Driver NIC Driver TU Dresden Legacy Reuse 7 DECOMPOSITION App App App App Monolithic -
Kernel Architectures
A short history of kernels n Early kernel: a library of device drivers, support for threads (QNX) Operating System Kernels n Monolithic kernels: Unix, VMS, OS 360… n Unstructured but fast… n Over time, became very large Ken Birman n Eventually, DLLs helped on size n Pure microkernels: Mach, Amoeba, Chorus… (borrowing some content from n OS as a kind of application Peter Sirokman) n Impure microkernels: Modern Windows OS n Microkernel optimized to support a single OS n VMM support for Unix on Windows and vice versa The great m-kernel debate Summary of First Paper n How big does it need to be? n The Performance of µ-Kernel-Based Systems (Hartig et al. 16th SOSP, Oct 1997) n With a m-kernel protection-boundary crossing forces us to n Evaluates the L4 microkernel as a basis for a full operating system n Change memory -map n Ports Linux to run on top of L4 and compares n Flush TLB (unless tagged) performance to native Linux and Linux running on n With a macro-kernel we lose structural the Mach microkernel protection benefits and fault-containment n Explores the extensibility of the L4 microkernel n Debate raged during early 1980’s Summary of Second Paper In perspective? n The Flux OSKit: A Substrate for Kernel and n L4 seeks to validate idea that a m-kernel Language Research (Ford et al. 16th SOSP, can support a full OS without terrible 1997) cost penalty n Describes a set of OS components designed to be used to build custom operating systems n Opened the door to architectures like the n Includes existing code simply using “glue code” Windows -
The Nizza Secure-System Architecture
Appears in the proceedings of CollaborateCom 2005, San Jose, CA, USA The Nizza Secure-System Architecture Hermann Härtig Michael Hohmuth Norman Feske Christian Helmuth Adam Lackorzynski Frank Mehnert Michael Peter Technische Universität Dresden Institute for System Architecture D-01062 Dresden, Germany [email protected] Abstract rely on a standard OS (including the kernel) to assure their security properties. The trusted computing bases (TCBs) of applications run- To address the conflicting requirements of complete ning on today’s commodity operating systems have become functionality and the protection of security-sensitive data, extremely large. This paper presents an architecture that researchers have devised system architectures that reduce allows to build applications with a much smaller TCB. It the system’s TCB by running kernels in untrusted mode is based on a kernelized architecture and on the reuse of in a secure compartment on top of a small security kernel; legacy software using trusted wrappers. We discuss the de- security-sensitive services run alongside the OS in isolated sign principles, the architecture and some components, and compartments of their own. This architecture is widely re- a number of usage examples. ferred to as kernelized standard OS or kernelized system. In this paper, we describe Nizza, a new kernelized- system architecture. In the design of Nizza, we set out to answer the question of how small the TCB can be made. 1 Introduction We have argued in previous work that the (hardware and software) technologies needed to build small secure-system Desktop and hand-held computers are used for many platforms have become much more mature since earlier at- functions, often in parallel, some of which are security tempts [8].