Efficient Formal Verification for the Linux Kernel

Formal verification of the Linux kernel has been receiving increasing attention in recent years, with the development of many models, from memory subsystems to the synchronization primitives of the real-time kernel. The effort in developing formal verification methods is justified considering the large code-base, the complexity in synchronization required in a monolithic kernel and the support for multiple architectures, along with the usage of Linux on critical systems, from high-frequency trading to self-driven cars. Despite recent developments in the area, none of the proposed approaches are suitable and flexible enough to be applied in an efficient way to a running kernel. Aiming to fill such a gap, this paper proposes a formal verification approach for the Linux kernel, based on automata models. It presents a method to auto-generate verification code from an automaton, which can be integrated into a module and dynamically added into the kernel for efficient on-the-fly verification of the system, using in-kernel tracing features. Finally, a set of experiments demonstrate verification of three models, along with performance analysis of the impact of the verification, in terms of latency and throughput of the system, showing the efficiency of the approach

A Stateful Approach to Generate Synthetic Events from Kernel Traces

We propose a generic synthetic event generator from kernel trace events. The proposed method makes use of patterns of system states and environment-independent semantic events rather than platform-specific raw events. This method can be applied to different kernel and user level trace formats. We use a state model to store intermediate states and events. This stateful method supports partial trace abstraction and enables users to seek and navigate through the trace events and to abstract out the desired part. Since it uses the current and previous values of the system states and has more knowledge of the underlying system execution, it can generate a wide range of synthetic events. One of the obvious applications of this method is the identification of system faults and problems that will appear later in this paper. We will discuss the architecture of the method, its implementation, and the performance results

Demystifying the Real-Time Linux Scheduling Latency

Linux has become a viable operating system for many real-time workloads. However, the black-box approach adopted by cyclictest, the tool used to evaluate the main real-time metric of the kernel, the scheduling latency, along with the absence of a theoretically-sound description of the in-kernel behavior, sheds some doubts about Linux meriting the real-time adjective. Aiming at clarifying the PREEMPT_RT Linux scheduling latency, this paper leverages the Thread Synchronization Model of Linux to derive a set of properties and rules defining the Linux kernel behavior from a scheduling perspective. These rules are then leveraged to derive a sound bound to the scheduling latency, considering all the sources of delays occurring in all possible sequences of synchronization events in the kernel. This paper also presents a tracing method, efficient in time and memory overheads, to observe the kernel events needed to define the variables used in the analysis. This results in an easy-to-use tool for deriving reliable scheduling latency bounds that can be used in practice. Finally, an experimental analysis compares the cyclictest and the proposed tool, showing that the proposed method can find sound bounds faster with acceptable overheads

A thread synchronization model for the PREEMPT_RT Linux kernel

This article proposes an automata-based model for describing and validating sequences of kernel events in Linux PREEMPT_RT and how they influence the timeline of threads’ execution, comprising preemption control, interrupt handling and control, scheduling and locking. This article also presents an extension of the Linux tracing framework that enables the tracing of kernel events to verify the consistency of the kernel execution compared to the event sequences that are legal according to the formal model. This enables cross-checking of a kernel behavior against the formalized one, and in case of inconsistency, it pinpoints possible areas of improvement of the kernel, useful for regression testing. Indeed, we describe in details three problems in the kernel revealed by using the proposed technique, along with a short summary on how we reported and proposed fixes to the Linux kernel community. As an example of the usage of the model, the analysis of the events involved in the activation of the highest priority thread is presented, describing the delays occurred in this operation in the same granularity used by kernel developers. This illustrates how it is possible to take advantage of the model for analyzing the preemption model of Linux

A declarative framework for stateful analysis of execution traces

With newer complex multi-core systems, it is important to understand applications’ run-time behaviour to be able to debug their executions, detect possible problems and bottlenecks and finally identify potential root-causes. Execution traces usually contain precise data about applications’ execution, with which analysis and abstraction at multiple levels, they can provide valuable information and insights about the applications’run-time behaviour. However, with multiple abstraction levels, it becomes increasingly difficult to find the exact location of detected performance or security problem. Tracing tools provide various analysis views to help understand these problems. However, these views are not somehow enough to uncover all aspects of the underlying issues. The developer is in fact the one who best knows his application. Therefore, a declarative approach that enables users to specify and build their custom analysis based on their knowledge, requirements and problems can be more useful and effective. In this paper we propose a generic declarative trace analysis framework to analyze, comprehend and visualize execution traces. This enhanced framework builds custom analysis based on a specified modelled state, extracted from a system execution trace and stored in a special purpose database. The proposed solution enables users to first define their different analysis models based on their application and requirements, then visualize these models in many alternate representations (Gantt chart, XY chart, etc.), and finally filter the data to get some highlights or detect some potential patterns. Several sample applications with different operating systems are shown using trace events gathered from Linux and Windows kernel and user-space levels

Detection of Common Problems in Real-Time and Multicore Systems Using Model-Based Constraints

Multicore systems are complex in that multiple processes are running concurrently and can interfere with each other. Real-time systems add on top of that time constraints, making results invalid as soon as a deadline has been missed. Tracing is often the most reliable and accurate tool available to study and understand those systems. However, tracing requires that users understand the kernel events and their meaning. It is therefore not very accessible. Using modeling to generate source code or represent applications’ workflow is handy for developers and has emerged as part of the model-driven development methodology. In this paper, we propose a new approach to system analysis using model-based constraints, on top of userspace and kernel traces. We introduce the constraints representation and how traces can be used to follow the application’s workflow and check the constraints we set on the model. We then present a number of common problems that we encountered in real-time and multicore systems and describe how our model-based constraints could have helped to save time by automatically identifying the unwanted behavior

Conception flexible d'analyses issues d'une trace système

Résumé Les logiciels deviennent de plus en plus complexes. Avec l'avènement de l'informatique embarquée, la limitation des ressources les contraint à s'exécuter en économisant le temps, la mémoire et l'énergie. Dans ce contexte, les développeurs ont besoin d'outils pour déboguer et optimiser les programmes qu'ils écrivent. Parmi ces outils, le traçage est une solution particulièrement adaptée qui enregistre l'occurrence d'événements, en interagissant peu avec l'exécution. Elle permet de mettre en évidence les causes de bogues ou les goulots d'étranglement qui ralentissent le programme. LTTng est un traceur focalisé sur les performances : grâce à des structures de données propres à chaque coeur et à des verrous non-bloquants, l'enregistrement d'un événement prend moins d'une microseconde sur une machine récente. Ce délai est toutefois nonnégligeable, il empêche de tracer un nombre arbitraire de points sans affecter les performances. De plus, le code et les données liées au traçage sont stockés dans l'espace mémoire du processus étudié, ce qui cause un impact sur son exécution. L'utilisation de blocs matériels dédiés au débogage pallie à ces limitations. Il existe une multitude de ces circuits, présents sur la plupart des processeurs du marché, à des fins de débogage et de profilage. En réutilisant leurs capacités à des fins de traçage, nous proposons de soulager la partie logicielle d'outils comme LTTng, et ainsi d'accroître leurs performances. Pour ce faire, nous utilisons les modules matériels STM, ETM et ETB de la suite CoreSight sur les processeurs ARM,ainsi que BTS sur les processeurs x86 d'Intel. Certains offrent une fonctionnalité de traçage d'exécution, c'est-à-dire d'enregistrement de la liste des instructions exécutées ; d'autres fournissent des ressources spécialisées pour l'estampillage de temps, l'envoi de messages sur des canaux dédiés, et le stockage de traces. Dans ce mémoire, nous proposons des implémentations de traçage logiciel s'aidant du matériel pour être moins intrusifs que les outils purement logiciels. Nous visons à réduire le surcoût en temps engendré par le traçage, c'est-à-dire le nombre de cycles ajoutés à une exécution normale, tout en gardant le même détail d'information que fournit une trace. Nous montrons que l'utilisation conjointe des modules STM et ETB pour faire transiter les traces par des circuits matériels dédiés économise la mémoire du processus et que la durée des points de trace est divisée par dix par rapport à LTTng. En utilisant ETM et ETB, le surcoût du traçage est lui aussi réduit : entre -30% et -50% par rapport à notre traceur de référence. En revanche, les capacités du traceur d'exécution ETM limitent notre système à seulement quelques points de trace enregistrables dans tout le programme. Finalement, l'utilisation de BTS sur les processeurs Intel est aussi plus efficace : les points de trace sont presque deux fois plus rapides que ceux de LTTng. Cependant, ce système ne permet pas de choisir quels événements tracer : tous les branchements pris par le processeur sont enregistrés. Cette lourdeur rend BTS inutilisable pour faire du traçage d'événements ; néanmoins pour du traçage d'exécution, la ré-implémentation que nous proposons est 65% plus rapide que celle de Perf, l'outil par défaut sous Linux.---------Abstract Software is becoming increasingly complex. With the advent of embedded computing, resource limitations force it to run in a way saving time, memory and energy. In this context, developers need tools to debug and optimize the programs they write. Among these tools, tracing is a particularly well suited solution that records the occurrence of events, while minimally interacting with the execution. It allows to identify the causes of bugs or bottlenecks that slow down the program. LTTng is a tracer focused on performance: through per-core data structures and nonblocking locks, recording an event takes less than one microsecond on a typical computer. However, this delay is not negligible, and tracing an arbitrary number of points is not possible without affecting performance. In addition, the code and data related to tracing are stored in the memory space of the process being studied, causing an impact on its execution. The use of dedicated debug hardware blocks overcomes these limitations. There are a multitude of these circuits, present on most processors on the market, for of debugging and profiling purposes. By reusing their capacity for tracing purposes, we propose to alleviate the software part of tracing tools such as LTTng, and thereby increase their performance. To do this, we use STM, ETM and ETB hardware modules from the CoreSight suite on ARM processors, as well as BTS on Intel x86 processors. Some offer an execution tracing feature, i.e. recording the list of executed instructions; others provide specialized resources for timestamping, transfering messages on dedicated channels, and storing traces. In this thesis, we propose implementations of software tracing that take advantage of hardware to be less intrusive than pure-software tools. We aim to reduce the time overhead induced by tracing, i.e. the number of cycles added to a normal execution, while keeping the same detailed information as a trace provides. We show that the combined use of STM and ETB modules to send traces through dedicated hardware circuits saves process memory and that each tracepoint duration is divided by ten as compared to LTTng. Using ETM and ETB, the overhead of tracing is also reduced: between -30% and -50% as compared to our reference tracer. However, the capacity of the ETM execution tracer limits our system to only a few recordable tracepoints throughout the program. Finally, the use of BTS on Intel processors is also more efficient: tracepoints are almost two times faster than LTTng. However, it is not possible to choose which events to trace with this system: all branches taken by the processor are stored. This limitation makes BTS unusable for event tracing; however, for execution tracing the re-implementation we offer is 65% faster than Perf, the default tool on Linux

Méthodes efficaces de parallélisation de l'analyse de traces noyau

RÉSUMÉ Les architectures hautement parallèles sont de plus en plus répandues, non seulement dans les systèmes haute-performance, mais aussi dans les ordinateurs grand public. La détection et la résolution de problèmes lors de l’exécution parallèle de logiciels sur ces types de systèmes sont des tâches complexes auxquelles les outils classiques de débogage ne sont pas adaptés. Des études précédentes ont démontré que le traçage s’avère être une solution efficace à la résolution de problèmes dans des systèmes hautement parallèles. Cependant, l’augmentation du nombre d’unités parallèles dans les systèmes tracés cause aussi une augmentation de la quantité de données générées par le traçage. Les architectures distribuées ne font qu’exacerber ce problème puisque chaque nœud peut contenir plusieurs processeurs multicœurs. Les données de trace doivent être analysées par un outil d’analyse de traces afin de pouvoir extraire les métriques importantes qui permettront de résoudre les problèmes. Or, les outils d’analyse de traces disponibles sont conçus de manière à s’exécuter séquentiellement, sans tirer avantage des capacités d’exécution parallèle. Nous nous retrouvons donc face à une différence de plus en plus grande entre la quantité de données produite par le traçage et la vitesse à laquelle ces données peuvent être analysées. La présente recherche a pour but d’explorer l’utilisation du calcul parallèle afin d’accélérer l’analyse de traces. Nous proposons une méthode efficace de parallélisation de l’analyse de traces qui supporte la mise à l’échelle. Nous nous concentrons sur les traces en format CTF générées par le traceur LTTng sur Linux. La solution présentée prend en compte des facteurs clés de la parallélisation efficace, notamment un bon équilibrage de la charge, un minimum de synchronisation et une résolution efficace des dépendances de données. Notre solution se base sur des aspects clés du format de trace CTF afin de créer des charges de travail équilibrées et facilement parallélisables. Nous proposons aussi un algorithme permettant la détection et la résolution de dépendances de données, pendant l’analyse de traces, qui utilise au minimum le verrouillage et la synchronisation entre les fils d’exécution. Nous implémentons trois analyses de traces parallèles à l’aide de cette solution : la première permet de compter les événements d’une trace, la seconde de mesurer le temps CPU utilisé par processus et la troisième de mesurer la quantité de données lues et écrites par processus. Nous utilisons ces analyses afin de mesurer la mise à l’échelle possible de notre solution, en utilisant le concept d’efficacité parallèle. Puisque les traces peuvent être potentiellement très volumineuses, elles ne peuvent être gardées en mémoire et sont donc lues à partir du disque. Afin d’évaluer l’impact de la performance des périphériques de stockages sur notre implémentation parallèle, nous utilisons un programme simulant des charges de travail sur le CPU et sur le disque, typiques de l’analyse de traces. Nous évaluons ensuite la performance de ce programme sur plusieurs types de périphériques de stockage, tels que des disques durs et des disques SSD, afin de démontrer que la performance de l’analyse parallèle de traces n’est pas gravement limitée par les accès au disque, surtout avec des périphériques de stockage modernes. Nous utilisons aussi ce programme afin d’évaluer l’effet d’améliorations futures au décodage de la trace, sur la mise à l’échelle de l’analyse parallèle. Notre solution offre une efficacité parallèle au-dessus de 56% jusqu’à 32 cœurs, lors de l’exécution de l’analyse de traces parallèle, ce qui signifie une accélération de 18 fois par rapport au temps de traitement séquentiel. De plus, les résultats de performance obtenus à partir du programme de simulation confirment que l’efficacité parallèle n’est pas sérieusement affectée par les accès au disque lorsque des périphériques de type SSD sont utilisés. Cette observation tient d’ailleurs même lorsque le décodage de la trace est plus rapide. Certains facteurs qui nuisent à la mise à l’échelle sont dus au modèle séquentiel de la bibliothèque de lecture de traces et peuvent être réglés avec une refonte de celle-ci, tandis que d’autres proviennent de goulots d’étranglement au sein du module de gestion de la mémoire du noyau et pourraient être améliorés ou contournés.----------ABSTRACT Highly parallel computer architectures are now increasingly commonplace, whether in com- mercial or consumer-grade systems. Detecting and solving runtime problems, in software running in a parallel environment, is a complicated task, where classic debugging tools are of little help. Previous research has shown that tracing offers an efficient and scalable way to resolve these problems. However, as the number of parallel units in the traced system increases, so does the amount of data generated in the trace. This problem also compounds when tracing distributed systems, where each individual node may have many-core processors. Trace data has to be analyzed by a trace analysis tool, in order to extract significant metrics which can be used to resolve problems. However, the current trace analysis tools are designed for serial analysis on a single thread. We therefore have an ever widening gap between the amount of data produced in the trace and the speed at which we can analyse this data. This research explores the use of parallel processing in order to accelerate trace analysis. The aim is to develop an efficient and scalable parallel method for analyzing traces. We focus on traces in the CTF format, generated by the LTTng tracer on Linux. We present a solution which takes into account key factors of parallelization, such as good load balancing, low synchronization overhead and an efficient resolution of data dependencies. Our solution uses key aspects of the CTF trace format to create balanced, parallelizable workloads. We also propose an algorithm to detect and resolve data dependencies during trace analysis, with minimal locking and synchronization. Using this solution, we implement three trace analyses (counting events; measuring CPU time per-process; measuring amount of data read and written per-process) which we use in order to assess the scalability in terms of parallel efficiency. Traces, being potentially very large, are not kept entirely in memory and must be read from disk. In order to assess the effect of the speed of storage devices on the parallel implementation of trace analysis, we create a program that simulates the CPU and I/O workloads typical of trace analysis. We then benchmark this program on various storage devices (e.g. HDD, SSD, etc.) in order to show that parallel trace analysis is not seriously hindered by I/O-boundedness problems, especially with modern storage hardware. We also use this program in order to assess the effect of future improvements in trace decoding on the analysis. Our solution shows parallel efficiency above 56% up to 32 cores, when running the parallel trace analyses, which translates to a speedup of 18 times the serial speed. Furthermore, benchmarks on the simulation program confirm that these efficiencies are not seriously affected by disk I/O on solid state devices, even in the case of faster trace decoding. Some factors affecting scalability are found within the serial design of the tracing library and can be fixed by a re-design, while others come from bottlenecks within the memory management unit of the kernel which could be improved or worked around

Software Tracing Comparison Using Data Mining Techniques

La performance est devenue une question cruciale sur le développement, le test et la maintenance des logiciels. Pour répondre à cette préoccupation, les développeurs et les testeurs utilisent plusieurs outils pour améliorer les performances ou suivre les bogues liés à la performance. L’utilisation de méthodologies comparatives telles que Flame Graphs fournit un moyen formel de vérifier les causes des régressions et des problèmes de performance. L’outil de comparaison fournit des informations pour l’analyse qui peuvent être utilisées pour les améliorer par un mécanisme de profilage profond, comparant habituellement une donnée normale avec un profil anormal. D’autre part, le mécanisme de traçage est un mécanisme de tendance visant à enregistrer des événements dans le système et à réduire les frais généraux de son utilisation. Le registre de cette information peut être utilisé pour fournir aux développeurs des données pour l’analyse de performance. Cependant, la quantité de données fournies et les connaissances requises à comprendre peuvent constituer un défi pour les méthodes et les outils d’analyse actuels. La combinaison des deux méthodologies, un mécanisme comparatif de profilage et un système de traçabilité peu élevé peut permettre d’évaluer les causes des problèmes répondant également à des exigences de performance strictes en même temps. La prochaine étape consiste à utiliser ces données pour développer des méthodes d’analyse des causes profondes et d’identification des goulets d’étranglement. L’objectif de ce recherche est d’automatiser le processus d’analyse des traces et d’identifier automatiquement les différences entre les groupes d’exécutions. La solution présentée souligne les différences dans les groupes présentant une cause possible de cette différence, l’utilisateur peut alors bénéficier de cette revendication pour améliorer les exécutions. Nous présentons une série de techniques automatisées qui peuvent être utilisées pour trouver les causes profondes des variations de performance et nécessitant des interférences mineures ou non humaines. L’approche principale est capable d’indiquer la performance en utilisant une méthodologie de regroupement comparative sur les exécutions et a été appliquée sur des cas d’utilisation réelle. La solution proposée a été mise en oeuvre sur un cadre d’analyse pour aider les développeurs à résoudre des problèmes similaires avec un outil différentiel de flamme. À notre connaissance, il s’agit de la première tentative de corréler les mécanismes de regroupement automatique avec l’analyse des causes racines à l’aide des données de suivi. Dans ce projet, la plupart des données utilisées pour les évaluations et les expériences ont été effectuées dans le système d’exploitation Linux et ont été menées à l’aide de Linux Trace Toolkit Next Generation (LTTng) qui est un outil très flexible avec de faibles coûts généraux.----------ABSTRACT: Performance has become a crucial matter in software development, testing and maintenance. To address this concern, developers and testers use several tools to improve the performance or track performance related bugs. The use of comparative methodologies such as Flame Graphs provides a formal way to verify causes of regressions and performance issues. The comparison tool provides information for analysis that can be used to improve the study by a deep profiling mechanism, usually comparing normal with abnormal profiling data. On the other hand, Tracing is a popular mechanism, targeting to record events in the system and to reduce the overhead associated with its utilization. The record of this information can be used to supply developers with data for performance analysis. However, the amount of data provided, and the required knowledge to understand it, may present a challenge for the current analysis methods and tools. Combining both methodologies, a comparative mechanism for profiling and a low overhead trace system, can enable the easier evaluation of issues and underlying causes, also meeting stringent performance requirements at the same time. The next step is to use this data to develop methods for root cause analysis and bottleneck identification. The objective of this research project is to automate the process of trace analysis and automatic identification of differences among groups of executions. The presented solution highlights differences in the groups, presenting a possible cause for any difference. The user can then benefit from this claim to improve the executions. We present a series of automated techniques that can be used to find the root causes of performance variations, while requiring small or no human intervention. The main approach is capable to identify the performance difference cause using a comparative grouping methodology on the executions, and was applied to real use cases. The proposed solution was implemented on an analysis framework to help developers with similar problems, together with a differential flame graph tool. To our knowledge, this is the first attempt to correlate automatic grouping mechanisms with root cause analysis using tracing data. In this project, most of the data used for evaluations and experiments were done with the Linux Operating System and were conducted using the Linux Trace Toolkit Next Generation (LTTng), which is a very flexible tool with low overhead

Analyse détaillée de trace en dépit d'événements manquants

Le traçage offre une compréhension détaillée du fonctionnement d’un système ou d’une application, mais la simple étude d’une trace ne permet pas d’exploiter tout le potentiel des informations contenues dans les événements qui la constituent. C’est pour cela que les spécialistes des systèmes distribués et de l’analyse de performance développent des analyses complexes, qui sont ensuite intégrées aux outils de visualisation de traces. Ces outils supposent que le processus de traçage s’est déroulé sans erreurs. Néanmoins, il arrive que des événements soient perdus. Ceci survient lorsque les structures de données (souvent des tampons circulaires) devant stocker les événements avant leur écriture dans la trace sur disque sont pleins, alors que d’autres événements sont générés. Pour éviter de bloquer le système, le traceur doit jeter les événements les plus récents, ou écraser les plus anciens. Il n’existe pas de mécanisme pour gérer ce cas lors de l’analyse de trace, ce qui crée des incohérences dans les résultats sans que l’utilisateur en soit notifié. L’objectif de cette recherche est donc d’étudier le problème des événements perdus dans une trace lors de son analyse, et d’apporter des solutions permettant d’indiquer les incohérences et d’y remédier. Notre hypothèse était que les événements présents dans la trace contiennent suffisament d’information pour pouvoir détecter un changement d’état qui n’aurait pas dû avoir lieu, et pour compléter la chronologie manquante. Pour cela, nous avons utilisé des machines à états finis, puisque ce formalisme de représentation permet de modéliser le système étudié, en définissant la façon dont les événements génèrent des changements d’états. Ces machines à états possèdent des propriétés qui peuvent être exploitées pour retrouver les informations perdues.----------ABSTRACT: With tracing, a lot of information can be gathered from a system or an application. This information needs to be exploited in order to provide a useful insight into the operation of our system. Experts develop complex trace analyses, but it does not take into account the fact that some events may have been lost during the tracing process, due to a much bigger flow of generated events than the capacity of writing into the trace. Therefore, the results may contain some inconsistencies. Our objective is to deal with these lost events at the trace analysis level. Using finite state machines to model the system, we are able to check the certainty of each new state. If no transition can be triggered from the current state, we check if one could be triggered from another state. By doing so, we can find inconsistencies. Then, we can correct these by looking for the sequence of transitions between the last coherent state and the incoherent one. Dijkstra’s shortest-path algorithm is applied, with frequencies used as weights for the transitions. Once the transitions have been inferred, we can deduce the related lost events and their content. The proposed solution has been implemented in Trace Compass, a trace visualisation tool. The new information is displayed on the view representing the results of the analysis. It allowed us to apply our method to a few usecases, thus demonstrating its usefulness. The accuracy of the recovery phase is 53%. The overhead of the detection phase is reasonable for small traces, but can increase rapidly for bigger ones. However, the inference phase does not cost too much in any case