Journal Tails 2.0, l'USB 2/3, les drivers eHCI/xHCI (Retour d'inexpérience)

Posté par . Licence CC by-sa
12
7
fév.
2016

Chers amis, Chères amies,

Ce week-end, je me suis essayé à l'installation d'une Tails 2.0 (une sorte de Debian-Live sur clef USB configurée pour la confidentialité et l'anonymat) en espérant qu'il ne s'agirait comme d'habitude que de copier un fichier par ci et vérifier dans le BIOS que le boot USB a priorité sur le reste.

Avant de poursuivre, un peu de contexte :

Je n'ai utilisé jusque-là Debian GNU/Linux/Gnome (stable et Sid) que pour la bureautique habituelle et la programmation scientifique avec C/python/bash… Ça dure depuis 10 ans et j'en suis satisfait. Pendant tout ce temps, je n'ai utilisé que des outils simples : pas de compilation de modules pour matériels exotiques, pas de construction de paquets Debian pour bénéficier de nouvelles fonctionnalitéss, pas d'imports depuis les dépôts expérimentaux, quasiment tout le système avec les configurations par défaut sans rien comprendre à init System V ou systemd. Bref quasiment aucune notion de programmation système, d'administration, de sécurité. J'ai vaguement entendu parler de confidentialité avec GnuPG, d'anonymat avec TOR/I2P mais je n'ai jamais vraiment pris le temps de me familiariser à ces sujets. L'époque m'a pris de vitesse. Cela devient aujourd'hui une nécessité pour tous. Je souhaite donc combler certaines de mes lacunes.

Lancement de Tails 2.0 sur :

I) Une Clef USB 2 (module noyau ehci_hcd.ko) :

Tout s'est fait très facilement. Le site tails.boum.org est efficace et sa documentation claire et concise, le bureau Gnome est, comme à son habitude, moche (par défaut) et user-friendly et la configuration (optionelle) d'une partition chiffrée de persistance (celle qui contiendra les documents, les .gpg/, .ssh/, .bashrc) est d'une simplicité extrême.

À ce moment là, je me dis "Super !". Les journalistes de Mediapart/Guardian/Spiegel, le Syndicat de la Magistrature, la Quadrature du Net, le Parti Pirate, Telecomix, les Anonymous, le Chaos Computer Club, les Manning/Assange/Snowden en herbe, les anarchistes révolutionnaires, les communistes antigestionnaires, les autonomes insurrectionnels, les altermondialistes, les écologistes libertaires, les alternativistes zadistes, riseup.net, boum.org, guide.boum.org, constellations.boum.org… mais pas que eux… ma mère, ton grand-oncle, nos ami-e-s… tout le monde est capable d'installer en une heure une distribution Tails 2.0 sur une clef USB de 8 Gigas à 5 euros en supermarché… et Résistera à sa façon.

II) Une clef USB 3 (module noyau xhci_hcd.ko) :
Ma clef ne fonctionne qu'à la condition d'être pluguée après avoir booté ma Debian et elle ne fonctionne pas si elle est pluguée avant que le système boot. On peut la faire fonctionner en la dépluguant puis en la repluguant mais cela interdit donc un boot d'une distribution GNU/Linux de type Live-CD comme Debian-Live ou Tails.

Cela ressemble à des bugs évoqués un peu partout sur les forums :
Crappy USB 3.0 support
External USB drive not detected at boot - Intermittent Problem
USB3 boot device lost during system boot
USB 3.0 Harddrive not recognised
Il ne s'agit bien souvent pas que d'USB 3 mais aussi de l'alimentation électrique, la fonction autosuspend, des différences cold vs warm boot… les problèmes se ressemblent mais sont tous un peu différents entre un utilisateur et un autre selon la clef USB, les options du BIOS et le noyau Linux. Certains problèmes sont résolus au hasard sans comprendre pourquoi ça marche, parfois les bugs s'étalent sur des années…

Au final, au bout d'une dizaine d'heures de lecture de forum, apparaissent beaucoup de problèmes inhabituels où la résolution éventuelle ne consiste pas seulement à recompiler un module ou le blacklister en configurant un fichier. Les situations abondent de cas bien plus pervers :
-des problèmes non reproductibles de périphériques USB 3 sur un port USB 3 qui ont parfois un débit USB 2
-des plaintes du noyau "device descriptor read/64, error -71"
-des plaintes du noyau "device not accepting address" qu'on fait disparaitre en éteignant l'ordinateur 10 minutes !? https://paulphilippov.com/articles/how-to-fix-device-not-accepting-address-error
cela va même jusqu'à un type qui soude une alimentation supplémentaire à sa clef USB 3…

À ce moment là, je me dis : "Merde !". Les distributions GNU/Linux sont devenues fonctionnelles out-of-the-box mais l'USB 3 avec le module xHCI semble toujours aussi foireux. Si des linuxiens moyens n'arrivent pas à réparer leurs problèmes alors pleins de nouveaux venus et des curieux de passage vont se décourager… Pourant USB 3.0 existe depuis 2008. Et le driver xHCI date de :

commit 74c6874199af98e602bb7c5fb1beb9cffda98729
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Mon Apr 27 19:52:22 2009 -0700

    USB: xhci: Support xHCI host controllers and USB 3.0 devices.

    This is the first of many patches to add support for USB 3.0 devices and
    the hardware that implements the eXtensible Host Controller Interface
    (xHCI) 0.95 specification.  This specification is not yet publicly
    available, but companies can receive a copy by becoming an xHCI
    Contributor (see http://www.intel.com/technology/usb/xhcispec.htm).

    No xHCI hardware has made it onto the market yet, but these patches have
    been tested under the Fresco Logic host controller prototype.

    This patch adds the xHCI register sets, which are grouped into five sets:
     - Generic PCI registers
     - Host controller "capabilities" registers (cap_regs) short
     - Host controller "operational" registers (op_regs)
     - Host controller "runtime" registers (run_regs)
     - Host controller "doorbell" registers

    These some of these registers may be virtualized if the Linux driver is
    running under a VM.  Virtualization has not been tested for this patch.

    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Est-il en 2016 encore fondamentalement buggué ? Coincidence marrante, le 26 janvier 2016, jour de la sortie officielle de Tails 2.0, il y a eu 8 commits concernant xHCI… Et à l'heure où j'écris, le dernier merge de Linus concerne xHCI aussi :

commit 46df55ceeaf3d28689242de2dd722857b7ea341f
Merge: dacd53c 89140fd
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Feb 6 22:14:46 2016 -0800

    Merge tag 'usb-4.5-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb

    Pull USB fixes from Greg KH:
     "Here are some USB fixes for 4.5-rc3.

      The usual, xhci fixes for reported issues, combined with some small
      gadget driver fixes, and a MAINTAINERS file update.  All have been in
      linux-next with no reported issues"

    * tag 'usb-4.5-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
      xhci: harden xhci_find_next_ext_cap against device removal
      xhci: Fix list corruption in urb dequeue at host removal
      usb: host: xhci-plat: fix NULL pointer in probe for device tree case
      usb: xhci-mtk: fix AHB bus hang up caused by roothubs polling
      usb: xhci-mtk: fix bpkts value of LS/HS periodic eps not behind TT
      usb: xhci: apply XHCI_PME_STUCK_QUIRK to Intel Broxton-M platforms
      usb: xhci: set SSIC port unused only if xhci_suspend succeeds
      usb: xhci: add a quirk bit for ssic port unused
      usb: xhci: handle both SSIC ports in PME stuck quirk
      usb: dwc3: gadget: set the OTG flag in dwc3 gadget driver.
      Revert "xhci: don't finish a TD if we get a short-transfer event mid TD"
      MAINTAINERS: fix my email address
      usb: dwc2: Fix probe problem on bcm2835
      Revert "usb: dwc2: Move reset into dwc2_get_hwparams()"
      usb: musb: ux500: Fix NULL pointer dereference at system PM
      usb: phy: mxs: declare variable with initialized value
      usb: phy: msm: fix error handling in probe.

Ou bien est-ce que ce sont les firmwares des clefs USB qui sont trop pourris ? Est-on condamné à vivre avec des fichiers comme drivers/usb/core/quirks.c et include/linux/usb/quirks.h ? Après le tout logiciel libre (pour certains le BIOS libre) et avant de passer au souhaitable tout hardware libre, j'espère qu'il y aura une phase intermédiaire clef USB hardware/firmware libre… L'USB a fait parlé de lui à l'occasion de Stuxnet/Siemens/les centrifugeuses/l'IRAN, il refera parler de lui, c'est clair.

ps : juste pour être sûr, j'ai vérifié que la clef USB 3 contenant une Debian-Live avait le même souci
ps2 : la clef USB 2 marchait tellement bien que j'ai profité de l'occasion pour installer FreeDos et flasher/updater le BIOS propriétaire donc le problème ne vient probablement pas de là
ps3 : chose amusante, le module noyau xHCI est justement le module à compiler pris en exemple sur kernelnewbies… comme un appel des anciens à Résister en améliorant spécifiquement ce module ?
ps4 : un truc intéressant, ça serait d'avoir l'avis des spécialistes du noyau nous donner leur impression sur cette partie du code

  • # la derniere fois que j'ai eu ca,

    Posté par . Évalué à 3.

    j'ai simplement desactiver l'USB3 dans le bios du PC,
    alors OK je perds en performance, mais toutes les distribs fonctionnent alors correctement.

    • [^] # Re: la derniere fois que j'ai eu ca,

      Posté par . Évalué à 8.

      Pour le boot, probablement aucune perte. Et pendant la session, je ne m'attends pas à copier des blueray quand je boot Tails… donc la faible perf. sur mon portable n'est pas gênante.

      Mais je ne peux de toute façon pas désactiver l'USB 3 dans mon BIOS.

      Le point n'est pas vraiment là. Pour démocratiser l'outil Tails 2.0, on aimerait que l'utilisateur débutant un peu flippé ne soit pas contraint à aller trifouiller trop son BIOS. (il aura tout le temps de devenir utilisateur avancé s'il le souhaite et d'avoir un maximum de libertés, c'est à dire dans ce cas de documentations et d'options). Par ailleurs, on a pas non plus envie de trifouiller le BIOS quand on se met sur le portable d'un-e ami-e (ami-e qui a peut-être des gros fichiers vidéos et photos à transférer et aime bien l'USB 3). Dans le pire des cas, le choix de l'ordre de Boot dans le BIOS devrait être le truc le plus compliqué.

      Si Greenwald a ignoré le tutoriel de Snowden sur GPG, c'est peut-être parce que la technicité est aride/austère/repoussante pour la majorité. Tails doit être aussi simple que son site web tails.boum.org est sobre. Il doit permettre à ceux qui se défendent (et ceux qui contre-attaquent) de protéger leur vie privée (et leur anonymat) pour 5 euros en 1h d'installation… juste le temps de lire la partie Premiers pas.

      Plus généralement, et du point de vue technique, c'est rageant de voir l'USB 3 complètement buggué 8 ans après son introduction.

  • # Fast boot

    Posté par . Évalué à 1.

    J'ai eu le même problème avec l'USB 3 et je l'ai résolu en désactivant fast boot dans l'UEFI.

    • [^] # Re: Fast boot

      Posté par . Évalué à 2.

      Fast boot c'est pas truc spécifique à Windows?

      • [^] # Re: Fast boot

        Posté par . Évalué à 1.

        Non c'est une option dans le BIOS/UEFI qui permet de démarrer plus vite en ne faisant pas certaines initialisations.

  • # Expérience analogue (même problème ?)

    Posté par . Évalué à 0.

    J'ai justement tenté ce dimanche une installation (à la base Ubuntu, mais par la suite j'ai fait différents essais !) sur une nouvelle machine à base de Intel H97. Et cette nouvelle machine n'a pas de lecteur optique donc essais avec lecteur DVD sur USB ou clé(s) USB. Résultat : plantages (freezes) à répétition et le plus loin où j'ai pu aller a été le partionnement… Du coup, peut-être pas le même problème - car cela allait plus ou moins loin (c'est encore plus amusant quand c'est aléatoire, sûr d'y passer la journée !), mais dans la même veine.

    Ah, installation de Windows (DVD sur USB) sans problème - puis divers tests de charge etc…

    "Fastboot" en "disabled" ne change rien dans mon cas. Et pas d'option pour supprimer le support du xHCI dans le BIOS de ma carte (MSI, apparemment, c'est le cas chez Gigabyte, mais je ne sais pas si ça marcherait dans mon cas !).

    Bref, je plussoie, je n'avais pas passé autant de tant sur une machine (pour ne pas y arriver en plus) depuis pas mal de temps !

    • [^] # Re: Expérience analogue (même problème ?)

      Posté par . Évalué à 2.

      Y'a des options "EHCI Hand-off support" et "xHCI Hand-off support" souvent dans les BIOS/UEFI. J'ai jamais trop pigé sur quelle valeur (enabled ou disabled) c'était mieux de mettre ça… À tester chez vous peut-être ?

      • [^] # Re: Expérience analogue (même problème ?)

        Posté par . Évalué à 1.

        J'ai essayé les 4 possibilités de combinaison de ces options. Sans succès. Ce qui devrait être normal, car les versions récentes de Linux gèrent ces modes et ne devraient pas être concernées par ces options. Mais il est vrai que les effets de bords de certaines options du BIOS font qu'il vaut mieux tout essayer (et y passer la journée !)

        Un BIOS open source permettrait certainement d'y voir plus clair aussi à ce niveau…

  • # À ajouter dans la doc ?

    Posté par . Évalué à 3.

    Si le problème n'est pas déjà mentionné dans la doc, peut être serait il intéressant de le faire apparaître, typiquement dans la liste des problèmes connus: https://tails.boum.org/support/known_issues/index.fr.html.

    N'hésitez pas à en parler sur le chan IRC ou sur la liste: https://tails.boum.org/contribute/index.fr.html#talk ou à ouvrir un bug report si celui ci n'existe pas déjà.

    Concernant le problème lui même, le mieux pour qu'il soit corrigé dans Tails, serait qu'il le soit dans Debian. Le noyau fournit par Tails étant celui de Debian (et cela bénéficiera à plus de monde :) ).

  • # Un article de LWN.net du 3 février 2016 sur Tails 2.0

    Posté par . Évalué à 1.

    Un article de LWN.net du 3 février 2016 sur Tails 2.0

    https://lwn.net/Articles/673960/

Suivre le flux des commentaires

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