Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Redacteur
    Inscrit en
    juin 2016
    Messages
    965
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Redacteur
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2016
    Messages : 965
    Points : 26 436
    Points
    26 436
    Par défaut Google découvre des centaines de situations de compétition dans le noyau Linux
    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

    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.

    Nom : z.jpg
Affichages : 18195
Taille : 13,3 Ko

    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre à l'essai
    Homme Profil pro
    Menuisier
    Inscrit en
    mars 2019
    Messages
    9
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Menuisier

    Informations forums :
    Inscription : mars 2019
    Messages : 9
    Points : 13
    Points
    13
    Par défaut Question d'un gars qui n'y connait rien
    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

  3. #3
    Membre expérimenté
    Profil pro
    Inscrit en
    octobre 2005
    Messages
    879
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France

    Informations forums :
    Inscription : octobre 2005
    Messages : 879
    Points : 1 465
    Points
    1 465
    Par défaut
    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. #4
    Membre à l'essai
    Homme Profil pro
    Menuisier
    Inscrit en
    mars 2019
    Messages
    9
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Menuisier

    Informations forums :
    Inscription : mars 2019
    Messages : 9
    Points : 13
    Points
    13
    Par défaut
    Merci pour ton explication très claire BugFactory

  5. #5
    Expert éminent sénior

    Homme Profil pro
    pdg
    Inscrit en
    juin 2003
    Messages
    5 691
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : pdg

    Informations forums :
    Inscription : juin 2003
    Messages : 5 691
    Points : 10 305
    Points
    10 305
    Billets dans le blog
    3
    Par défaut
    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.

Discussions similaires

  1. Réponses: 1
    Dernier message: 18/06/2019, 22h12
  2. Réponses: 4
    Dernier message: 05/07/2015, 11h51
  3. Réponses: 3
    Dernier message: 16/03/2015, 08h58
  4. Comment éviter que google répete des mots qui sont dans la description du meta tag
    Par tese84 dans le forum Balisage (X)HTML et validation W3C
    Réponses: 2
    Dernier message: 18/09/2006, 08h55

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo