Points de trace dynamiques, portables et extensibles en espace utilisateur avec un surcoût minimal et une couverture maximale

L’instrumentation d’un logiciel fait partie de la boîte à outils de l’ingénieur informatique. Ses principales utilisations sont l’évaluation des performances d’un logiciel et la génération d’évènements, dérivés de l’état du programme, en minimisant l’effet de sonde. Deux types d’instrumentation existent. L’instrumentation dite statique est déterminée au moment de la compilation du programme et requiert une recompilation de ce dernier pour être modifiée. Elle contraste avec l’instrumentation dite dynamique qui permet d’être modifiée sans recompilation du programme. Cela a le grand avantage de pouvoir instrumenter un logiciel en production, sans avoir accès à son moteur de production. Or, l’instrumentation dynamique – quoique présente dans le noyau de Linux – est peu présente en espace utilisateur. L’état de l’art actuel propose plusieurs algorithmes – tels que le calembourage d’instructions – permettant d’effectuer une instrumentation dynamique qui minimise les coûts associés à celle-ci sur le programme instrumenté, tout en maximisant sa couverture. Cependant, il n’existe pas d’implémentation robuste basée sur de tels algorithmes qui puisse être utilisée sur des systèmes réels. L’implémentation la plus sérieuse se nomme Dyninst et n’implémente pas ces algorithmes, son paradigme d’instrumentation dynamique étant différent. L’objectif de ce travail est donc de mettre au point de nouveaux algorithmes améliorés, et d’implémenter ceux-ci dans une bibliothèque en espace utilisateur qui unifie, améliore et complète les algorithmes existants en matière d’instrumentation dynamique, en offrant une API qui abstrait les détails architecturaux. Les sous-objectifs sont de maximiser la couverture de l’instrumentation, minimiser le surcoût spatio-temporel associé à l’instrumentation sur le programme, et de garantir l’exactitude de l’instrumentation, c.-à-d. que celle-ci ne brise pas le programme. L’implémentation qui en résulte, nommée Libpatch, a été comparée à Dyninst. Sur le plan de la couverture, Dyninst est en théorie capable d’atteindre 100%, car celui-ci déplace et augmente des flots de contrôle complets du programme. Libpatch, quant à lui, offre une couverture globale de 99.1%, tout en étant beaucoup moins intrusif. Cela favorise Libpatch sur le plan du surcoût spatial en utilisant beaucoup moins de mémoire physique – près de 10 fois moins – que Dyninst, un aspect critique pour les sytèmes embarqués. De plus, le surcoût temporel lié à la modification du programme pour installer ou enlever l’instrumentation est beaucoup moins important pour Libpatch, car ce dernier n’interrompt pas l’ensemble des fils d’exécutions du programme, contrairement à Dyninst. Enfin, les surcoûts temporels, liés vi à l’exécution de l’instrumentation, sont du même ordre de grandeur et Libpatch offre une grande capacité de mise à l’échelle, par rapport au nombre de fils d’exécution. Finalement, Libpatch serait en mesure de bien s’intégrer au sein d’outils tels que GDB et Uftrace, pour augmenter le taux de couverture de leur instrumentation, mais aussi les accélérer. D’autres applications sont aussi possibles, telles que la vérification des accès en mémoire et l’application de correctifs liés à des failles de sécurité.