Ubuntu 17.10 retiré de la circulation à cause d’un problème d’UEFI

Canonical vient de faire disparaître les liens vers la version 17.10 d’Ubuntu sur son site en raison de remontées alarmantes concernant une corruption des UEFI de certains portables de Lenovo, Acer, Dell ou Toshiba.

Il semblerait que le système parviennent à corrompre l’UEFI de ces machines et à empêcher le démarrage de celles-ci sur des périphériques USB.

boot-04-ubuntu

L’UEFI1 est une mise à jour des fonctions et usages du BIOS. Le nouveau système permet beaucoup de choses supplémentaires notamment en matière de sécurité ou en usage réseau. Des outils puissants mais pas forcément simples à maîtriser. On a ainsi connu par le passé des bugs d’UEFI avec des noyaux Linux qui zombifiaient totalement des machines de Samsung.

Aujourd’hui, il semblerait qu’Ubuntu 17.10 pose problème à plusieurs marques et modèles de portables avec une assez grave corruption de leurs systèmes UEFI sur des portables exécutant la distribution. Assez pour que Canonical réagisse en faisant disparaitre les liens de téléchargement de son site.

Il faut dire que le résultat de la corruption est vraiment problématique. En installant Ubuntu 17.10 sur ces portables de marques Lenovo, Dell, Acer ou Toshiba, le système modifie non seulement l’UEFI mais empêche de revenir ensuite sur ces changements. Parmi les points les plus dérangeants, l’impossibilité de démarrer la machine sur un périphérique USB, ce qui empêche de revenir à une autre distribution par la suite… A moins d’extraire le stockage, ou d’avoir un lecteur optique sur son portable. On reste coincé sous Ubuntu 17.10.

Les possesseurs de portables ayant rencontré le problème n’ont pour le moment pas de solution. Vous trouverez plus d’informations techniques sur Linuxium.

Une mise à jour de Canonical devrait résoudre le problème et faire apparaître à nouveau le système sur leurs pages de téléchargement. L’éditeur précise tout de même au passage de ne pas télécharger le système dans cette version sur d’autres plateformes pour le moment. Les précédentes versions ne sont évidemment pas affectées par ce bug.

Une première liste des machines affectées par le bug :

  • Lenovo B40-70, B50-70, B50-80
  • Lenovo Flex-3, Flex-10
  • Lenovo G40-30, G50-70, G50-80
  • Lenovo S20-30
  • Lenovo U31-70
  • Lenovo Y50-70, Y70-70
  • Lenovo Yoga Thinkpad (20C0)
  • Lenovo Yoga 2 11″ – 20332
  • Lenovo Z50-70, Z51-70
  • Lenovo ideapad 100-15IBY
  • Acer Aspire E5-771G
  • Acer TravelMate B113
  • Toshiba Satellite S55T-B5233
  • Dell Inspiron équipés d’un BIOS Insyde Software

Notes :

  1. pour Unified Extensible Firmware Interface
35 commentaires sur ce sujet.
  • 21 décembre 2017 - 12 h 54 min

    En bref, U17.10 se comporte comme Windows naguère, mais de façon involontaire lui -;))

    Répondre
  • 21 décembre 2017 - 13 h 03 min

    J’ai également lu un article là-dessus (à cet instant, cela concernait uniquement un modèle Lenovo).
    C’est un problème très grave, une mauvaise image pour Canonical. Dommage car je trouve Ubuntu 17.10 excellent, j’espère que sera vite réglé et que ceux qui sont impactés pourront récupérer leur PC.

    Répondre
  • yan
    21 décembre 2017 - 13 h 05 min

    D’abord, faites depuis le départ (ces fameuses “interruptions” logicielles du BIOS, Intel a toujours aimé la confusion sur les termes, qui sont des services offerts par ce dernier essentiellement utilisés par windows) un démarrage qui mets des dépendances entre le boot-loader et le système d’exploitation, chose que l’on cherche généralement à éviter (dans la plupart des archi tierces, on ne passe que des infos d’adressage physique du matériel installé servant ensuite à l’initialisation du noyau et/ou des drivers les utilisant) car source de bugs croisés pénibles… et de problèmes de sécurité: Sans ces IntXXh, qui permettaient l’accès aux frappes clavier/stockage/bus PCI, c’est simple: Quasiment aucun virus de boot n’aurait vu le jour (obligation de les ré-écrire pour tous les matériels existants/moindre attrait, car pas placés idéalement en hook des appels OS)!

    Comme des petits malins ont profité de ce pont d’or offert pour faire des véroles chargées avant même l’OS… On a fait l’UEFI pour ajouter le secure-boot! Et tant qu’on y était, on a refondu ces “interruptions” BIOS en services (confusion jusque dans les termes encore chez Intel, qui appelle cela des “protocoles”) UEFI, bien plus nombreux.

    Le problème, c’est que c’est encore une horreur spécifiée par le duo WinTel, qui devait avoir il faut bien le dire quelques vétérans de l’époque DOS à occuper avant la retraite: Ils ont fait un sac de noeud qui n’est pas sans rappeler le pire du DOS (syntaxe du shell UEFI, pendant des lettres de lecteur…), de windows (GUID partout, clarté nulle part) et des spécifications Intel (que même ceux qui utilisent des architectures tierces, mais avec un controleur PCIe ou USB, auront eu le loisir d’apprécier)!

    Bref, le sujet est un tel merdier que même les fournisseurs de BIOS peinent à le maîtriser. Surtout qu’ils sont en réalité devenus des intégrateurs du design de référence d’Intel, EDK2, auquel ils ajoutent surtout leur couche de présentation/menu et configuration.

    Si on ajoute la sécurité (dont on se passerait sans doute encore, au moins si tôt dans le démarrage, s’il n’y avait ces services hautement hackables qui auraient pu être en totalité évités) qui offre a la moindre erreur la possibilité de se briquer, on a le potentiel pour des gags réguliers comme celui ci. Il n’est ni le premier ni le dernier.

    Répondre
  • 21 décembre 2017 - 13 h 34 min

    et après on s’étonne qu’on aime et préconise les pc d’occaz et surtout ceux avec bios legacy
    quand je pense que cette possibilités va disparaître, moi qui louche sur les ryzen mobile…

    l’uefi, ça me rappelle fortement la hadopi
    “si en face on avait des gens compétents et pas enfermés dans une “certaine” “logique”, on ne serait même pas là a en discuter. ça n’existerait pas.”

    Répondre
  • 21 décembre 2017 - 13 h 45 min

    Est-ce réellement la faute de l’OS ou plutôt la faute au constructeur qui embarque une couche UEFI pas fonctionnelle ? Etrangement, le nombre de machines touchées reste lié à un nombre plus que restreint de constructeurs …

    Répondre
  • 21 décembre 2017 - 13 h 58 min

    L’UEFI, c’est le truc juste gonflant, qui bloque le démarrage légitime (sur mon ordi perso ou celui de la famille que je dois dépanner) d’un système d’exploitation concurrent (au pif un Knoppix sur clé USB, une distribution de secours genre SystemRescueCD, Rescatux) et dont la désactivation n’apporte que des avantages par la suite : notamment faire marcher une machine défaillante.

    Répondre
  • 21 décembre 2017 - 14 h 09 min

    @samy: Ne pas confondre UEFI et Secure Boot hein.

    Répondre
  • 21 décembre 2017 - 14 h 12 min

    @Pierre Lecourt:

    Oui, je crois que j’ai désactivé les 2 dernièrement (pourquoi se priver, n’est-ce pas ?) ;)

    Répondre
  • 21 décembre 2017 - 14 h 56 min

    @Jean BRUDER: il y a plusieurs “fournisseurs” de “bios” en effet

    mais il suffit d’une pomme pourrie pour mettre le doute à tous le monde

    la décision de canonical est compréhensible

    à voir si debian à les meme soucis…
    sinon, que les gens attendnet la prochaine lts

    Répondre
  • 21 décembre 2017 - 15 h 26 min

    D’après le rapport de bug, c’est un bug dans un pilote intel:
    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147/comments/160

    Cela n’est pas spécifique à Ubuntu (puisque c’est un bug de pilote), mais c’est vu plus souvent par les utilisateurs d’Ubuntu 17.10 car ils se sont mis à jour il y a peu et que certaines machines neuves y sont sensibles.

    Répondre
  • 21 décembre 2017 - 15 h 28 min
  • 21 décembre 2017 - 15 h 32 min

    Bonjour, je pourrais ajouter l’Acer E1-111 dont le bios est inutilisable après une installation d’Ubuntu, mais version 16.04.03. Essais en légacy, sans sécure boot, usb divers,…etc, mais le bios ne se laisse plus modifier. Donc:
    Plus de possibilité de choix de périphérique de démarrage.
    Plus de prise en compte de changement de disque dur.
    La seule possibilité a été de prendre le même disque, de faire une installation d’Ubuntu 16.04.03 sur une autre machine et de le remonter sur l’Acer. Après quelques heures de recherche, pas d’autre solution. Bref, pas de pire système finalement que ce bios qui s’auto-créé des dysfonctionnements.

    Répondre
  • 21 décembre 2017 - 15 h 43 min

    @liberforce: la première machine Lenovo du rapport de bug est plutôt une bécane gamer plus en vente non ?
    idem pour certain yoga je crois (et les ideapad pas cher de la marque)

    bref, on va les regretter nos bon vieux bios (ou au moins la possibilité du bios legacy) dans pas longtemps

    heureusement qu’AMD revient enfin dans la course

    la concurrence va avoir du bon

    @Eric: ça, c’est pas cool pour un paquet de monde là.

    et ben ça me promet de bon retour après les fêtes ça !
    pfff

    Répondre
  • 21 décembre 2017 - 16 h 02 min

    Pierre il n’existe pas d’option secure boot sur les anciens bios,on peut donc lier secure boot et uefi et declarer que c’est vraiment de la merde ( je rentrerais dans les details si on me le demande ) tech info depuis 30 ans je peux temoigné de la dérive lamentable des fabricants :puce sur les cartouche d’encre,blocage icloud sur iphone au point que méme si vous prouvez que vous avez achetez le produit en boutique avec facture apple refuse de le debloquer,touch ID sur iphone 7 qui rend le tel inutisisable si on le casse lors d’une chute,frp lock chez android,carte wifi en white list sur pas mal de marque qui fait qu’on ne peut meme pas changer de carte wifi quand elle est bancale,etc.
    En résumé les fabricants ont prit le pouvoir et nous vendent des produits dont nous ne somme pas vraiment propriétaire.
    les pires évidemment Apple donc on est que locataire d’un produit dont on ne fait pas du tout ce que l’on en veut.Inpossible de revenir a un ancien firmware qui pourtant marchait bien mieux.inpossible d’installer un soft non agrée.
    Panne totalement admis mais refusé en garantie :
    ex tactile de l’iphone 6+ qui debloque du a une puce de la carte mére.Panne systématique de ce modéle qui en france s’appelle un un default caché et n’a pas de limite en garantie mais qui chez apple se facture 181,10 euros avec garantie de seulement 3 mois pour :
    Apple a déterminé que certains iPhone 6 Plus pouvaient présenter des problèmes de clignotement de l’écran ou des problèmes liés au Multi-Touch après avoir subi plusieurs chutes sur une surface dure, suivies ultérieurement d’autres contraintes.

    la verité c’est que le chassis du 6+ est trop peut rigide et que méme sans aucune chute la deformation du a une utilsation normale dans sa poche peut provoquer le désoudage de cette puce !
    preuve ça n’arrive pas du tout au 7+ au chassis renforcé.

    les fabricants se foutent vraiment de la gueule du monde,quand allons nous réagir !!

    Non a l’uefi et a toute ces merdes qu’il nous sortent en ce moment .

    Répondre
  • 21 décembre 2017 - 16 h 17 min

    @qtx49: Ce que je veux dire c’est qu’une évolution du BIOS est nécessaire… Et qu’on peut imaginer un UEFI sans Secure Boot ou mode Legacy et surtout garder la possibilité de le désactiver.

    Répondre
  • 21 décembre 2017 - 17 h 16 min

    @Eric: Oui car le problème est lié au kernel 4.10 présent dans 16.04.3 aussi.

    Répondre
  • 21 décembre 2017 - 17 h 17 min

    C’est un peu HS, mais tout cela ne relance-t-il pas le débat sur libreboot et coreboot ? Au moins, quand c’est libre, c’est pas moins sécurisé et lors d’un bug de cette gravité, c’est souvent bien suivi par la communauté.

    Répondre
  • 21 décembre 2017 - 17 h 42 min

    @Pierre Lecourt:
    L’UEFI n’est pas une évolution positive: Comparer le volume de sources EDK2 et comparer au kernel Linux. C’est du même ordre de grandeur. Ce truc, c’est un OS mal branlé pour booter le vrai OS.
    C’est si lent qu’avec un SSD, désormais on passe souvent plus de temps dans le BIOS qu’a démarrer l’OS complet. A un point que j’avais vu il y a qq mois que certains avaient strippé un UEFI de serveur pour ne conserver que la partie inits de base (processeur/DDR) et faire faire le reste par un noyau Linux (et ses drivers) allégé au maximum pour tenir dans la place libérée dans la SPI: De mémoire ils passaient de plus d’une minute à démarrer via un BIOS AMI (avec optimisations spécifiques, mais vu la suite il reste de la marge!)… à 5s!
    Et en prime les drivers Linux sont à jour contrairement à ceux embarqués dans les EFI ou les ROM des périphériques.

    Répondre
  • 21 décembre 2017 - 17 h 53 min
  • 21 décembre 2017 - 18 h 23 min

    @yann: C’est pas ce que je dis… Je dis que le BIOS n’est plus possible. Il faut une autre alternative. Pour le moment on a l’UEFI. Si une alternative se profile, on verra vers quoi on pourra aller.

    Répondre
  • 21 décembre 2017 - 18 h 33 min

    Bah…. un sorte de Kickstart comme sous Amiga? OK, je sors!

    Répondre
  • 21 décembre 2017 - 22 h 19 min

    @Pierre Lecourt: Je crois que le lien de @Graveen est très intéressant à suivre. Si j’ai bien compris, NERF est un dérivé de coreboot, sorte de BIOS open-source, et réussi à se débarrasser d’Intel ME, qui dérange pas mal de personnes.

    Toujours si j’ai bien compris, on tient peut-être l’alternative à UEFI, en tout cas, je l’espère.

    Répondre
  • 21 décembre 2017 - 22 h 41 min

    @Pierre Lecourt:

    Merci d’expliquer vos propos: “Je dis que le BIOS n’est plus possible. Il faut une autre alternative.”???

    Répondre
  • 21 décembre 2017 - 23 h 09 min

    @AlexP: Les BIOS ont beaucoup de limitations techniques : Stockage moderne de grande capacité, 64 bits en standard, réseaux déployés, sécurité en entreprise, gestion graphique… Il faut une alternative plus moderne. Que ce soit l’UEFI ou autre chose.

    Aujourd’hui c’est l’UEFI mais ce n’est pas une norme, juste une alternative. Il pourrait y en avoir d’autres.

    Je serais de curieux de connaitre quels matériels tournent encore aujourd’hui en BIOS.

    Répondre
  • 22 décembre 2017 - 8 h 21 min

    @prog-amateur:
    C’est à ce projet que je faisais pour ma part allusion dans mon précédent message. Maintenant, si Linux saurait parfaitement se passer de tout service UEFI (c’est la cas sur quasiment toutes les architectures alternatives, même si des masochistes commencent à mettre de l’UEFI sur ARM…) y compris sur x86, windows non. Et je ne pense pas qu’ils veuillent évoluer car cela a toujours été un moyen de verrouiller la plateforme et d’emmerder les alternatives que de coller cette dépendance problématique évitée comma la peste partout ailleurs.

    Répondre
  • 22 décembre 2017 - 10 h 30 min

    Salut,
    Nous savons, à l’heure actuelle, que dans le cas d’un EUFI où le secure-boot est obligatoirement activé, pour la sécurité des ordinateurs, les drivers des différentes cartes doivent alors obligatoirement être signées par une clé signature, celle-ci officiellement validée par Microsoft, et ceci pour les ordinateur vendus au grand-public.(UEFI 3+)
    Les périphériques ne seront pas alimentés quand le secure-boot est désactivé dans l’EUFI.
    Les clés de signatures sont soumises par les éditeurs de drivers, validées par ms.
    Il n’existe actuellement aucune clé signature linux émanant de nVidia ou même de Broadcom pour faire fonctionner les périphériques, comme l’écran géré par la carte graphique ou le wifi.
    De plus le matériel intel, à partir de 2020, ne fonctionnera qu’avec un secure-boot obligatoirement activé…

    Répondre
  • 22 décembre 2017 - 11 h 05 min

    Se passer du bios, de l’EUFI, comme vous y allez ! Ces usines a gaz n’ont pas été créées seulement à cause de la volonté d’Intel et d’ M$ de casser les pieds à tout le monde pour faire plus de thune. A la base le bios est une procédure d’autotest et d’allocation des ressources de la machines, car sous intel/ms je vous rappelle que toutes les machines sont différentes, à tel point qu’on est en droit de trouver remarquable qu’au final cela puisse fonctionner.

    Alors je rejoins Pierre en disant que bios ou EUFI de toute manière il y a des fonctions indispensables préalables au lancement d’un système.

    A ce sujet Pierre devrait :) parler prochainement d’un portable pc Schneider dont le bios est incroyablement complet, amical et particulier pour les linuxiens qui ont même des entrées spécifiques pour la prise en charge de leur système préféré.

    Enfin la signature, à la base c’était pour empêcher les écrans bleus au démarrages de périphériques fabriqués avec les pieds, après ce que certains constructeurs en ont fait est un dévoiement d’une technologie pas sensé être utilisée pour censurer les utilisateurs.

    Répondre
  • 22 décembre 2017 - 11 h 50 min

    @yann: exactement, je ne maîtrise pas complètement le sujet mais après m’être renseigné au sujet du verrouillage, il semblerait que c’est à la fois logiciel mais aussi matériel.

    C’est là qu’on peut faire un raccourci de type Wintel > 2 mastodontes privés Windows/Intel > systèmes (dont UEFI) fermés. Pour eux, comme pour AMD dernièrement, il n’y a aucun intérêt à rendre libre quoi que ce soit, bien au contraire. Par exemple, pour la partie matérielle, l’Intel ME (pour Management Engine), est une puce installée par défaut depuis 2008 et permettant d’accéder entre autres à la mémoire, au clavier, à l’écran, et à envoyer des informations via le net sans que le processeur/l’OS/l’utilisateur ne puissent être au courant. Cela peut se faire même ordinateur éteint ! AMD fait pareil depuis 2013. Pourquoi ?… En tout cas, ça fait potentiellement un paquet d’informations personnelles ou d’entreprises vendables à des organismes intéressés.

    Heureusement, quelques entreprises qui font de la confidentialité leur cheval de bataille, comme la société Purism, ont réussi à désactiver la puce gérant l’Intel ME via le Coreboot (une alternative libre à l’UEFI, mais qui contient à la base quelques parties logicielles propriétaires). Même System76 travaillent à désactiver l’Intel ME.

    Pour en revenir à la partie logicielle, un français bosse sur un projet appelé NERF (pour Non-Extensible Reduced Firmare), une alternative ouverte comparée à UEFI, et basée sur Coreboot. Le but est de “remplacer le firmware UEFI par un kernel Linux léger”.

    Apparemment, le gars dit que depuis cette semaine, il a réussi la partie Desktop/Portable, en revanche, la partie Serveurs est plus difficile à gérer, et il espère arriver à faire des serveurs x86 totalement ouverts.

    Si Google s’y intéresse personnellement, et si les développeurs veulent transformer le terme NERF en “Linuxboot”, c’est que le projet devient sérieux. J’espère que ça sera possible, et que la désactivation de l’Intel ME sera démocratisée au moins pour cette génération de cartes mères.

    Répondre
  • 22 décembre 2017 - 11 h 56 min

    @prog-amateur: Juste pour info : UEFI est compatible ARM et a été pensé comme tel.

    Répondre
  • 22 décembre 2017 - 18 h 47 min

    @Pierre Lecourt:
    AMHA, il faut être maso pour prendre cela sous ARM. Que Microsoft en aie besoin car leur système a besoin des runtime services UEFI, pourquoi pas… Mais les autres ont intérêt à éviter cet immondice. C’est pas les boot loader industriels qui manquent sur cette architecture.

    Répondre
  • 22 décembre 2017 - 19 h 03 min

    @yann: Je dis pas le contraire. Je donne juste des infos pour que l’on comprenne bien ce qui est en jeu ici.

    Répondre
  • 22 décembre 2017 - 19 h 58 min

    @Pierre Lecourt: je ne maîtrise pas le sujet. Je veux bien comprendre que l’UEFI a été fait pour ARM mais sur quel point cela entre en contradiction avec mon monologue ^^ ?

    Répondre
  • 22 décembre 2017 - 20 h 35 min

    @prog-amateur: Juste que l’UEFI a été pensé d’une manière ouverte et que des constructeurs en font autre chose. Ce n’est pas forcément la faute du format. Un peu comme les gens qui disent que le MP3 sert à pirater alors que ça sert a compresser. Tu vois ce que je veux dire ?

    Si à la sortie des premières solutions UEFI secure-boot restrictives (sans possibilité de les désactiver) il y avait un refus massif des acheteurs, crois moi, ça s’arrêterait là.

    Il faut distinguer le format UEFI, une nécessaire évolution qui n’a pas d’alternative, de ce que certains en font.

    Répondre
  • 22 décembre 2017 - 23 h 23 min
  • 23 décembre 2017 - 0 h 10 min

    @Pierre Lecourt: Merci beaucoup, c’est un sujet qui fait couler beaucoup d’encre en ce moment, et j’aime bien la vulgarisation. Ton lien va m’aider à en savoir plus !

    Répondre
  • LAISSER UN COMMENTAIRE

    *

    *