DOCSLIB.ORG

Interactive Runtime Verification Raphaël Jakse

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Interactive Runtime Verification Raphaël Jakse Interactive Runtime Verification Raphaël Jakse To cite this version: Raphaël Jakse. Interactive Runtime Verification. Mathematical Software [cs.MS]. Université Grenoble Alpes, 2019. English. NNT : 2019GREAM075. tel-02460734v2 HAL Id: tel-02460734 https://hal.inria.fr/tel-02460734v2 Submitted on 28 Sep 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. THÈSE Pour obtenir le grade de DOCTEUR DE LA COMMUNAUTÉ UNIVERSITÉ GRENOBLE ALPES Spécialité : informatique Arrêté ministériel : 25 mai 2016 Présentée par Raphaël Jakse Thèse dirigée par Jean-François Méhaut et encadrée par Yliès Falcone, Université Grenoble Alpes préparée au sein du Laboratoire d’Informatique de Grenoble à l’École Doctorale Mathématiques, Sciences et technologies de l’information, Informatique Interactive Runtime Verification Vérification de propriétés interactive à l'exécution Thèse soutenue publiquement le 18 Décembre 2019, devant le jury composé de : Fabrice Dupros Ingénieur de recherche, ARM, examinateur Yliès Falcone Maître de conférence, Université Grenoble Alpes, encadrant de thèse João Lourenço Professeur, Universidade Nova de Lisboa, rapporteur Jean-François Méhaut Professeur, Université Grenoble Alpes, directeur de thèse Hervé Marchand Charché de recherche, Inria Rennes Bretagne-Atlantique, examinateur Gwen Salaün Professeur, Inria Grenoble, Examinateur, président du jury Alexandre Termier Professeur, Inria Rennes Bretagne-Atlantique, rapporteur Abstract Résumé en Français Les ordinateurs sont partout. Nous leur faisons confiance pour un grand, et grandissant, nombre de tâches, parmi lesquelles certaines sont critiques. Les conséquences des bogues logiciels sont diverses, de l’agacement léger à la mort de plusieurs personnes. Ainsi, il est important de s’assurer que les logiciels sont fiables. Corriger les bogues est une activité très chronophage du processus de développement logiciel. Dans cette thèse, nous présentons la vérification interactive à l’exécution, qui combine la vérification à l’exécution et le débogage interactif. La vérification à l’exécu- tion est une méthode formelle pour étudier le comportement d’un système à l’exécution. Elle consiste à faire correspondre des traces d’exécutions d’un système avec des pro- priétés comportementales. Ces propriétés font partie des spécifications du système. Le débogage interactif consiste à étudier un système durant son exécution pour comprendre ses bogues et les corriger en inspectant interactivement son état interne. La vérification interactive à l’exécution a pour objectif de rendre le débogage interactif moins fastidieux et plus systématique en s’appuyant sur les aspects automatiques et rigoureux de la vérifi- cation à l’exécution. Nous avons pour but de faciliter la partie débogage du processus de développement logiciel. Nous définissons une manière efficace et pratique de vérifier des propriétés comportementales automatiquement sur un programme en utilisant un débo- gueur interactif. Nous rassemblons la détection et la compréhension de bogues dans une méthodologie intégrée, en guidant le débogage interactif avec la vérification à l’exécution. Nous fournissons un modèle formel pour les programmes vérifiés interactivement à l’exé- cution. Nous modélisons l’exécution d’un programme en train d’être débogué, composé avec un moniteur (pour l’émission de verdicts) et un scénario (pour conduire la session de débogage). Nous fournissons des garanties sur la validité des verdicts produits par le moniteur en nous appuyant sur une relation de simulation faible entre le programme initial et le programme vérifié interactivement. De plus, nous fournissons une vue algo- rithmique du modèle adaptée à l’écriture d’implémentations. Nous introduisons ensuite un cadre et une architecture distribuée pour la vérification interactive à l’exécution. Cela permet de vérifier plusieurs propriétés simultanément et de déboguer un système dis- tribué, composé de multiples processus communicants. Les moniteurs, le scénario et les programmes débogués eux-mêmes s’exécutent de façon distribuée en utilisant un pro- tocole que nous avons vérifié avec le vérificateur de modèles SPIN. Notre architecture distribuée est conçue pour s’adapter à des composants existants. Nous présentons Verde, une implémentation de la vérification interactive à l’exécution. Une première version est basée sur le débogueur GNU (GDB) pour vérifier interacti- vement des programmes C et C++. Une deuxième version, Dist-Verde, est une implé- mentation de notre architecture distribuée compatible avec les programmes C et C++ à travers GDB et les programmes Java à travers JDB, le débogueur Java. Nous présentons des expérimentations en utilisant Verde, évaluant l’utilité de l’approche et les performances de notre implémentation. Nos résultats montrent que la vérification interactive à l’exécution est applicable dans une variété de cas et aide à étudier les bogues. Mots-clés : vérification à l’exécution, débogage interactif, fiabilité, ingénierie logicielle, systèmes distribués, propriétés, bogues 3 3 Abstract in English Computers are ubiquitous. We trust them for a huge and increasing number of tasks, some critical. Consequences of software defects are various, from little annoyances to the loss of multiple lives. Hence, ensuring software reliability is instrumental. Fixing bugs is a very time-consuming activity of the software development cycle. In this thesis, we present interactive runtime verification (i-RV), which combines runtime verification and interactive debugging. Runtime verification is a formal method to study the behavior of a system at runtime. It consists in matching runtime traces of a sys- tem at runtime against behavioral properties. These properties are part of the system specification. Interactive debugging consists in studying a system at runtime in order to understand its bugs and fix them, inspecting its internal state interactively. Interactive runtime verification aims to make interactive debugging less tedious and more system- atic by leveraging the rigorous and automated aspects of runtime verification. We aim to ease the debugging part of the software development cycle. We define an efficient and convenient way to check behavioral properties automatically on a program using an interactive debugger. We gather bug detection and bug understanding in an integrated workflow, by guiding interactive debugging using runtime verification. We provide a formal model for interactively runtime verified programs. We model the execution of a program under a debugger composed with a monitor (for verdict emis- sion) and a scenario (for steering the debugging session). We provide guarantees on the soundness of the verdicts issued by the monitor by exhibiting a weak simulation (relation) between the initial program and the interactively runtime verified program. Moreover, we provide an algorithmic view of this model suitable for producing implementations. We then introduce a distributed and adaptive framework for interactive runtime verifica- tion. It allows checking several requirements simultaneously and debugging a distributed system composed of communicating processes. The monitors, the scenario and the de- bugged programs themselves run distributed using an orchestrating protocol which we verified using the SPIN model checker. Our distributed framework is designed to adapt to existing components. We present Verde, an implementation of interactive runtime verification. A first version is based on the GNU Debugger (GDB) to interactively runtime verify C and C++ pro- grams. A second version, Dist-Verde, is an implementation of our distributed framework compatible with C and C++ programs through GDB and Java programs through JDB, the Java Debugger. We report on experiments using Verde assessing the usefulness of interactive runtime verification and the performance of our implementation. Our results show that interactive runtime verification is applicable in a variety of cases and helps to study bugs. Keywords: runtime verification, interactive debugging, reliability, software engineer- ing, distributed systems, property, bugs. Merci ! Je tiens à remercier Chloé, Maman et Papa, pour m’avoir accompagné, guidé et soutenu tout au long de ce doctorat, et bien avant. Merci pour ces weekends tranquilles et rassurants loin de l’agitation et de la polution citadine, ces apéros, ces moments studieux ensemble, ces randonnées agréables, ces petites marches ou ces tours de vélo autour de la maison. On vient quand même malgré la connexion moisie, parce qu’on y est bien. Merci aussi pour ces petits restos sur le campus. Je voudrais remercier Mamie et Papi, qui ont toujours été confiants sur le bon déroulement de mes études, y compris ce doctorat. Merci aussi à toute la famille : Camille, Donavan, Émilie, Geneviève, Gérald, Laurent, Lisa, Marie-Noelle, Marion, Rémi, Séverine. Vous êtes géniaux. Merci Bruno, Céline et Ludo, plus loins mais là. Je tiens aussi à remercier Solène, qui a décidé de bien vouloir me supporter au cours de la dernière année de ce doctorat. Une tâche ardue s’il en est. Merci pour toute cette joie
Load more

Recommended publications
  • Checkpoint and Restoration of Micro-Service in Docker Containers
    3rd International Conference on Mechatronics and Industrial Informatics (ICMII 2015) Checkpoint and Restoration of Micro-service in Docker Containers Chen Yang School of Information Security Engineering, Shanghai Jiao Tong University, China 200240 [email protected] Keywords: Lightweight Virtualization, Checkpoint/restore, Docker. Abstract. In the present days of rapid adoption of micro-service, it is imperative to build a system to support and ensure the high performance and high availability for micro-services. Lightweight virtualization, which we also called container, has the ability to run multiple isolated sets of processes under a single kernel instance. Because of the possibility of obtaining a low overhead comparable to the near-native performance of a bare server, the container techniques, such as openvz, lxc, docker, they are widely used for micro-service [1]. In this paper, we present the high availability of micro-service in containers. We investigate capabilities provided by container (docker, openvz) to model and build the Micro-service infrastructure and compare different checkpoint and restore technologies for high availability. Finally, we present preliminary performance results of the infrastructure tuned to the micro-service. Introduction Lightweight virtualization, named the operating system level virtualization technology, partitions the physical machines resource, creating multiple isolated user-space instances. Each container acts exactly like a stand-alone server. A container can be rebooted independently and have root access, users, IP address, memory, processes, files, etc. Unlike traditional virtualization with the hypervisor layer, containerization takes place at the kernel level. Most modern operating system kernels now support the primitives necessary for containerization, including Linux with openvz, vserver and more recently lxc, Solaris with zones, and FreeBSD with Jails [2].
    [Show full text]
  • Evaluating and Improving LXC Container Migration Between
    Evaluating and Improving LXC Container Migration between Cloudlets Using Multipath TCP By Yuqing Qiu A thesis submitted to the Faculty of Graduate and Postdoctoral Affairs in partial fulfillment of the requirements for the degree of Master of Applied Science in Electrical and Computer Engineering Carleton University Ottawa, Ontario © 2016, Yuqing Qiu Abstract The advent of the Cloudlet concept—a “small data center” close to users at the edge is to improve the Quality of Experience (QoE) of end users by providing resources within a one-hop distance. Many researchers have proposed using virtual machines (VMs) as such service-provisioning servers. However, seeing the potentiality of containers, this thesis adopts Linux Containers (LXC) as Cloudlet platforms. To facilitate container migration between Cloudlets, Checkpoint and Restore in Userspace (CRIU) has been chosen as the migration tool. Since the migration process goes through the Wide Area Network (WAN), which may experience network failures, the Multipath TCP (MPTCP) protocol is adopted to address the challenge. The multiple subflows established within a MPTCP connection can improve the resilience of the migration process and reduce migration time. Experimental results show that LXC containers are suitable candidates for the problem and MPTCP protocol is effective in enhancing the migration process. i Acknowledgement I would like to express my sincerest gratitude to my principal supervisor Dr. Chung-Horng Lung who has provided me with valuable guidance throughout the entire research experience. His professionalism, patience, understanding and encouragement have always been my beacons of light whenever I go through difficulties. My gratitude also goes to my co-supervisor Dr.
    [Show full text]
  • The Aurora Operating System
    The Aurora Operating System Revisiting the Single Level Store Emil Tsalapatis Ryan Hancock Tavian Barnes RCS Lab, University of Waterloo RCS Lab, University of Waterloo RCS Lab, University of Waterloo [email protected] [email protected] [email protected] Ali José Mashtizadeh RCS Lab, University of Waterloo [email protected] ABSTRACT KEYWORDS Applications on modern operating systems manage their single level stores, transparent persistence, snapshots, check- ephemeral state in memory, and persistent state on disk. En- point/restore suring consistency between them is a source of significant developer effort, yet still a source of significant bugs inma- ACM Reference Format: ture applications. We present the Aurora single level store Emil Tsalapatis, Ryan Hancock, Tavian Barnes, and Ali José Mash- (SLS), an OS that simplifies persistence by automatically per- tizadeh. 2021. The Aurora Operating System: Revisiting the Single sisting all traditionally ephemeral application state. With Level Store. In Workshop on Hot Topics in Operating Systems (HotOS recent storage hardware like NVMe SSDs and NVDIMMs, ’21), June 1-June 3, 2021, Ann Arbor, MI, USA. ACM, New York, NY, Aurora is able to continuously checkpoint entire applications USA, 8 pages. https://doi.org/10.1145/3458336.3465285 with millisecond granularity. Aurora is the first full POSIX single level store to han- dle complex applications ranging from databases to web 1 INTRODUCTION browsers. Moreover, by providing new ways to interact with Single level storage (SLS) systems provide persistence of and manipulate application state, it enables applications to applications as an operating system service. Their advantage provide features that would otherwise be prohibitively dif- lies in removing the semantic gap between the in-memory ficult to implement.
    [Show full text]
  • Checkpoint and Restore of Singularity Containers
    Universitat politecnica` de catalunya (UPC) - BarcelonaTech Facultat d'informatica` de Barcelona (FIB) Checkpoint and restore of Singularity containers Grado en ingenier´ıa informatica´ Tecnolog´ıas de la Informacion´ Memoria 25/04/2019 Director: Autor: Jordi Guitart Fernandez Enrique Serrano G´omez Departament: Arquitectura de Computadors 1 Abstract Singularity es una tecnolog´ıade contenedores software creada seg´unlas necesidades de cient´ıficos para ser utilizada en entornos de computaci´onde altas prestaciones. Hace ya 2 a~nosdesde que los usuarios empezaron a pedir una integraci´onde la fun- cionalidad de Checkpoint/Restore, con CRIU, en contenedores Singularity. Esta inte- graci´onayudar´ıaen gran medida a mejorar la gesti´onde los recursos computacionales de las m´aquinas. Permite a los usuarios guardar el estado de una aplicaci´on(ejecut´andose en un contenedor Singularity) para poder restaurarla en cualquier momento, sin perder el trabajo realizado anteriormente. Por lo que la posible interrupci´onde una aplicaci´on, debido a un fallo o voluntariamente, no es una p´erdidade tiempo de computaci´on. Este proyecto muestra como es posible realizar esa integraci´on. Singularity ´esuna tecnologia de contenidors software creada segons les necessitats de cient´ıfics,per ser utilitzada a entorns de computaci´od'altes prestacions. Fa 2 anys desde que els usuaris van comen¸cara demanar una integraci´ode la funcional- itat de Checkpoint/Restore, amb CRIU, a contenidors Singularity. Aquesta integraci´o ajudaria molt a millorar la gesti´odels recursos computacionals de les m`aquines.Permet als usuaris guardar l'estat d'una aplicaci´o(executant-se a un contenidor Singularity) per poder restaurar-la en qualsevol moment, sense perdre el treball realitzat anteriorment.
    [Show full text]
  • Debugging Mixedenvironment Programs with Blink
    SOFTWARE – PRACTICE AND EXPERIENCE Softw. Pract. Exper. (2014) Published online in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/spe.2276 Debugging mixed-environment programs with Blink Byeongcheol Lee1,*,†, Martin Hirzel2, Robert Grimm3 and Kathryn S. McKinley4 1Gwangju Institute of Science and Technology, Gwangju, Korea 2IBM, Thomas J. Watson Research Center, Yorktown Heights, NY, USA 3New York University, New York, NY, USA 4Microsoft Research, Redmond, WA, USA SUMMARY Programmers build large-scale systems with multiple languages to leverage legacy code and languages best suited to their problems. For instance, the same program may use Java for ease of programming and C to interface with the operating system. These programs pose significant debugging challenges, because programmers need to understand and control code across languages, which often execute in different envi- ronments. Unfortunately, traditional multilingual debuggers require a single execution environment. This paper presents a novel composition approach to building portable mixed-environment debuggers, in which an intermediate agent interposes on language transitions, controlling and reusing single-environment debug- gers. We implement debugger composition in Blink, a debugger for Java, C, and the Jeannie programming language. We show that Blink is (i) simple: it requires modest amounts of new code; (ii) portable: it supports multiple Java virtual machines, C compilers, operating systems, and component debuggers; and (iii) pow- erful: composition eases debugging, while supporting new mixed-language expression evaluation and Java native interface bug diagnostics. To demonstrate the generality of interposition, we build prototypes and demonstrate debugger language transitions with C for five of six other languages (Caml, Common Lisp, C#, Perl 5, Python, and Ruby) without modifications to their debuggers.
    [Show full text]
  • Multi-Threaded Programs ● Limitations ● Advanced Debugger Usage ● Adding Support for D Language ● Q and a Debugger / Program Interaction
    Tools for a New Generation ● Understanding how debuggers work boosts developers' efficiency ● Linux needs a new generation of tools ● D may lead the change Current Tools Are ... ... stuck in the 80s, yet insist upon calling themselves a “ GNU Generation” New designs should be modular, based on shared APIs. GPL is not the only way! Agenda ● Overview of debugger / program interaction ● Remote & cross-debugging: out of scope ● Fine-tunning the debug information ● Multi-threaded programs ● Limitations ● Advanced debugger usage ● Adding support for D Language ● Q and A Debugger / Program Interaction Debugger Program to debug ptrace() waitpid() /proc Kernel file-system Program Interaction ● The debugger uses the ptrace() API to: – attach / detach to / from targets – read / write to / from debugged program memory – resume execution of program ● Debugger sends signals to program – most notably SIGSTOP ● The /proc file-system allows reading / writing of memory, and provides access to other information (command line args, etc) Worse Is Better ● “ It is more important for the implementation to be simpler than the interface” Richard Gabriel, The Rise of Worse is Better ● (http://www.jwz.org/doc/worse-is-better.html) ● Example: when the debugger receives a SIGTRAP, it needs to figure what happened, on its own (could be a breakpoint, a singlestep, a system call, etc). Debug Events ● When signals occur in the program the debugger is notified (before signal is delivered) ● The status of the debugged program is collected with the waitpid() call ● The debugger
    [Show full text]
  • Instant OS Updates Via Userspace Checkpoint-And
    Instant OS Updates via Userspace Checkpoint-and-Restart Sanidhya Kashyap, Changwoo Min, Byoungyoung Lee, and Taesoo Kim, Georgia Institute of Technology; Pavel Emelyanov, CRIU and Odin, Inc. https://www.usenix.org/conference/atc16/technical-sessions/presentation/kashyap 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. Instant OS Updates via Userspace Checkpoint-and-Restart Sanidhya Kashyap Changwoo Min Byoungyoung Lee Taesoo Kim Pavel Emelyanov† Georgia Institute of Technology †CRIU & Odin, Inc. # errors # lines Abstract 50 1000K 40 100K In recent years, operating systems have become increas- 10K 30 1K 20 ingly complex and thus more prone to security and per- 100 formance issues. Accordingly, system updates to address 10 10 these issues have become more frequently available and 0 1 increasingly important. To complete such updates, users 3.13.0-x 3.16.0-x 3.19.0-x May 2014 must reboot their systems, resulting in unavoidable down- build/diff errors #layout errors Jun 2015 time and further loss of the states of running applications. #static local errors #num lines++ We present KUP, a practical OS update mechanism that Figure 1: Limitation of dynamic kernel hot-patching using employs a userspace checkpoint-and-restart mechanism, kpatch. Only two successful updates (3.13.0.32 34 and → which uses an optimized data structure for checkpoint- 3.19.0.20 21) out of 23 Ubuntu kernel package releases.
    [Show full text]
  • User's Guide Borland® Turbo Debugger
    User's Guide Borland" o User's Guide Borland® Turbo Debugger® Borland'rntemational, Inc., 100 Borland Way P.O. Box 660001, Scotts Valley, CA 95067-0001 Borland may have patents and/or pending patent applications covering subject matter, in this document. The furnishing of this document does not give you any license to these patents. COPYRIGHT © 1988, 1995 Borland International. All rights reserved. All Borland product names are trademarks or registered trademarks of Borland International, Inc. Other brand and product names are trademarks or registered trademarks of their respective holders. Printed in the U.S.A. IEORI295 9596979899-9 8 7 6 5 4 HI Contents Introduction 1 Preparing programs for debugging . 15 Compiling from the C++ integrated New features and changes for version 5.x . .2 environment. 16 New features and changes for version 4.x . .2 Compiling from Delphi . 16 Hardware requirements. .2 Compiling from the command line . 16 Terminology in this manual. .3 Starting Turbo Debugger . 17 Module ....................... 3 Specifying Turbo Debugger's command-line Function ....................... 3 options ....................... 17 Turbo Debugger . 3 Setting command-line options with Turbo Typographic and icon conventions . 3 Debugger's icon properties . 18 Using this manual . .4 Setting command-line options from Borland's C++ integrated environment. .. 18 Where to now? . .5 Launching Turbo Debugger from Delphi ... 18 First-time Turbo Debugger users . 5 Running Turbo Debugger . .... 19 Experienced Turbo Debugger users ....... 5 Loading your program into the debugger . 19 Software registration and technical support . 5 Searching for source code. 21 Chapter 1 Specifying program arguments . 21 Restarting a debugging session . 21 Installing and configuring Just-in-time debugging.
    [Show full text]
  • Task Migration at Scale Using CRIU Linux Plumbers Conference 2018
    Task Migration at Scale Using CRIU Linux Plumbers Conference 2018 Victor Marmol Andy Tucker [email protected] [email protected] 2018-11-15 Confidential + Proprietary Who we are Outside of Google, we’ve worked on open source cluster management and containers lmctfy Confidential + Proprietary 2 Who we are Inside Google: we’re part of the Borg team ● Manages all compute jobs ● Runs on every server ConfidentialImages + Proprietary by Connie Zhou3 What is Borg? Google’s cluster management system ● Borgmaster: Cluster control and main API entrypoint ● Borglet: On-machine management daemon ● Suite of tools and UIs for managing jobs ● Many purpose-built platforms created on top of Borg ● Everything runs on Borg and everything runs in containers Confidential + Proprietary 4 Borg basics Allocated Ports Base compute primitive: Task ● A priority signals how quickly a task should Processes Packages schedule Processes Packages Processes Packages ● It’s appclass describes a task as either Processes Packages serving (latency sensitive) or batch ● Static content/binaries provided by Container packages Task ● A container isolates a task’s resources ● Native Linux processes Borg Machine ● Share an IP with the machine, ports are allocated for each task Confidential + Proprietary 5 Borg basics: evictions When a task is forcefully terminated by Borg ● Typically receive a notification: 1-5min ● Our SLO allows for quite a few evictions ● Applications must handle them Reasons for evictions ● Preemption: a higher priority task needs the resources ● Software upgrades (e.g.: kernel, firmware) ● Re-balancing for availability or performance Confidential + Proprietary 6 Evictions are impactful and hard to handle Technical Complexity ● Handling evictions requires state management ○ How and what state to serialize and where to store it ● Application-specific and not very reusable Lost Compute ● Batch jobs run at lower priorities and get preempted often ● Even platforms that handle them for users, don’t do a great job Task 0 Evicted!Shard 1 Task 2 Task 3 Task 4 Compute is lost..
    [Show full text]
  • Open Source Software Packages
    Hitachi Ops Center 10.5.1 Open Source Software Packages Contact Information: Hitachi Ops Center Project Manager Hitachi Vantara LLC 2535 Augustine Drive Santa Clara, California 95054 Name of package Version License agreement @agoric/babel-parser 7.12.7 The MIT License @angular-builders/custom-webpack 8.0.0-RC.0 The MIT License @angular-devkit/build-angular 0.800.0-rc.2 The MIT License @angular-devkit/build-angular 0.901.12 The MIT License @angular-devkit/core 7.3.8 The MIT License @angular-devkit/schematics 7.3.8 The MIT License @angular/animations 9.1.11 The MIT License @angular/animations 9.1.12 The MIT License @angular/cdk 9.2.4 The MIT License @angular/cdk-experimental 9.2.4 The MIT License @angular/cli 8.0.0 The MIT License @angular/cli 9.1.11 The MIT License @angular/common 9.1.11 The MIT License @angular/common 9.1.12 The MIT License @angular/compiler 9.1.11 The MIT License @angular/compiler 9.1.12 The MIT License @angular/compiler-cli 9.1.12 The MIT License @angular/core 7.2.15 The MIT License @angular/core 9.1.11 The MIT License @angular/core 9.1.12 The MIT License @angular/forms 7.2.15 The MIT License @angular/forms 9.1.0-next.3 The MIT License @angular/forms 9.1.11 The MIT License @angular/forms 9.1.12 The MIT License @angular/language-service 9.1.12 The MIT License @angular/platform-browser 7.2.15 The MIT License @angular/platform-browser 9.1.11 The MIT License @angular/platform-browser 9.1.12 The MIT License @angular/platform-browser-dynamic 7.2.15 The MIT License @angular/platform-browser-dynamic 9.1.11 The MIT License @angular/platform-browser-dynamic
    [Show full text]
  • Red Hat Enterprise Linux 7 7.8 Release Notes
    Red Hat Enterprise Linux 7 7.8 Release Notes Release Notes for Red Hat Enterprise Linux 7.8 Last Updated: 2021-03-02 Red Hat Enterprise Linux 7 7.8 Release Notes Release Notes for Red Hat Enterprise Linux 7.8 Legal Notice Copyright © 2021 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/ . In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries. Node.js ® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
    [Show full text]
  • Seccomp Update
    seccomp update https://outflux.net/slides/2015/lss/seccomp.pdf Linux Security Summit, Seattle 2015 Kees Cook <[email protected]> (pronounced “Case”) What is seccomp? ● Programmatic kernel attack surface reduction ● Used by: – Chrome – vsftpd – OpenSSH – Systemd (“SystemCallFilter=...”) – LXC (blacklisting) – … and you too! (easiest via libseccomp) seccomp update 2/8 Linux Security Summit 2015 Seattle, Aug 21 Architecture support ● x86: v3.5 ● s390: v3.6 ● arm: v3.8 ● mips: v3.15 ● arm64: v3.19, AKASHI Takahiro ● powerpc: linux-next (v4.3), Michael Ellerman seccomp update 3/8 Linux Security Summit 2015 Seattle, Aug 21 split-phase internals ● v3.19, Andy Lutomirski ● Splits per-architecture calls to seccomp into 2 phases ● Speeds up simple (no tracing) callers ● Only used on x86 so far seccomp update 4/8 Linux Security Summit 2015 Seattle, Aug 21 Regression tests ● v4.2: moved the 48 tests from github into the kernel: tools/testing/selftests/seccomp/ ● Shows some interesting glitches with restart_syscall on arm (hidden) and arm64 (hidden, unless compat, then exposed) ● Gained big-endian support during powerpc port ● Added s390 seccomp support today seccomp update 5/8 Linux Security Summit 2015 Seattle, Aug 21 Minor changes ● v4.0: SECCOMP_RET_ERRNO capped at MAX_ERRNO – Avoid confusing userspace ● v4.1: asm-generic for seccomp.h – Easier architecture porting seccomp update 6/8 Linux Security Summit 2015 Seattle, Aug 21 Future ● Argument inspection ● CRIU (checkpoint/restore) – PTRACE_O_SUSPEND_SECCOMP with CAP_SYS_ADMIN: linux-next (v4.3), Tycho Andersen – Serialize dump/restore of filters. ● eBPF – Use maps or tail calls instead of balanced if/else trees for checking syscall numbers. seccomp update 7/8 Linux Security Summit 2015 Seattle, Aug 21 Questions? https://outflux.net/slides/2015/lss/seccomp.pdf @kees_cook [email protected] [email protected] [email protected] seccomp update 8/8 Linux Security Summit 2015 Seattle, Aug 21.
    [Show full text]