Les vulnérabilités dites de course de course critique ne sont pas nouvelles. En effet, une course critique ou situation de compétition se produit lorsque deux threads ou plus dans un même processus accèdent simultanément au même emplacement mémoire, où au moins un des accès est destiné à l'écriture, et lorsque les threads n'utilisent aucun verrou exclusif pour contrôler leurs accès à cette mémoire. Lorsque ces conditions sont remplies, l'ordre des accès n'est pas déterministe et le calcul peut donner des résultats différents d'une exécution à l'autre en fonction de cet ordre.
Les courses critiques sont de plus en plus considérées comme des bogues d'accès simultané et sont difficiles à reproduire et à diagnostiquer dans des programmes parallèles. Le noyau Linux est un système logiciel à grande échelle, dans lequel un parallélisme intensif au niveau des threads et un entrelacement non déterministe des threads sont plus sujets aux conditions de concurrence. Certaines situations de compétition peuvent être bénignes, mais une grande partie identifiée à ce jour sont considérées comme des bogues.
Le noyau Linux fournit plusieurs mécanismes pour éviter et gérer les conditions de course (race conditions en anglais). Il existe des outils comme Thread Analyzer ou encore KTSAN (Kernel Thread Sanitizer) pour détecter les erreurs de courses critiques dans le noyau Linux. Toutefois, Google, qui contribue également au noyau Linux, a proposé récemment KCSAN, un nouveau détecteur de courses critiques pour le noyau, un peu semblable à KTSAN. KCSAN (Kernel Concurrency Sanitizer) est un détecteur dynamique de course de critiques pour le noyau Linux.
Selon Google, KCSAN se concentre sur la découverte des situations de compétition dans le code du noyau. Ce détecteur dynamique de courses critiques est une alternative au détecteur KTSAN (Kernel Thread Sanitizer). D’après les explications de Google, KCSAN est basé sur des points de surveillance d'échantillonnage, contrairement au détecteur KTSAN, qui est un détecteur de courses critiques avant l'événement. Les priorités clés dans la conception du KCSAN sont le manque de faux positifs, l'évolutivité et la simplicité.
KCSAN utilise des instruments de compilation pour les accès à la mémoire. KCSAN est supporté par les compilateurs GCC et Clang. Avec GCC, il nécessite la version 7.3.0 ou ultérieure et avec Clang, il nécessite la version 7.0.0 ou ultérieure. Sur la page GitHub du projet, Marco Elver de Google a écrit qu’en utilisant KCSAN dans des tests le mois dernier, ils ont trouvé en seulement deux jours plus de 300 situations de compétition uniques dans le noyau principal. KCSAN fournit plusieurs options de configuration pour personnaliser son comportement.
« Nous utilisons KCSAN via Syzkaller depuis plusieurs semaines, et nous avons trouvé de nombreux bogues. Initialement en septembre 2019, nous avons identifié plus de 300 situations de compétition uniques pendant seulement 2 jours », a-t-il écrit. Google a indiqué que l’approche générale s’inspire de DataCollider, un autre détecteur dynamique de situations de compétition dans les modules de noyau. Mais contrairement à DataCollider, KCSAN n'utilise pas de points de surveillance matériels, mais s'appuie plutôt sur des instruments de compilation.
Les points de surveillance sont implémentés à l'aide d'un encodage efficace qui stocke le type d'accès, la taille et l'adresse dans un long fichier. Les avantages de l'utilisation de points de surveillance souples sont la portabilité et une plus grande flexibilité pour limiter les accès pouvant déclencher un point de surveillance. Voici les points clés évoqués par Google pour KCSAN :
- des performances élevées : la durée d'exécution de KCSAN est minimale et ne nécessite pas de verrouillage d'état partagé pour chaque accès. Il en résulte des performances nettement supérieures à celles du KTSAN ;
- aucune mémoire supplémentaire : selon Google, aucune mémoire cache n'est requise. L'implémentation actuelle utilise un petit nombre de longs pour coder l'information des points de surveillance, ce qui est négligeable ;
- commande de mémoire : KCSAN n'a pas connaissance des règles de commande du LKMM (Linux Kernel Memory Model - le modèle de mémoire du noyau Linux). Il peut en résulter des courses critiques manquées (faux négatifs) par rapport à un détecteur de course avant l’événement tel que le KTSAN ;
- précision : selon Google, KCSAN est imprécis, car il utilise une stratégie d'échantillonnage ;
- nécessite une annotation : une annotation minimale est requise en dehors du runtime KCSAN. Dans le cas d'un détecteur d'événements antérieurs à la course, toute omission entraîne de faux positifs, ce qui est particulièrement important dans le contexte du noyau qui comprend des mécanismes de synchronisation personnalisés. Avec KCSAN, par conséquent, les frais de maintenance sont minimes à mesure que le noyau évolue ;
- détecte les écritures dynamiques à partir de périphériques : grâce à la vérification des valeurs de données lors de la configuration des points de surveillance, les écritures dynamiques à partir de périphériques peuvent également être détectées.
Vous pouvez obtenir plus d’informations sur KCSAN en parcourant sa documentation. Google a hébergé le code du détecteur sur GitHub que vous pouvez également consulter. Si l’outil s’est montré performant et capable de déterminer un tel nombre de courses de données en deux jours seulement, certains soulignent aussi la possibilité d’utiliser la technologie de l’apprentissage automatique pour résoudre ces problèmes.
Source : KCSAN
Et vous ?
Qu'en pensez-vous ?
Voir aussi
Une faille grave du noyau Linux a été découverte dans RDS. Red Hat, Ubuntu, Debian et SUSE affectées
De nouvelles vulnérabilités découvertes sur les systèmes Linux et FreeBSD, permettant aux pirates d'avoir un contrôle à distance
Des vulnérabilités de corruption de mémoire dans systemd affectent la plupart des distributions Linux. Aucun correctif n'est disponible pour le moment