Pinaraf a écrit 3420 commentaires

  • [^] # Re: Not in 4.15-RC5 yet

    Posté par  . En réponse au journal D'un kernel panic à un patch…. Évalué à 3.

    Ok, good news for your boot.
    AFAIK, crypto should not prevent ethernet nor bluetooth from coming up. Maybe another issue. I suppose the drivers are properly loading, with no warning ?
    If you need any help, you can try contacting me on IRC (Pinaraf on freenode and oftc.net), or send me an email…

  • [^] # Re: Euh…

    Posté par  . En réponse au journal Un peu de NERF et de microcode Intel (merci Meltdown/Spectre). Évalué à 10.

    • PEI et DXE sont les deux parties de l'UEFI, pour résumer. PEI c'est un peu l'équivalent de ce qu'on avait avec le BIOS, et DXE est l'environnement UEFI plus complet, où tournent pilotes, applications et services UEFI
    • NERF est un projet visant à remplacer DXE par un noyau Linux

    Le rapport à meltdown : aucun, on ne peut pas patcher meltdown en dehors d'une modification du noyau.
    Le rapport à spectre : il faut déployer la mise à jour du microcode, et le meilleur endroit pour le faire reste le firmware (garantie que c'est fait pour tous les OS notamment)

  • [^] # Re: Euh…

    Posté par  . En réponse au journal Un peu de NERF et de microcode Intel (merci Meltdown/Spectre). Évalué à 10.

    C'est un projet qui vise à injecter dans la mémoire flash sur la carte mère, à la place de la partie «haute» de l'UEFI, un noyau Linux…
    Cf https://linuxfr.org/news/un-pas-en-avant-pour-les-serveurs-libres-le-projet-nerf

  • [^] # Re: Comment le cache peut être lu ?

    Posté par  . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 3.

    On peut plus faire de grosso modo tranquille de nos jours… :)

  • [^] # Re: Comment le cache peut être lu ?

    Posté par  . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 6.

    Alors, en fait, l'astuce c'est d'avoir un petit bout 'partagé' dans le cache.

    L'attaque repose, très grosso modo, sur le pseudo-code suivant :

    int mon_tableau[255] = { /* valeurs aléatoires */ };
    
    vide_le_cache();
    
    if (cas_impossible()) {
       unsigned char mon_octet = la_ram[adresse_cible];
       mon_tableau[mon_octet] = mon_tableau[mon_octet] * 42; // Ou toute autre opération sur mon_tableau[mon_octet]
    }

    L'attaque nécessite de faire croire au processeur qu'il va exécuter le code dans le if. Il fera alors les accès mémoire de ce code…
    Et si maintenant on fait une boucle sur mon_tableau, alors il y aura normalement une entrée qui sera en mémoire cache, et donc beaucoup plus rapide d'accès. CQFD…

    Est-ce plus clair ?

  • [^] # Re: Ca sent pas bon chez IBM aussi

    Posté par  . En réponse au journal Ça sent pas bon chez Intel ?. Évalué à 5.

    Pas tout à fait. Il reste les failles de l'Intel ME (on en a eu une belle l'année dernière) et celles à prévoir du côté du PSP d'AMD qui repose sur Trustzone (qui a déjà été exploité).

    Une faille de type Remote Code Execution sur le PSP est passée dans mes flux RSS ce week-end…

    Je vais reprendre des anti-dépresseurs…

  • [^] # Re: Not in 4.15-RC5 yet

    Posté par  . En réponse au journal D'un kernel panic à un patch…. Évalué à 5.

    Ok, you want the nasty one :)

    You have to locate the buggy function with objdump, and replace the whole function with a simple «return -EFAULT;» aka 0xb8f2ffffffc3.
    Using objdump -j text on ecdh_generic.ko, there will be two interesting lines :

    Idx Name          Size      VMA               LMA               File off  Algn
      1 .text         0000WXYZ  0000000000000000  0000000000000000  00000070  2**4
    

    And

    00000000000023e0 g     F .text  000000000000016f ecc_gen_privkey
    

    You will have to patch at address 0x70 + 0x23e0. And just overwrite the function first bytes with 0xb8f2ffffffc3. Then you will have a patched .ko file.
    It's a really really really nasty way of patching this. But it works…

  • [^] # Re: Bug (ou fonctionnalité ?)

    Posté par  . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 8.

    J'indiquais qu'AMD semble ne pas avoir pris ce risque en me basant sur les dires du développeur AMD sur la LKML : https://marc.info/?l=linux-kernel&m=151435344819700

    Donc effectivement il y a un truc suspect vu que le code a été exécuté… Peut-être les instructions sont exécutées mais sans lecture des données ? Ce qui serait un peu idiot, certes, mais compatible avec le fait que l'accès mémoire ait été bloqué, et que l'attaque n'ait pas réussi.

  • [^] # Re: Bug (ou fonctionnalité ?)

    Posté par  . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 7.

    Intel est la risée d’Internet pour avoir dit ces derniers jours, en substance, « nous n’avons pas merdé, nos processeurs fonctionnent exactement comme prévu », mais ils n’ont pas forcément tort sur ce point.

    À partir du moment où les accès mémoires sont faits avec un contrôle a posteriori, il y a un risque non négligeable. Et a priori AMD n'a pas pris ce risque. Pourquoi serait-il normal de prendre ce risque, et surtout d'affirmer que non non c'est normal qu'on fasse ça ?
    Spectre est difficilement reprochable, par contre Meltdown c'est quand même provoqué par un choix de conception qui parait assez «osé».

  • [^] # Re: Not in 4.15-RC5 yet

    Posté par  . En réponse au journal D'un kernel panic à un patch…. Évalué à 5.

    Ok, now we have something :)

    I did not push strongly my patch because I recently had an hard time trusting my computer (I fear my motherboard may have an issue). Since you have exactly the same bug, yes, a debian bug report would help since the debian team could backport the patch in their kernel, waiting for it to be upstreamed.

    Otherwise, well… I'm manually patching my .ko file using an hex editor. That's a weird way to work around the bug, but it's faster than recompiling :)

    Just so I can have an idea what may be wrong here, what is your motherboard and what is your CPU ?

  • [^] # Re: Mais que fait la p̶o̶l̶i̶c̶e̶ MMU ?

    Posté par  . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 10.

    Alors…

    1) c'est une entorse protégée par le "contrat" entre les développeurs et le CPU. La mémoire noyau est vendue par l'architecture comme intouchable avec ce découpage.
    2) meltdown est une violation du contrat précédent. Spectre par contre c'est autre chose, une optimisation qui permet de dévoiler des données

    La MMU continue en tout cas son boulot de gardien, comme toujours : la mémoire virtuelle A n'a pas accès à la mémoire virtuelle B. Mais le processeur reste maitre de l'accès aux pages virtuelles. Si il dit qu'il peut lire la mémoire du noyau, il peut. Même si c'est un mensonge, qu'il est en ring 3 et que c'est de la mémoire "réservée" au ring 0… Et tout ça c'est meltdown.

  • [^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?

    Posté par  . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 7.

    La MMU bloque l'accès… ou pas.
    Que tu sois en espace noyau ou en espace utilisateur, tu es (avant KPTI) sur le même espace virtuel.
    Ce n'est pas l'attaque actuelle, mais quand tu y réfléchis, d'un côté ton code est en ring 3, de l'autre en ring 0. Et c'est bien le CPU qui passe dans un mode ou un autre…
    Le choix d'interdire ou non l'accès à une adresse ne dépend pas de la MMU. En "simplifié", la MMU sépare les différents process, mais comme historiquement on a noyau et process au même endroit, pim.

  • [^] # Re: Merci pour la redirection…

    Posté par  . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 10.

    Je confirme, ce dimanche de 19H à 20H sur radio campus lille, dans l'echo des gnous, nous allons tenter d'expliquer tout ce bazar en des termes compatibles grand public.
    Ceux qui ont compris les journaux et dépêches sur ce sujet n'apprendront probablement pas grand chose. Les autres peuvent s'en servir pour répondre à des questions…

    Il sera donc possible d'écouter en live sur http://campuslille.com/ dimanche (et on sera joignables sur IRC, #chtinux sur freenode), ou en différé par le podcast https://podcast.grossard.fr/ (Merci encore au mainteneur du podcast, si tu lis ceci…)

  • [^] # Re: Failles totalement couvertes ou pas ?

    Posté par  . En réponse au journal Ça sent pas bon chez Intel ?. Évalué à 3.

    Spectre c'est processus courant. Ou un voisin dans lequel t'arrives à influencer l'exécution du code. C'est pas un accès ouvert à toute la mémoire. Pas comme meltdown qui permet d'accéder à la mémoire du noyau…

  • [^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?

    Posté par  . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 10.

    C'est pour ça que j'avais mis algorithme entre guillemets… :)
    C'est effectivement très très général comme principe (ça colle mieux qu'algo).
    Les processeurs modernes n'exécutent pas les instructions dans l'ordre, et tentent notamment de prédire quelles branches de code seront exécutées avant même d'interpréter la condition de la branche.

    Par exemple :

    a = 42;
    b = 72;
    if (tableau[a] < 73) {
      b++;
    }
    

    Il est possible que dans le processeur b soit incrémenté alors que tableau[a] est supérieur à 73. En fait le CPU ne peut pas exécuter le code x86 dans l'ordre suffisamment vite pour atteindre son maximum d'utilisation, c'est juste impossible. Par exemple s'il exécutait ce code dans l'ordre, l'unité arithmétique dormirait la majeure partie du temps. Il vaut mieux qu'elle soit active et fasse une opération alors que l'on n'a pas encore exécuté la comparaison pour savoir si l'opération est requise. Au pire, on jette le résultat et on reprend les opérations depuis l'erreur. Au mieux, on aura le résultat à l'avance. Et là je parle bien d'optimisations réalisées par le CPU, pas par le compilateur.
    C'est le principe d'une exécution «Out of Order» et d'une prédiction de branche.
    Tu peux jouer avec la commande perf stat pour comprendre ça éventuellement plus concrêtement.

    # perf stat echo 'toto'
    toto
    
     Performance counter stats for 'echo toto':
    
              0.354665      task-clock (msec)         #    0.010 CPUs utilized          
                     1      context-switches          #    0.003 M/sec                  
                     0      cpu-migrations            #    0.000 K/sec                  
                    59      page-faults               #    0.166 M/sec                  
             1,303,535      cycles                    #    3.675 GHz                    
               765,605      instructions              #    0.59  insn per cycle         
               154,395      branches                  #  435.326 M/sec                  
                 7,829      branch-misses             #    5.07% of all branches        
    
           0.034129737 seconds time elapsed
    

    Un CPU moderne est capable d'exécuter bien plus de 0,59 instructions par cycle (et je parle même pas de multi-cœurs). On voit qu'il a fait 5% de branch-misses, ce qui signifie qu'il a fait des mauvaises prédictions dans certains cas… Mais 5% c'est peu d'échecs et de temps perdu par rapport au gain qu'on a lorsqu'on a prédit avec succès…

    Là où il y a un problème, c'est quand le processeur rejette un résultat. Ça laisse des traces. Et ça on n'y avait pas suffisamment pensé avant. L'attaque spectre consiste, en simplifié, à exploiter ces traces. De même pour l'attaque meltdown (mais qui profite en plus d'un bug d'intel qui vérifie des droits d'accès a posteriori et pas a priori (!))

    Est-ce plus clair ?

  • # Merci pour la redirection…

    Posté par  . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 10.

    Ben merci pour le commentaire sur mon journal…

    Je vais tenter de faire une vulgarisation «grand public» des failles dans une émission de radio consacrée à l'informatique dans les prochains jours (l'Echo des Gnous, de chtinux)… Si ça se fait, sûrement ce dimanche ou dimanche prochain, je posterai ici un lien vers l'enregistrement.

  • [^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?

    Posté par  . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 10.

    C'est une faille sur l'"algorithme" implémenté (pardonnez moi cette simplification).
    Un effet de bord n'a pas été pris en compte dans l'algorithme d'exécution prédictive, et donc "PAF"… Aucun fondeur n'a vu ce défaut avant, aussi étonnant que ça puisse paraitre.

  • [^] # Re: Failles totalement couvertes ou pas ?

    Posté par  . En réponse au journal Ça sent pas bon chez Intel ?. Évalué à 2.

    Les patchs protègent le binaire compilé heureusement, ce n'est pas des patchs à appliquer sur le binaire «assaillant».

  • [^] # Re: Stock options Intel

    Posté par  . En réponse au journal Ça sent pas bon chez Intel ?. Évalué à 10.

    Tu voulais dire popcoin ?

  • [^] # Re: Bordel ?

    Posté par  . En réponse au journal Ça sent pas bon chez Intel ?. Évalué à 5.

    Certaines mesures d'hygiène informatique (souvent casse-couilles) diminuent considérablement l'impact tout de même.
    Pour meltdown, les détenteurs de CPU Intel n'ont pas le choix, mise à jour du noyau et activation de KPTI…
    Pour spectre, sur nos machines perso, la plus grosse attaque possible serait du code JavaScript qui va lire la mémoire du navigateur web (et donc des infos sur les autres sites). Je me sens moins concerné, j'utilise en permanence 4 instances de navigateur web, selon le type de site visité et la sensibilité des données qu'il manipule. Pour à travers spectre voler des infos sur mon compte bancaire, il faudrait que, depuis son domaine (NoScript bloquerait le reste), une de mes banques en attaque une autre.
    De manière générale, il serait temps de se demander pourquoi on laisse n'importe quelle page web exécuter du code sur nos machines. Est-ce-que ça en vaut vraiment la peine ?
    Et pourquoi Google a laissé pendant tant d'années (et semble continuer encore) des fabricants de smartphone vendre des Android sans garantie de maintenance sur la durée ?

  • [^] # Re: Not in 4.15-RC5 yet

    Posté par  . En réponse au journal D'un kernel panic à un patch…. Évalué à 4.

    Why in english ? This is a french website, quite unusual to see an english comment here.

    I contacted the crypto subsystem maintainers a few days ago to know how to boost this. Do you have any Debian bug report regarding this ?

    FR : J'ai contacté les mainteneurs de la partie crypto il y a quelques jours pour savoir comment pousser le patch… As-tu un rapport de bug debian à propos de ce soucis ?

  • [^] # Re: Desactivable?

    Posté par  . En réponse au journal Ça sent pas bon chez Intel ?. Évalué à 4.

    Toutes les autres contre-mesures ? De quelles contre-mesures parles-tu ? Ça ne désactive que le KPTI…

  • [^] # Re: autre lien

    Posté par  . En réponse au journal Ça sent pas bon chez Intel ?. Évalué à 3.

    PCID/INVPCID permet d'implémenter KPTI avec un coût moindre. La faille serait présente depuis avant l'introduction de cette fonctionnalité, certains affirmant même qu'elle date du Pentium 1…

  • [^] # Re: autre lien

    Posté par  . En réponse au journal Ça sent pas bon chez Intel ?. Évalué à 6.

    Plus précis mais aussi plus spéculatif. J'ai choisi (en plus il était tard) de ne pas mentionner ces pistes, même si le point d'AMD semble vraiment fiable.

    Mais dire «D'après AMD, il s'agirait d'un manque de contrôle lorsque le processeur empile de manière prédictive (speculative) les instructions avant de les exécuter (pipelining).» est incomplet/incorrect. On ne peut pas expliquer cette faille juste en prenant ce point de vue, il faut a priori partir très bas dans le fonctionnement du CPU, la faille serait au niveau du cœur d'exécution des micro opérations et pas de l'exécution des instructions x86 à proprement parler (sinon ça serait corrigeable par microcode).

    Donc attendons la levée de l'embargo à la con qui ne protège personne et ne fait que propager inquiétudes et rumeurs…

  • [^] # Re: Concrètement ?

    Posté par  . En réponse au journal Ça sent pas bon chez Intel ?. Évalué à 5.

    Sont-ils plus récents que des Pentium 1 ? Si oui, il y a une chance pour qu'ils soient impactés :)