IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Google découvre des centaines de situations de compétition dans le noyau Linux en se servant de KCSAN
Son nouveau détecteur de courses critiques pour le noyau Linux

Le , par Bill Fassinou

99PARTAGES

17  0 
Les ingénieurs de Google contribuant au noyau Linux ont annoncé avoir découvert des centaines de « race conditions », littéralement « situation de course » en anglais, dans le noyau en utilisant KCSAN. L’entreprise a travaillé pendant longtemps sur AddressSanitizer pour la recherche de bogues liés à la corruption de la mémoire, ou sur UndefinedBehaviorSanitizer pour le comportement non défini dans le code et d'autres assainisseurs. Cette fois, Google propose un nouveau détecteur de course critique pour le noyau Linux qu’il appelle KCSAN (Kernel Concurrency Sanitizer).

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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de BugFactory
Membre chevronné https://www.developpez.com
Le 04/10/2019 à 11:01
C'est théoriquement possible, mais pas très réaliste. Le code de Linux est très contrôlé, et introduire un logiciel espion en échappant à la surveillance des autres contributeurs serait pour le moins difficile. De plus, si google était pris à introduire un logiciel espion dans le noyau Linux, les conséquences pourraient être graves. Google perdrait énormément en termes d'images, et utilise beaucoup de logiciels Open Source : se mettre à dos la communauté serait une erreur.

Mais la principale raison pour laquelle Google ne ferait pas ça est plus simple : ils n'en ont pas besoin. Ils possèdent déjà des outils de "suivi" efficaces et légaux. Pourquoi prendre un risque?
4  0 
Avatar de Aurelien.Regat-Barrel
Expert éminent sénior https://www.developpez.com
Le 04/10/2019 à 17:11
Google est très dépendant de Linux pour son propre usage mais aussi pour vendre des services via son Cloud. Sa propre sécurité et rentabilité en dépend. Il a donc intérêt à fiabiliser cet OS au même titre que Red Hat, IBM, ... et même Microsoft (qui vend plus de Linux sur son Azure que de Windows).

Comme l'a dit BugFactory, ce n'est pas en installant un espion sur ta machine que Google fait de l'argent mais simplement en t'identifiant comme utilisateur de leurs services.
4  0 
Avatar de Will0171
Membre du Club https://www.developpez.com
Le 04/10/2019 à 15:48
Merci pour ton explication très claire BugFactory
0  0 
Avatar de Will0171
Membre du Club https://www.developpez.com
Le 04/10/2019 à 9:34
Si quelqu'un peut m’éclairer sur un truc, sachant que le but (et le gagne pain) de google est pénétrer chaque machine numérique de ce monde pour en siphonner toutes les données, leur KCSAN, ne serait il pas une bonne façon de placer un spy dans les quelques derrieres machines résistantes à leur soif de "vie privée"?

Merci
0  1