Journal Les performances d'un noyau avec le patch PaX

PaX est un patch externe applicable sur le noyau Linux et qui vise à protéger les zones mémoires contre diverses attaques.
Une présentation intéressante, "20 years of PaX", a été donnée à la conférence SSTIC de cet été. Et un commentaire de cette présentation est disponible ici.

J'ai toujours été curieux de savoir quel pouvait être le coût en performances de PaX quand il est appliqué au noyau Linux. Le dernier document intéressant datait de 2005 (donc risque d'obsolescence) et en plus il n'évaluait qu'une seule chose:

Benchmarks were based on time measurement of a kernel tree compilation, on idle computers. This is a reliable benchmark because it can take about one hour to complete, and above all, it is very CPU and memory intensive.

Ce que je voulais c'était des données plus récentes, avec une granularité plus fine de l'évaluation et pourquoi pas, soyons fous, une certaine caution scientifique apportée par une publication avec comité de lecture.
Oyez, oyez, ma quête est arrivée à son terme ! J'ai trouvé mon bonheur avec un article publié lors de la dernière conférence USENIX Security Symposium 2012.
Le papier s'intitule "kGuard: Lightweight Kernel Protection against Return-to-user Attacks" et il évoque un nouveau système de protection qui se veut plus performant que PaX.
Bien entendu je n'ai pas le plus petit début de compétence pour juger si kGuard est effectivement une bonne approche…mais ce qui est intéressant c'est la section 5 de l'article qui évalue les performances de kGuard et de PaX par rapport à un noyau vanilla.

On peut ainsi trouver des chiffres fiables sur divers micro-benchmarks comme par exemple la latence des principaux appels (read, write, fstat, select, open, close) ou sur la gestion des processus (fork, exit, execve).
Je ne commente pas les chiffres de kGuard mais, en ce qui concerne PaX, les résultats sont assez préoccupants puisque la latence augmente fortement. Les pourcentages expriment la dégradation (en microsecondes) par rapport au noyau vanilla:

The PaX-protected kernel exhibits a latency ranging between 5.6% and 257% (average 84.5%) on the x86, whereas on x86-64, the latency overhead ranges between 19% and 531% (average 172.2%). Additionally, (..) overhead for process creation (in both architectures) lies between 8.1% to 56.3%.

On note que les chiffres sous x86-64 sont moins bons que sous x-86 parce que PaX utilise la segmentation sous x86 alors qu'il est obligé de faire certaines contorsions spécifiques sous l'architecture x86-64:

On x86, PaX offers protection against ret2usr attacks by utilizing the segmentation unit for isolating the kernel from user space. In x86-64 CPUs, where segmentation is not supported by the hardware, it temporarily remaps user space into a different location with non-execute permissions.

Il y a également des tests de bande passante entre les processus (via socket et pipe). Ici les pourcentages expriment la dégradation (en Mo/s) par rapport au noyau vanilla:

PaX’s overhead lies between 19.9% – 58.8% on x86 (average 37%), and 21.7% – 78% on x86-64 (average 42.8%).

En dépit de ces micro-benchmarks franchement catastrophiques, les chiffres des tests sur application réelles (macro benchmarks) sont assez corrects. Par exemple le temps de compilation d'un noyau mesuré avec time n'augmente que 1,26% sous x86 et de 2,89% sous x86-64. De la même manière le test MySQL (sql-bench) montre une dégradation modérée (1,16% sous x86 et 2,67% sous x86-64).

Quoi qu'il en soit mon âme est maintenant en paix puisque je ne suis plus totalement à la merci des trolls pro ou anti PaX. J'ai maintenant des chiffres sous la main afin d'évaluer le coût en performances de ce patch.
Reste maintenant à avoir des infos fiables sur la qualité réelle de la protection offerte par PaX et sur la charge de maintenance que cela représenterait d'inclure ça dans le noyau.

Une nouvelle quête ?