Journal Corruption hardware fatal sur les noyaux 2.6.27-rc

Posté par  .
Étiquettes :
18
24
sept.
2008
Un bug dans le kernel peut tuer complètement (niveau hard) certaines cartes réseau intel lors de l'utilisation d'un noyau 2.6.27-rc. Ce noyau est celui utilisé dans les pre-release de SuSE, Fedora, Ubuntu et Mandriva.

Les détails:
http://blog.mandriva.com/2008/09/23/urgent-notification-majo(...)
http://bugzilla.kernel.org/show_bug.cgi?id=11382
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/263555
  • # Seulement hardware ?

    Posté par  . Évalué à 4.

    Je pensais que les cartes étaient protégées contre un bug de ce type.
    Ça m'étonne que du software puisse abîmer du hardware en jouant sur autre chose que l'usure.

    Envoyé depuis mon lapin.

    • [^] # Re: Seulement hardware ?

      Posté par  (site web personnel) . Évalué à -1.

      hello,

      viiblement, le module en question doit injecter un firmware dans l'EEPROM de la carte et ce firmware est défectueux...
      Du coup, le matos ne fonctionne plus ! Encore une fois, le problème est finalement d'ordre logiciel !
      • [^] # Re: Seulement hardware ?

        Posté par  . Évalué à 3.

        Non l'eeprom ne contient pas un firmware mais des paramètres de la carte (adresse MAC, constructeur, id a présenté sur le bus usb, ...)

        Et du coup si certains de ces paramètres sont foireux la carte n'est plus fonctionnelle, jusqu'a qu'on ai remis dans l'eeprom des valeur correcte (souvent avec un logiciel du constructeur).

        Ca met déja arriver plusieurs fois : sous windows sur une carte TV et un driver foireux (j'ai pu la réparer grace a linux qui exportait l'eeprom)
        sous linux avec une carte réseau 3c905C et AIRONET (la réparation c'est fait en utilisant des logiciel du constructeur (DOS/windows)).
    • [^] # Re: Seulement hardware ?

      Posté par  . Évalué à 2.

      Ça écrase l'EEPROM, et si tu n'as pas de sauvegarde c'est très difficile à rétablir (et si le rétablissement foire, la carte n'est même plus visible sur le bus PCI d'après certaines personnes qui commentent sur le bug). Le problème c'est que ces données ne dépendent pas que du périphérique mais de tout le matos (le BIOS, etc), du coup Intel ne peut pas fournir une sauvegarde qui marcherait pour tout le monde (d'ailleurs leur conseil est pour les personnes possédant une carte concernée de sauvegarder tout de suite le contenu de l'EEPROM).

      Avec de la chance, une mise à jour BIOS pourrait rétablir le fonctionnement de la carte.

      Sinon le problème c'est comme avec les routeurs. Si t'as pas de port de debuggage, si ta carte/ton routeur est brické (la partie soft est tellement buggé que ça n'écoute même plus sur le bus pci/l'interface ethernet) tu peux rien faire. Et une interface de debuggage pour carte PCI c'est pas évident à trouver je pense.
      • [^] # Re: Seulement hardware ?

        Posté par  . Évalué à 2.

        > Sinon le problème c'est comme avec les routeurs. Si t'as pas de port de debuggage, si ta carte/ton routeur est brické (la partie soft est tellement buggé que ça n'écoute même plus sur le bus pci/l'interface ethernet) tu peux rien faire. Et une interface de debuggage pour carte PCI c'est pas évident à trouver je pense.

        Tu peux aussi te faire foutre dehors quand la gestion du mot de passe fonctionne mal (ça m'est déjà arrivé avec une X-WRT "kamikaze", donc tout sauf stable, et encore moins fiable, et l'interface https, qui ne voulait pas accepter le mot de passe dont j'étais pourtant sûr [m'apprendra à mettre des mots de passe avec le signe €]... et dont le ssh plantait aussi [mais ça, je savais, sur le coup])...

        ... bon, il y a toujours les "pin tricks", comme la fantastique mise à la masse de la patte 16 d'une des puces, sur les WRT54, qui remet le bestiau en attente de flashage via tftp... m'a sauvé la vie plus d'une fois, ce truc-là (et je n'ai claqué qu'un seul WRT, avec des étincelles, via cette méthode... sur des dizaines et des dizaines de recours au pin-trick)...
      • [^] # Re: Seulement hardware ?

        Posté par  . Évalué à 3.

        Ça écrase l'EEPROM, et si tu n'as pas de sauvegarde c'est très difficile à rétablir (et si le rétablissement foire, la carte n'est même plus visible sur le bus PCI d'après certaines personnes qui commentent sur le bug).
        Oui, mais il y a souvent des moyen de les récuperer en by passant les stack pci des os et en utilisant des outils du constructeur.


        Le problème c'est que ces données ne dépendent pas que du périphérique mais de tout le matos (le BIOS, etc), du coup Intel ne peut pas fournir une sauvegarde qui marcherait pour tout le monde (d'ailleurs leur conseil est pour les personnes possédant une carte concernée de sauvegarder tout de suite le contenu de l'EEPROM).

        Bon après il suffit de prendre une copie d'une eeprom de quelqu'un qui a une config similaire a toi et eventuel de modifier un peu le contenu si le format est connu.

        PS : t'es sur que l'eeprom de la carte réseau et le BIOS sont liée ?
        • [^] # Re: Seulement hardware ?

          Posté par  . Évalué à 2.

          PS : t'es sur que l'eeprom de la carte réseau et le BIOS sont liée ?

          C'était dans le bugreport ubuntu (après peut être que le mec dit n'imp, mais le mec de intel qui poste dans le bugrepot ne corrige pas en tout cas):
          https://bugs.launchpad.net/ubuntu/+source/linux/+bug/263555
        • [^] # Re: Seulement hardware ?

          Posté par  . Évalué à 4.

          Bon après il suffit de prendre une copie d'une eeprom de quelqu'un qui a une config similaire a toi et eventuel de modifier un peu le contenu si le format est connu.

          Visiblement malheureusement c'est pas le cas. Les derniers mails de Dave Airlie sur la lkml:
          Well I'm out of the race, my attempts to re-write my eeprom using an eeprom from an equivalent laptop have totally failed and my BIOS won't boot anymore - so my laptop is == a brick.

          http://lkml.org/lkml/2008/9/24/469
  • # ICH8/ICH9 ?

    Posté par  (site web personnel) . Évalué à 3.

    a priori, il faut aussi avoir un chipset ICH8/ICH9, j'ai de la chance de ne pas être touché

    mon laptop a de l'ICH7 http://hardware4linux.info/system/2960/
    lspcidrake -v donne
    e1000e : Intel Corporation|82573L Gigabit Ethernet Controller [NETWORK_ETHERNET] (vendor:8086 device:109a subv:103c subd:30bb)
    i2c_i801 : Intel Corporation|82801G (ICH7 Family) SMBus Controller [SERIAL_SMBUS] (vendor:8086 device:27da subv:103c subd:30bb)
    (et d'autres ICH7 mais je suppose que ce n'est pas l'USB ou le son ou le PCI express ni le sata ou l'ide...)

    J'ai tout de même lancé le ethtool -e eth0 > savemyeep.txt
    au cas où... Intel donnera bien une méthode logicielle pour réparer j'espère ;-)
    • [^] # Re: ICH8/ICH9 ?

      Posté par  . Évalué à 3.

      tiens pour une fois que je suis content d'avoir du broadcom dans mon pc... :)

      Cela m'a permis de m'en rendre compte aussi, j'etais pas trop au courrant.
  • # Ouf

    Posté par  . Évalué à 3.

    Heureusement que je met toujours les pre-release dans une machine vbox....
  • # DON'T PANIC

    Posté par  (site web personnel) . Évalué à 5.

    « il est possible de résoudre le problème en updatant ou en reflashant le BIOS de votre carte mère. » dit le blog Mandriva.

    Et n'oubliez pas votre serviette !
    • [^] # Re: DON'T PANIC

      Posté par  . Évalué à -5.

      Surtout que Mandriva n'en est pas à son coup d'essai en matière de déterioration du matériel :
      http://www.mandrakelinux.com/en/errata.php3 ah ben non, ça n'existe plus. Plutôt ceci : http://www.zdnet.fr/actualites/informatique/0,39040745,39128(...)
      • [^] # Re: DON'T PANIC

        Posté par  (site web personnel) . Évalué à 10.

        oué enfin la première ligne est qd même :
        > Le non-respect de la norme ATAPI par certains lecteurs de CD-Rom LG

        Après faut pas venir se pleindre si ça crame... (et on me souffle que le problème touchait également d'autres distribs dont suse mais qu'il est mieux de retenir mandriva c'est mieux pour briller en société)
        • [^] # Re: DON'T PANIC

          Posté par  . Évalué à 4.

          Gentoo a morflé longtemps avant, mais sans que personne ne comprenne ce qu'il se passait
      • [^] # Re: DON'T PANIC

        Posté par  (Mastodon) . Évalué à -3.

        Tu peux pas te contenter de dire "la distro que je préfère elle est bien parceque..." ? faut vraiment que tu exprimes du mépris envers les autres ? (du coup, la distro que tu aimes bien, elle certainement pas si bien, vu le peu d' arguments....)

        purée que j' en ai marre de certains linuxiens, mais marre.
        • [^] # Re: DON'T PANIC

          Posté par  . Évalué à 0.

          Des fois je me dis qu'un brevet de "non marchage dedans" serait nécessaire avant d'autoriser les gens à poster sur trollfr.
          Si tu veux le fond de ma pensée pour te rassurer : je ne porte absolument aucun jugement, par ignorance, sur aucune distribution que je n'utilise pas, même si elle saute des numéros de version ou change de nom. Non, j'ai même une certaine admiration pour les gens qui choisissent le chemin le plus difficile : gagner sa vie en faisant une distribution libre.

          Je pense que le vrai débat c'est "pour ou contre le point d'ironie ?". Personnellement je suis contre, et contre les smilaids qui adoucissent hypocritement certaines vacheries.

          Naïf, va ;-)
          • [^] # Re: DON'T PANIC

            Posté par  (Mastodon) . Évalué à 0.

            Tu m' excusera de prendre ce commentaire pour un non-troll. Ce type de commentaires pullule trop (pour moi en ce moment) par ici et ailleurs. Sans mention type /humour... il est impossible de faire la différence.

            Il faudrait aussi un permis "je me rends compte de comment je le dis et où je le dis" avant d' autoriser les gens à poster sur linuxfr, tribune lue pas seulement par des initiés aux trolls.

            Désolé d' avoir pris ton commentaire au 1er degrés. La prochaine fois fait une mention /humour, s' il te plait. (et moi aussi d' ailleurs, j' y penserai...)

            Cdlt ;-)
        • [^] # Re: DON'T PANIC

          Posté par  (site web personnel) . Évalué à 3.

          Mouais enfin toutes les distros qui utilisaient le même kernel ont eu le pbm (Gentoo, Suse).
          J'avais justement bousillé le lecteur de CD du PC de mes parents, mais Mandriva apportait un appui efficace et de la doc ce qui m'a permis de le réparer facilement...
          Nul doute qu'ils (Mandriva, les dev noyau, Intel...) donneront bientôt la marche à suivre pour récupérer le coup.
  • # Merci

    Posté par  (Mastodon) . Évalué à 10.

    Merci d' avoir relayé cette information ici !!

    j' ai été confronté au bug ;) mais bizarrement je n' ai pas eu de soucis menant à flasher... un simple reboot sur un autre kernel à suffit. (mdv cooker).

    En fait le workaround de mandriva a fonctionné sans même que je m' en apperçoive, et avant même d' être au courant de ce bug. Chapeau Mandriva ! Et merci !

    L' équipe Kernel de chez Mandriva, c' est devenu quelque chose d' extra !
  • # Ah? Bientôt un nouveau virus pour windaube?

    Posté par  . Évalué à -4.

    Cette information est intéressante pour les créateurs de virus. Ils vont pouvoir utiliser ce bug.
    • [^] # Re: Ah? Bientôt un nouveau virus pour windaube?

      Posté par  . Évalué à 8.

      Un bug dans le kernel Linux (ou un de ses drivers ?) va permettre à des gus d'écrire des virus pour Windows ?

      Il y a une logique dans ton propos qui m'échappe...
      • [^] # Re: Ah? Bientôt un nouveau virus pour windaube?

        Posté par  . Évalué à 1.

        Malgré l'attention générale focalisée sur les spywares, le bon vieux virus qui a juste pour but de flinguer ton matos existe encore. Ce bug du noyau expose une vulnérabilité du matériel qui peut potentiellement être exploité par un virus (bien que j'espère que seul le driver peut aller farfouiller le microcode, même sous windows).
        • [^] # Re: Ah? Bientôt un nouveau virus pour windaube?

          Posté par  . Évalué à 3.

          Le kernel peut tout faire, sous windows ou sous linux, si du code dans le kernel veut flinguer un périphérique il peut le faire.
          • [^] # Re: Ah? Bientôt un nouveau virus pour windaube?

            Posté par  (site web personnel) . Évalué à 2.

            si du code dans le kernel veut flinguer un périphérique il peut le faire.

            Mouais faut aussi que le matos ai un bug... si tu fais du matos ou un logiciel c'est pareil, tu dois te protéger de mauvais paramètres/conditions... donc si ton kernel peut flinguer du matos, le matos en question est buggé... Bon tu me diras tout matos est buggé... mais il faut plus que vouloir flinguer du matos et être du code en kernel space pour actuellement flinguer du matos.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.