Academic literature on the topic 'Linux (Système d'exploitation des ordinateurs)'

L'évolution des sous systèmes de stockage et plus particulièrement des disques a été considérable ces dernières années. Cependant, l'écart de performance entre ces dernièrs et les processeurs ne cesse de se creuser. Il est donc essentiel de bien choisir les ressources de stockage secondaire et de les utiliser d'une manière optimale. Pour y parvenir, une compréhension complète du fonctionnement logiciel et matériel des systèmes de stockage ainsi que des interactions entre les différents modules de ce système est indispensable. Nous nous sommes intéressés dans cette thèse à la mesure et à l'analyse des performances, ainsi qu'à la simulation de l'architecture de stockage sur PC. Nous étudions en particulier les systèmes d'E/S sous Windows ou plus exactement les mécanismes d'accès aux fichiers. L'utilisation de certains paramètres dans la fonction d'ouverture et de création de fichiers CreateFile sous Windows détermine la manière avec laquelle se fera l'accès aux fichiers. Le choix d'une stratégie de lecture par anticipation, d'algorithmes d'écriture retardée, de la taille des blocs systèmes ainsi que d'autres paramètres se fait par le système d'après le paramétrage de cette même fonction. Il est donc important de connaître et de comprendre l'influence de ces choix sur les performances des E/S qui sont bien sûr relatives à la charge de travail imposée au système. Le travail effectué dans le cadre de cette thèse consiste à d'abord trouver un moyen efficace de mesure de performance spécifique à Windows, c'est-à-dire que l'on prend en compte les paramètres spécifiques à la fonction CreateFile ainsi que les tailles de requêtes. En effet, nous avons remarqué des fluctuations de performance très importantes selon la stratégie d'accès aux fichiers choisie. Nous avons par la suite développé une méthodologie d'analyse des systèmes de stockage sous Windows grâce à laquelle nous avons identifié les différents paramètres de stockage aidant à la compréhension des performances obtenues. C'est l'analyse des temps de réponse qui a permis cette compréhension. En effet, nous avons remarqué une périodicité des temps de réponse dans le cas des accès à des blocs stockés séquentiellement sur le disque, c'est ce qui nous a permis de commencer l'analyse. Une fois cette analyse effectuée, un simulateur comportemental du système de stockage de Windows a été développé. Il permet entre autres d'évaluer les performances d'une charge de travail sur une architecture donnée pour qu'un utilisateur puisse décider de la stratégie d'accès aux fichiers la plus efficace à adopter avant l'implémentation de son application<br>The evolution of storage subsystems and more particularly disks was considerable this last decade. However, the performance gap between secondary storage and processor is still increasing. It is therefore crucial to well choose the storage subsystem and to know how to use it in an optimal way. In order to resolve this problem, a complete understanding of the software and hardware behaviours of storage systems as well as the interactions between the different modules of the I/O system is required. We are interested in this thesis in the benchmarking, the performance analysis and the simulation of the storage architecture on PCs. We are particularly studying the I/O system under Windows and the file access mechanisms. The use of some parameters in the file opening and creation function CreateFile under Windows decides on the way files are accessed. The choice of a read ahead algorithm, a lazy write strategy, the system data block size and other parameters is done by the system and depends on those function parameters. It is thus very important to understand the impact of those choices on the I/O performance of the system that are of course relative to the injected workload. The realized work consists of finding at first an efficient way to measure the specific Windows storage system performance depending on the parameters like those specified in the CreateFile function and request sizes. We have noticed very important performance fluctuations relative to the file access strategy used. We have then developed a methodology to analyse Windows storage systems. We have identified thanks to this methodology different parameters that helped us to understand the performance fluctuations we obtained. It is the response time analysis step that allowed this understanding. We observed that response times are periodic when the accessed blocks were stored sequentially on the disk, that was the starting point of our analysis. Once the performance study and analysis done, a behavioral simulator of the Windows storage system has been developed. It allows for instance the performance evaluation of a given workload on defined storage architecture for a user to decide of the most effective access strategy to adopt before implementing his application

Le déploiement et l'exécution d'applications dans le cloud sont aujourd'hui une réalité. L'existence de celui-ci est intrinsèquement liée à celle de la virtualisation. Ce concept consiste à découper une machine physique en plusieurs sous-machines, dites machines virtuelles, isolées les unes des autres. Plus récemment, les conteneurs se sont posés comme une alternative viable aux machines virtuelles. Les conteneurs sont plus légers que ces dernières et apportent les mêmes garanties d'isolation et de sécurité. Néanmoins, l'isolation, un conteneur ne peut affamer ses congénères, proposée est peut-être trop poussée. En effet, les mécanismes existants permettant l'isolation mémoire ne s'adaptent pas aux changements de charge de travail. Il n'est donc pas possible de consolider la mémoire, c'est-à-dire récupérer la mémoire inutilisée d'un conteneur pour en faire un meilleur usage. Pour répondre à ce problème et garantir, à la fois, l'isolation et la consolidation mémoire, nous proposons MemOpLight. Ce mécanisme s'adapte aux changements de charge de travail grâce à un retour applicatif. Chaque conteneur indique donc s'il a de bonnes performances pour guider la répartition de la mémoire. Celle-ci est récupérée aux conteneurs ayant de bonnes performances pour que les autres conteneurs puissent augmenter celles-ci. L'idée étant de trouver un équilibre mémoire où tous les conteneurs ont des performances satisfaisantes. MemOpLight permet d'augmenter la satisfaction des conteneurs de 13% comparé aux mécanismes existants<br>Nowadays, deploying and executing applications in the cloud is a reality. The cloud can not exist without virtualization. This concept consists of slicing physical machines into several sub-machines, isolated from one another, known as virtual machines. Recently, containers emerged as a viable alternative to virtual machines. Containers are lighter than virtual machines and bring the same isolation and security guarantees. Nonetheless, the isolation they offer is maybe too important. Indeed, existing mechanisms enforce memory isolation by ensuring that no container starves the others; however, they do not adapt to changes in workload. Thus, it is impossible to consolidate memory, i.e. to reclaim memory unused by some containers to make a better use of it. To answer this problem and ensure both isolation and consolidation, we introduce MemOpLight. This mechanism adapts to workload changes thanks to application feedback. Each container tells the kernel whether it has good or bad performance to guide memory reclaim. Memory is first reclaimed from containers with good performance in the hope that the others can improve their own performance. The idea is to find a balance where all containers have satisfying performance. MemOpLight increases container satisfactions by 13% compared to existing mechanisms

Nous cherchons à améliorer l'état de l'art des implémentations de contrôle de flux d'information dans les systèmes Linux. Le contrôle de flux d'information vise à surveiller la façon dont l'information se dissémine dans le système une fois hors de son conteneur d'origine, contrairement au contrôle d'accès qui ne peut permettre d'appliquer des règles que sur la manière dont les conteneurs sont accédés. Plusieurs défis scientifiques et techniques se sont présentés. Premièrement, la base de code Linux est particulièrement grande, avec quinze millions de lignes de code réparties dans trente-mille fichiers. La première contribution de cette thèse a été un plugin pour le compilateur GCC permettant d'extraire et visualiser aisément les graphes de flot de contrôle des fonctions du noyau. Ensuite, le framework des Linux Security Modules qui est utilisé pour implémenter les moniteurs de flux d'information que nous avons étudiés (Laminar [1], KBlare [2] et Weir [3]) a été conçu en premier lieu pour le contrôle d'accès, et non de flux. La question se pose donc de savoir si le framework est implémenté de telle sorte à permettre la capture de tous les flux produits par les appels système. Nous avons créé et implémenté une analyse statique permettant de répondre à ce problème. Cette analyse statique est implémenté en tant que plugin GCC et nous a permis d'améliorer le framework LSM pour capturer tous les flux. Enfin, nous avons constaté que les moniteurs de flux actuels n'étaient pas résistants aux conditions de concurrence entre les flux et ne pouvaient pas traiter certains canaux ouverts tels que les projections de fichiers en mémoire et les segments de mémoire partagée entre processus. Nous avons implémenté Rfblare, un nouvel algorithme de suivi de flux, pour KBlare, dont nous avons prouvé la correction avec Coq. Nous avons ainsi montré que LSM pouvait être utilisé avec succès pour implémenter le contrôle de flux d'information, et que seules les méthodes formelles, permettant la mise en œuvre de méthodologie, d'analyses ou d'outils réutilisables, permettaient de s'attaquer à la complexité et aux rapides évolutions du noyau Linux<br>We look forward to improving the implementations of information flow control mechanisms in Linux Operating Systems. Information Flow Control aims at monitoring how information disseminates in a system once it is out of its original container, unlike access control which can merely apply rule on how the containers are accessed. We met several scientific and technical challenges. First of all, the Linux codebase is big, over fifteen millions lines of code spread over thirty three thousand files. The first contribution of this thesis is a plugin for the GCC compiler able to extract and let a user easily visualize the control flow graphs of the Linux kernel functions. Secondly, the Linux Security Modules framework which is used to implement the information flow trackers we have reviewed (Laminar, KBlare, and Weir) was designed in the first place to implement access control, rather than information flow control. One issue is thus left open: is the framework implemented in such a way that all flows generated by system calls can be captured? We have created and implemented static analysis to address this problem and proved its correction with the Coq proof assistant system. This analysis is implemented as a GCC plugin and have allowed us to improve the LSM framework in order to capture all flows. Finally, we have noted that current information flow trackers are vulnerable to race conditions between flows and are unable to cover some overt channels of information such as files mapping to memory and shared memory segments between processes. We have implemented Rfblare, a new algorithm of flow tracking, for KBlare. The correction of this algorithm has been proved with Coq. We have showed that LSM can be used successfully to implement information flow control, and that only formal methods, leading to reusable methodology, analysis, tools, etc., are a match for the complexity and the fast-paced evolution of the Linux kernel

Le marché des passerelles domestiques évolue vers un nouveau modèle économique, où de multiples acteurs sont amenés à fournir des services vers nos domiciles : multimédia à la demande, domotique, télésécurité, aide aux personnes âgées ou handicapées\ldots<br /><br />Ce nouveau modèle économique a des répercussions techniques sur les passerelles domestiques. Ces équipements à ressources limitées doivent alors supporter le déploiement, l'exécution et la gestion de plusieurs éléments logiciels (modules), en provenance de fournisseurs différents. Ceci se traduit par des besoins en terme d'isolation d'exécution locale, de gestion à distance, d'infrastructure de déploiement et de modèle de programmation.<br /><br />Dans ces travaux, nous proposons de répondre à ces quatre familles de besoins en nous appuyant sur deux types d'environnements d'exécution : Java/OSGi et C/Linux.<br /><br />Nous proposons de combler les fonctionnalités manquantes à ces deux environnements, afin d'obtenir un système conforme au modèle multi-services.

Lorsqu'une erreur survient dans le noyau Linux, celui-ci émet un rapport d’erreur appelé "kernel oops" contenant le contexte d’exécution de cette erreur. Les kernel oops décrivent des erreurs réelles de Linux, permettent de classer les efforts de débogage par ordre de priorité et de motiver la conception d’outils permettant d'améliorer la fiabilité du code de Linux. Néanmoins, les informations contenues dans un kernel oops n’ont de sens que si elles sont représentatives et qu'elles peuvent être interprétées correctement. Dans cette thèse, nous étudions une collection de kernel oops provenant d'un dépôt maintenu par Red Hat sur une période de huit mois. Nous considérons l’ensemble des caractéristiques de ces données, dans quelle mesure ces données reflètent d’autres informations à propos de Linux et l’interprétation des caractéristiques pouvant être pertinentes pour la fiabilité de Linux. Nous constatons que ces données sont bien corrélées à d’autres informations à propos de Linux, cependant, elles souffrent parfois de problèmes de duplication et de manque d’informations. Nous identifions également quelques pièges potentiels lors de l'étude des fonctionnalités, telles que les causes d'erreurs fréquentes et les causes d'applications défaillant fréquemment. En outre, un kernel oops fournit des informations précieuses et de première main pour un mainteneur du noyau Linux lui permettant d'effectuer le débogage post-mortem car il enregistre l’état du noyau Linux au moment du crash. Cependant, le débogage sur la seule base des informations contenues dans un kernel oops est difficile. Pour aider les développeurs avec le débogage, nous avons conçu une solution afin d'obtenir la ligne fautive à partir d’un kernel oops, i.e., la ligne du code source qui provoque l'erreur. Pour cela, nous proposons un nouvel algorithme basé sur la correspondance de séquences approximative utilisé dans le domaine de bioinformatique. Cet algorithme permet de localiser automatiquement la ligne fautive en se basant sur le code machine à proximité de celle-ci et inclus dans un kernel oops. Notre algorithme atteint 92% de précision comparé à 26 % pour l’approche traditionnelle utilisant le débogueur gdb. Nous avons intégré notre solution dans un outil nommé OOPSA qui peut ainsi alléger le fardeau pour les développeurs lors du débogage de kernel oops<br>When a failure occurs in the Linux kernel, the kernel emits an error report called “kernel oops”, summarizing the execution context of the failure. Kernel oopses describe real Linux errors, and thus can help prioritize debugging efforts and motivate the design of tools to improve the reliability of Linux code. Nevertheless, the information is only meaningful if it is representative and can be interpreted correctly. In this thesis, we study a collection of kernel oopses over a period of 8 months from a repository that is maintained by Red Hat. We consider the overall features of the data, the degree to which the data reflects other information about Linux, and the interpretation of features that may be relevant to reliability. We find that the data correlates well with other information about Linux, but that it suffers from duplicate and missing information. We furthermore identify some potential pitfalls in studying features such as the sources of common faults and common failing applications. Furthermore, a kernel oops provides valuable first-hand information for a Linux kernel maintainer to conduct postmortem debugging, since it logs the status of the Linux kernel at the time of a crash. However, debugging based on only the information in a kernel oops is difficult. To help developers with debugging, we devised a solution to derive the offending line from a kernel oops, i.e., the line of source code that incurs the crash. For this, we propose a novel algorithm based on approximate sequence matching, as used in bioinformatics, to automatically pinpoint the offending line based on information about nearby machine-code instructions, as found in a kernel oops. Our algorithm achieves 92% accuracy compared to 26% for the traditional approach of using only the oops instruction pointer. We integrated the solution into a tool named OOPSA, which would relieve some burden for the developers with the kernel oops debugging

Les travaux présentés dans ce mémoire possèdent un double objectif. Nous nous intéressons, dans un premier temps, à la définition d'un cadre conceptuel d'étalonnage de la sûreté de fonctionnement des systèmes informatiques, basé sur les techniques d'évaluation analytique et expérimentale de la sûreté de fonctionnement. Le but d'un étalon de sûreté de fonctionnement est de fournir un moyen générique pour la caractérisation du comportement des systèmes informatiques en présence de fautes, permettant ainsi la quantification de mesures de sûreté de fonctionnement. Le second objectif de ce mémoire est d'illustrer l'application de ce cadre conceptuel sur deux cas particuliers. Le premier cas d'application est relatif à la modélisation analytique de systèmes complexes tolérants aux fautes. Nous montrons par cet exemple le moyen d'identifier les paramètres significatifs d'un modèle analytique nécessitant d'être déterminés expérimentalement. Le deuxième exemple est relatif à l'étalonnage de la sûreté de fonctionnement d'un système opératoire. Ces étalons sont purement expérimentaux et se basent énormément sur l'injection de fautes. Nous mettons l'accent dans cette partie de la thèse sur l'étude d'une part de l'équivalence entre les fautes injectées et d'autre part de la représentativité des fautes injectées par rapport aux fautes réelles dans les systèmes opératoires.

La sécurité informatique est un enjeu crucial. Elle consiste en premier lieu à définir une politique de sécurité puis à mettre en œuvre cette politique. L’approche de détection d'intrusions paramétrée par la politique de sécurité nous paraît prometteuse. Une telle approche s'appuie uniquement sur un modèle de l'évolution de l'état du système et sur un modèle de la politique de sécurité. Nous souhaitons surveiller un système comprenant un OS et des logiciels COTS dont des applications web. Nous proposons un modèle de détection permettant de suivre les flux d'informations entre les conteneurs d'informations. Nous définissons une architecture générique de système de détection d'intrusions (IDS) permettant d'implémenter le modèle proposé. Cette architecture repose sur la collaboration entre plusieurs IDS effectuant le suivi des flux d'informations à différents niveaux de granularité. Nous présentons une implémentation de cette architecture ainsi que les résultats de nos expérimentations<br>Computer security is now a crucial issue. We are convinced that policy-based intrusion detection is a promising approach. This kind of detection is only based on both a model of the system state evolution and a model of the security policy. We aim at using policy-based intrusion detection systems (IDS) to monitor a system with OS running COTS software and web applications. We propose a detection model that can monitor information flow between information containers. We define a generic IDS architecture implementing the proposed model. This architecture is based on the collaboration between several IDS monitoring information flows at different granularity levels. We present an implementation of this architecture and the results of the experiments we realized on realistic Java applications

Les noyaux de systèmes d'exploitation manipulent des données fournies par les programmes utilisateur via les appels système. Si elles sont manipulées sans prendre une attention particulière, une faille de sécurité connue sous le nom de Confused Deputy Problem peut amener à des fuites de données confidentielles ou l'élévation de privilèges d'un attaquant. Le but de cette thèse est d'utiliser des techniques de typage statique afin de détecter les manipulations dangereuses de pointeurs contrôlés par l'espace utilisateur. La plupart des systèmes d'exploitation sont écrits dans le langage C. On commence par en isoler un sous-langage sûr nommé Safespeak. Sa sémantique opérationnelle et un premier système de types sont décrits, et les propriétés classiques de sûreté du typage sont établies. La manipulation des états mémoire est formalisée sous la forme de lentilles bidirectionnelles, qui permettent d'encoder les mises à jour partielles des états et variables. Un première analyse sur ce langage est décrite, permettant de distinguer les entiers utilisés comme bitmasks, qui sont une source de bugs dans les programmes C<br>Operating system kernels need to manipulate data that comes from user programs through system calls. If it is done in an incautious manner, a security vulnerability known as the Confused Deputy Problem can lead to information disclosure or privilege escalation. The goal of this thesis is to use static typing to detect the dangerous uses of pointers that are controlled by userspace. Most operating systems are written in the C language. We start by isolating Safespeak, a safe subset of it. Its operational semantics as well as a type system are described, and the classic properties of type safety are established. Memory states are manipulated using bidirectional lenses, which can encode partial updates to states and variables. A first analysis is described, that identifies integers used as bitmasks, which are a common source of bugs in C programs. Then, we add to Safespeak the notion of pointers coming from userspace. This breaks type safety, but it is possible to get it back by assigning a different type to the pointers that are controlled by userspace. This distinction forces their dereferencing to be done in a controlled fashion. This technique makes it possible to detect two bugs in the Linux kernel: the first one is in a video driver for an AMD video card, and the second one in the ptrace system call for the Blackfin architecture