Tiberiu Mosnoi’s research while affiliated with University of Bucharest and other places

What is this page?


This page lists works of an author who doesn't have a ResearchGate profile or hasn't added the works to their profile yet. It is automatically generated from public (personal) data to further our legitimate goal of comprehensive and accurate scientific recordkeeping. If you are this author and want this page removed, please let us know.

Publications (2)


FIGURE 5 -Débit Redis pour différents scénarios d'isolation MPK. décrit précédemment. Nos micro-benchmarks montrent un coût moyen de changement de contexte en moyenne trois fois plus élevé que pour l'ordonnanceur C : 218.6ns contre 76.6ns, mais la Figure 4 montre que ce coût est raisonnable en pratique avec un ralentissement moyen de 6% pour Redis. L'utilisation flexible de SFI et de la vérification sur la base d'une bibliothèque permet de profiter de certains avantages de ces mécanismes sans en payer le coût, ouvrant la voie à de nombreux potentiels de couplage avec des mécanismes matériels. Redis : Variation des Stratégies d'Isolation avec MPK. Nous avons évalué Redis dans une variété de scénarios sous Intel MPK. Nous avons défini quatre modèles d'isolation : { pile TCP/IP, reste du système }, { pile TCP/IP, ordonnanceur, reste du système }, et { pile TCP/IP + ordonnanceur, reste du système }, ainsi qu'un référentiel sans isolation. Ces différents scénarios illustrent la capacité de FlexOS à simplement composer avec une variété de modèles de confiance. Pour chaque scénario nous avons réalisé les mesures avec et sans isolation de la pile d'exécution. Les résultats sont visibles sur la Figure 5. Le coût de l'isolation varie en fonction du nombre de compartiments, de la porte utilisée, et de l'approche de communication empruntée par les compartiments. Isoler la pile réseau seulement entraîne un ralentissement de 17%. Isoler également l'ordonnanceur entraîne un ralentissement de 1.4x-2.25x en fonction de la porte utilisée. Ces résultats illustrent l'importance de la communication entre l'ordonnanceur et la pile réseau. Néanmoins, mettre la pile réseau et l'ordonnanceur dans le même compartiment n'améliore pas significativement la performance. La communication entre la pile réseau et l'ordonnanceur passe par la libC, ne réduisant ainsi pas le nombre de changements de contexte. En somme, ces résultats montrent la variété de compromis sécu-rité/performance qui peuvent être obtenus, mais aussi la complexité de raisonner sur la performance d'une configuration; cela motive notre approche d'exploration automatique de l'espace de conception.
FlexOS : Vers une Isolation Flexible du Noyau
  • Conference Paper
  • Full-text available

July 2021

·

58 Reads

Hugo Lefeuvre

·

·

·

[...]

·

Rȃzvan Deaconescu

Au moment de leur conception, les systèmes d'exploitation modernes implémentent une stratégie de sécurité et d'isolation bien précise reposant sur un ou plusieurs mécanismes logiciels ou matériels. Pour des raisons de coût, ce choix est rarement revisité après déploiement. Cette approche classique est limitée lorsque les protections matérielles viennent à casser, lorsque le matériel devient hétérogène, ou lorsque l'on cherche à spécialiser dynamiquement le système pour un cas d'usage précis. Nous présen-tons FlexOS, un système d'exploitation permettant de facilement spécialiser la stratégie d'isolation du noyau à la compilation et non à la conception. FlexOS est un LibOS modulable incluant des composants isolables à des granularités variables via de multiples mécanismes, d'un langage de description per-mettant à l'utilisateur de détailler les besoins en sécurité du système, et d'un framework d'exploration automatique des compromis de sécurité et performance offerts par FlexOS pour une application donnée. Nous évaluons FlexOS et démontrons le vaste espace de conception qu'il permet d'explorer.

Download

Figure 1: Design space of OS kernels.
Figure 5: Redis throughput with MPK isolation.
iperf throughput with SH on various components.
FlexOS: making OS isolation flexible

June 2021

·

212 Reads

·

18 Citations

OS design is traditionally heavily intertwined with protection mechanisms. OSes statically commit to one or a combination of (1) hardware isolation, (2) runtime checking, and (3) software verification early at design time. Changes after deployment require major refactoring; as such, they are rare and costly. In this paper, we argue that this strategy is at odds with recent hardware and software trends: protections break (Meltdown), hardware becomes heterogeneous (Memory Protection Keys, CHERI), and multiple mechanisms can now be used for the same task (software hardening, verification, HW isolation, etc). In short, the choice of isolation strategy and primitives should be postponed to deployment time. We present FlexOS, a novel, modular OS design whose compartmentalization and protection profile can seamlessly be tailored towards a specific application or use-case at build time. FlexOS offers a language to describe components' security needs/behavior, and to automatically derive from it a compartmentalization strategy. We implement an early proto-type of FlexOS that can automatically generate a large array of different OSes implementing different security strategies.

Citations (1)


... Hardware-assisted compartmentalization The idea of using MPK for compartmentalizing applications is not new; PKU in 64-bit x86 is used to augment SFI approaches that generally suer from high enforcement overheads [23], [88]. Such work falls into two categories: 1) in-process isolation [44]- [47], [51]- [56], and 2) isolation for unikernels and library OSs [48]- [50]. Lack of PKRU access control has been scrutinized for leaving PKU-based schemes vulnerable to bypass of established isolation domains [53], [82], [84]. ...

Reference:

Rewind & Discard: Improving Software Resilience using Isolated Domains
FlexOS: making OS isolation flexible