Lors de leur keynote à l'Open Source Summit 2024, Linus Torvalds et Dirk Hohndel ont échangé sur l’avenir des architectures matérielles libres, en particulier RISC-V. Linus, avec son franc-parler habituel, a partagé ses craintes et ses espoirs concernant l’évolution de RISC-V et le rôle crucial que peuvent jouer les communautés open source pour éviter les erreurs passées, notamment dans le développement des plateformes comme ARM et x86.

Linus estime qu’il existe un risque majeur que RISC-V répète les erreurs commises par les architectures précédentes, comme lorsqu’ARM est devenu une plateforme serveur et a ignoré en partie les leçons apprises lors du développement de l’architecture x86, notamment en matière de sécurité. Cependant, il reconnaît également que grâce à l’expérience accumulée, ces erreurs ont été corrigées plus rapidement. La question cruciale est à présent de savoir si RISC-V saura tirer parti de cette expérience collective pour éviter ces écueils ou s’il devra traverser les mêmes cycles d’apprentissage douloureux.

Leçons du passé et rôle des logiciels libres

Les erreurs évoquées par Linus sont multiples. Il parle notamment des problèmes de compatibilité et d’interopérabilité qui ont compliqué l’adoption de nouvelles architectures matérielles. Il mentionne également le manque de communication entre les concepteurs de matériel et les développeurs de logiciels, créant un fossé qui ralentit l’innovation et entraîne des inefficacités. Enfin, il rappelle que les délais nécessaires pour corriger les erreurs matérielles sont bien plus longs que pour les logiciels, ce qui peut freiner l’évolution des nouvelles technologies.

Cependant, l’open source présente une opportunité unique pour surmonter ces obstacles. Une architecture matérielle ouverte comme RISC-V permet une transparence totale, où les développeurs de logiciels peuvent intervenir dès les premières phases de conception pour s’assurer que les erreurs du passé ne se reproduisent pas. Cette collaboration précoce entre développeurs matériels et logiciels est essentielle pour anticiper et résoudre les problèmes avant qu’ils ne deviennent des obstacles majeurs.

L’open source a déjà prouvé sa valeur dans le domaine des logiciels en offrant une flexibilité et une adaptabilité incomparables. Cette même philosophie appliquée au matériel peut accélérer l’innovation et permettre de répondre plus rapidement aux besoins du marché. De plus, une communauté ouverte permet de partager les connaissances et les meilleures pratiques, réduisant ainsi les risques de répéter les erreurs passées.

Sécurité et architecture matérielle open source

Un point crucial soulevé par Linus concerne la sécurité, en particulier les défis posés par les failles matérielles et les attaques par canal auxiliaire. Ces vulnérabilités résultent souvent des optimisations dans le silicium, comme l'exécution spéculative, qui peuvent être exploitées pour compromettre la sécurité des systèmes.

Linus a exprimé sa frustration face à la nature secrète des processus de gestion des failles de sécurité dans le domaine du matériel. Il a souligné que cette opacité empêche de travailler en toute transparence sur ces problèmes intéressants et techniques. Une architecture matérielle open source, comme RISC-V, pourrait potentiellement atténuer ces frustrations en permettant une collaboration ouverte dès le début, facilitant ainsi la détection et la correction rapide des vulnérabilités.

L’open source offre également un modèle de confiance basé sur la transparence et la vérification par les pairs. Dans le contexte de la sécurité, cela signifie que les failles peuvent être identifiées et corrigées plus rapidement grâce à une surveillance continue et à une coopération étroite entre les développeurs de matériel et de logiciels.

La vision d’un avenir open source pour le hardware

L’un des points forts de l’open source est sa capacité à démocratiser l’accès à la technologie. Avec des projets comme RISC-V, il est possible de voir émerger des solutions matérielles qui ne sont pas seulement le produit de quelques grandes entreprises, mais le fruit d’une collaboration globale. Cela peut mener à des avancées significatives non seulement en termes de performances, mais aussi de coûts et d’efficacité énergétique, en offrant des alternatives viables aux architectures propriétaires.

Linus Torvalds a également évoqué l’évolution des pratiques du développement du matériel. Il y a dix ans, il était difficile de passer de x86 à une autre plateforme, mais aujourd’hui, grâce à l’open source, la transition est beaucoup plus fluide. Les utilisateurs finaux ne se soucient plus de savoir si leur serveur fonctionne sur un processeur Intel, AMD ou ARM ; ce qui compte, c’est que l’infrastructure logicielle soit solide et interopérable.

Pour que RISC-V réalise pleinement son potentiel, il est donc crucial que les communautés du logiciel et du matériel libres continuent de favoriser une culture de partage et de collaboration. Les développeurs de logiciels doivent être encouragés à s’impliquer dans le processus de conception matérielle, et vice versa. En travaillant ensemble, ils peuvent s’assurer que les erreurs du passé ne se reproduisent pas et que les nouvelles technologies répondent aux besoins réels du marché.

S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) est un système de surveillance intégré aux disques durs modernes et aux disques SSD. Il évalue en continu le bien-être du périphérique tout en anticipant les éventuels dysfonctionnements. Il utilise une réserve de secteurs de rechange pour réparer quand il détecte un secteur en anomalie.
Le programme Linux badblocks teste les blocs d’un média par écriture+relecture+comparaison. À l’origine il servait à mettre les blocs mauvais en liste noire dans le file-system.

Est-il utile de nos jours de vérifier ses médias ?
Comment se situe S.M.A.R.T. par rapport à l’outil badblocks ?
Comment vérifier un média en tenant compte de sa surveillance par S.M.A.R.T. ?

C'est ce que nous allons voir dans la suite de la dépêche.

Sommaire

• Préambule
• S.M.A.R.T.
• BADBLOCKS
• BADBLOCKS2
• En pratique
  • Si S.M.A.R.T. n’est pas sur le média
  • Si S.M.A.R.T. est sur le média

Préambule

Quelle précaution prendre vis-à-vis du risque de mauvaise qualité du stockage, quand je viens d’acheter un média (disque SSD, disque rotatif, clé USB, carte SD) ou un appareil sous Linux équipé d’un espace de stockage dont j’ignore la technologie ?
Sans être parano, je me dis qu’avant d’envoyer des données précieuses sur l’espace de stockage, c’est le moment de faire certaines vérifications. Mais quelles vérifications ? Qu’est-il possible de faire ?

Sur un média connectable, tout est possible.
Sur un appareil neuf sans système ni données, tout est possible en utilisant une distrib Live.
Sur les autres, ça dépend, il y en a où on n’a même pas un accès root pour lancer une vérification « dure » ou « molle » (Android, routeur…).

En écrivant cet article, je me suis rendu compte que je ne me suis jusqu’ici jamais posé de questions sur l’opportunité de vérifier les espaces de stockage de mes téléphones, PC portables, routeurs, box… bref tous les appareils vendus prêts à être utilisés. Pourtant, que sais-je de la vérification faite par celui qui a installé le système ? Rien, et j’utilise, sans penser que l’espace de stockage de l’appareil n’est ni plus ni moins robuste que celui du PC Linux que j’ai installé dernièrement, mais que j’ai vérifié consciencieusement.

S.M.A.R.T.

S.M.A.R.T. est un système de surveillance intégré aux disques durs modernes et aux disques SSD. Il évalue en continu le bien-être du périphérique tout en anticipant les éventuels dysfonctionnements. Il surveille un maximum de paramètres (température, temps de fonctionnement, vitesse de rotation pour les disques magnétiques, nombre de démarrages et d’arrêts…) et dépend de l’expérience du fabricant. La réparation de secteurs utilise une réserve de secteurs et le mapping entre secteurs logiques et secteurs physiques.

On pourrait se dire que, de nos jours, les supports sont fiables et testés par les intégrateurs. D’autres considèrent que la technologie S.M.A.R.T. suffit… et c’est bien commode de ne plus se soucier de la fiabilité des supports de stockage. Mais à la première galère due à un média défaillant, tu évolueras dans ta confiance.

Sais-tu seulement sur lesquels de tes médias S.M.A.R.T. est installé et actif ?
Si tu utilises un RaspberryPi, ton média système est… une carte SD. Elle n’a pas S.M.A.R.T.. Idem pour l’extension de mémoire que tu as ajoutée à ton téléphone.

Je t’invite à lire la page Wikipedia sur S.M.A.R.T. et son paragraphe « Standard, implémentation et limitations ». Que fait et que ne fait pas le S.M.A.R.T. qui fonctionne sur le disque du PC qui te permet de lire cet article ? Difficile de savoir. Comment est-il configuré ? Fais un sondage autour de toi à ce sujet et tu seras pris pour un parano.

Sur ton PC, sais-tu qu’il y a une option S.M.A.R.T. dans le BIOS (ou UEFI) ? Sais-tu qu’il y a un service smartd dans ton Linux ? As-tu compris aussi qu’avec du RAID il n’est pas toujours opportun d’activer S.M.A.R.T. ? Les communications entre S.M.A.R.T. RAID et l’O.S. peuvent se passer plus ou moins bien selon la qualité de ces éléments. Il te faut bien comprendre ce qu’il est possible de paramétrer et deviner comment ça marche derrière.

Si tu demandes une vérification à S.M.A.R.T. par smartctl, sais-tu ce qu’il fait ? Se contente-t-il de lire ou fait-il un test en écriture ?

Enfin, quand S.M.A.R.T. détecte qu’un secteur est devenu défectueux, il ne peut pas deviner quels bits sont défaillants, aussi il renseigne le secteur de secours avec ce qu’il peut, qui est l’état du secteur après défaillance. S.M.A.R.T. a ses limites, il répare comme il peut. S’il est configuré pour, il alerte quand il prévoit de la défaillance, mais sais-tu reconnaître ses alertes ? As-tu compris ce que tu dois faire en réponse aux alertes ?

Je t’invite à apercevoir la complexité de prise en main de S.M.A.R.T. en faisant quelques recherches sur ces listes de mots :

smartctl howto
smartctl configure self test
smartd howto

et tu verras que ce n’est pas simple à comprendre et à configurer.

Tu peux te dire naïvement que tout est bien configuré par défaut et que tes médias seront toujours impeccables. Sinon, il va falloir investir en temps et faire quelques essais. À toi de choisir.

S.M.A.R.T. est une belle avancée technologique, mais il est dangereux de lui attribuer des mérites indus.

BADBLOCKS

Le programme Linux badblocks a été créé en même temps que le paquetage e2fsprogs (mkfs.ext2, mkfs.ext3, mkfs.ext4, fsck.ext2…). À l’époque S.M.A.R.T. n’existait pas et il n’y avait pas de mapping entre les adresses logiques et physiques. C’est le file-system qui devait tout gérer quand il détectait un bloc défectueux, notamment la mise du bloc en liste noire. C’est pour cela que mke2fs et e2fsck lancent un badblocks « dur » quand on leur spécifie deux fois l’option -c. Cela dure trèèès longtemps car les paramètres par défaut ne sont plus bien optimisés.

Depuis l’arrivée de S.M.A.R.T., certains considèrent badblocks comme obsolète. Mais qui peut affirmer que TOUS les médias utilisés par TOUS les usages de Linux sont équipés de S.M.A.R.T. ?
Peut-être qu’au M.I.T. avec un réseau de classe A, on ne s’abaisse pas à utiliser une clé USB ou un RaspberryPi. Je me demande dans quel type de bulle vivent ceux qui pensent que S.M.A.R.T. est sur tous les médias de stockage.

Quand j’achète une clé USB, je lui passe badblocks dessus et s’il y a des mauvais blocs, je la rends et je me fais rembourser.
J’ai essayé d’interroger les fonctionnalités S.M.A.R.T. de diverses clés USB et je n’ai rien obtenu, comme si cette utilité n’y était pas installée :

# smartctl --scan-open
# smartctl -x /dev/sdc
# smartctl -i -d scsi -T verypermissive /dev/sdc

Mes recherches sur Internet n’ont abouti à rien qui me permette de voir une réponse de la part de clés USB. Peut-être que si j’achetais (cher) des clés USB de très haute qualité, j’y trouverais S.M.A.R.T. ?

Comme l’intervenant du message #25 de ce rapport de bug (en), je pense que badblocks est loin d’être obsolète.
J’ai envie d’imiter le message #20 juste au-dessus en disant : « Je dois demander --- ***pourquoi*** vous (et d’autres personnes) mettez de l’essence dans vos voitures en 2024 ? L’essence en tant que chose a commencé à devenir inutile pour les voitures vers 2011, lorsque la voiture électrique s’est répandue, et que les batteries sont devenues suffisamment énergétiques pour faire rouler des véhicules sur des centaines de km ».

Je t’invite aussi à une recherche sur la liste de mots « courbe en baignoire composants électroniques ». Le programme badblocks peut servir au déverminage. On sait en détail ce qu’il fait. Son résultat est clair, contrairement aux implémentations propriétaires de S.M.A.R.T..
Sans déverminage (rodage) on court le risque de subir trop tôt une réparation discrète incomplète : le secteur réparé sera physiquement bon mais son contenu sera corrompu. La conséquence peut être catastrophiquement discrète. Par exemple, un fichier LibreOffice est une archive zip (compressée), la corruption d’un seul bit y a des conséquences imprévisibles.

De mon côté, j’utilise badblocks pour tester les médias nouvellement acquis et pour effacer ceux bons à réformer. Ce programme permet aussi la chasse aux médias « fake-size », du genre carte SD de 1To qui accepte de recevoir 1To de fichiers, mais qui ne stocke en réalité que 8Go. On trouve de nos jours (juin 2024) des clés USB de 16To vendues au prix de 5 € ! L’application h2testw sous windows et son équivalent f3 sous linux sont spécialement conçus pour cette chasse. Le microprogramme de ces clés USB ou de ces disques a été détourné pour déclarer un espace de stockage falsifié. C’est de l’escroquerie.

BADBLOCKS2

Mon usage du badblocks du paquetage e2fsprogs-1.47.0 m’a amené à y caractériser un bug reproductible en novembre 2023. J’ai eu l’intention de remonter le bug aux équipes ad hoc de ma distribution (Mageia) mais je me suis d’abord mis à regarder le source.

J’y ai trouvé l’origine du bug, et j’ai trouvé d’autres bugs. En ajoutant des instructions de traçage et de simulation d’erreurs du média, j’ai mis en évidence encore d’autres bugs. De fil en aiguille, j’ai fini par retoucher profondément certains algorithmes, et j’ai appelé badblocks2 cette nouvelle version. J’y ai ajouté diverses options faciles à programmer et commodes à l’usage. J’ai copieusement testé.

Si tu veux essayer badblocks2 et/ou prendre connaissance de ma démarche, je livre tout sur mon site. Tu verras pourquoi je me suis rabattu sur la création d’une nouvelle version, plutôt que de faire remplacer l’ancienne (ce qui aurait profité à tous).
Tu peux te faire une idée des fonctionnalités ajoutées en consultant les *.8.txt .
Tu peux t’inspirer des tests décrits dans le fichier Alire.txt, tester diverses valeurs pour -c -t et voir l’effet sur la vitesse de traitement. Tu peux même jouer à arracher la clé en cours de test (Ctrl-C pour arrêter) !

J’espère que ce programme servira à d’autres que moi.

En pratique

Voici une suggestion d’actions à faire lors de l’acquisition d’un nouveau média (disque SSD, disque rotatif, clé USB, carte SD…). Les commandes doivent être lancées par l’opérateur root.
Avec cela, quand dans quelques années tu satureras le média, tu seras sûr que le dernier secteur utilisé aura été déverminé avant la mise en production.

ATTENTION : les usages de badblocks proposés sont destructifs pour les données présentes sur le média. Le mode non-destructif du badblocks actuel comporte des bugs (version e2fsprogs-1.47.0). Celui de badblocks2 a été corrigé.
ATTENTION : la liste des mauvais blocs renvoyée par le badblocks actuel est fausse (version e2fsprogs-1.47.0). Le nombre de mauvais blocs est correct. La liste renvoyée par badblocks2 est correcte.
ATTENTION : le paramètre device du média est supposé être /dev/sdc. Ne pas se tromper, au risque d’effacer un autre média en cours d’usage.

D’abord déterminer le block-size du noyau, c’est une bonne valeur à prendre comme block-size du file-system :

# blockdev --getbsz /dev/sdc

Dans ce qui suit, je suppose que la valeur 4096 a été renvoyée.

Ensuite déterminer si S.M.A.R.T. est sur le média :

# smartctl --scan-open
# smartctl -x /dev/sdc
# smartctl -i -d scsi -T verypermissive /dev/sdc

Si S.M.A.R.T. n’est pas sur le média

Passer badblocks2 pour voir s’il y a 0 ou peu de mauvais blocs :

# badblocks2 -b 4096 -c 32768 -wrrvvss -t r -t r -e 40 -o /tmp/sdc.bb /dev/sdc

L’option -e peut être supprimée ou modifiée selon la limite du nombre de mauvais blocs considérée acceptable ; les options -t peuvent être différentes selon la sévérité souhaitée (voir le man).

S’il y a trop de mauvais blocs, refuser d’utiliser le média (->garantie ?).

S’il y a 0 mauvais bloc on peut formater en toute tranquillité (partitionner éventuellement avant) :

# mkfs.ext? -b 4096 ... /dev/sdc

S’il y a quelques mauvais blocs, sans que la limite -e soit atteinte, on pourra formater en utilisant la liste sauvée de mauvais blocs :

# mkfs.ext? -b 4096 -l /tmp/sdc.bb ... /dev/sdc

Si l’on veut partitionner, il faudra recalculer la liste des mauvais blocs de chaque partition avant de formater (remplacer sdc par sdc1 dans les commandes badblocks2 et mkfs.ext? ci-dessus).

Si l’on veut formater en vfat exfat ou f2fs (clés USB en général), il n’est pas possible d’utiliser la liste des mauvais blocs détectés ; la seule solution est de refuser d’utiliser le média s’il y a des mauvais blocs (ou alors de restreindre l’usage à une zone saine… à localiser)

Si S.M.A.R.T. est sur le média

On peut vérifier son activation par smartctl :

# smartctl -i /dev/sdc

Ensuite, il faut interroger le média sur l’état et les capacités de son S.M.A.R.T. :

# smartctl -a /dev/sdc

Noter le nombre de réallocations faites et prévues :

# smartctl -a /dev/sdc | grep -i _sector

Puis faire une passe de déverminage, en écriture+lecture car on ne sait pas si l’écriture seule suffit ; ne pas utiliser l’option -p de badblocks ; les options -t peuvent être différentes selon la sévérité souhaitée (voir le man) :

# badblocks2 -b 4096 -c 32768 -wrvvss -t r -o /tmp/sdc.bb1 /dev/sdc

Faire une passe de vérification, il ne devrait plus y avoir de mauvais blocs :

# badblocks2 -b 4096 -c 32768 -wrvvss -t r -o /tmp/sdc.bb2 /dev/sdc

S’il y a encore des mauvais blocs, c’est soit que le déverminage n’est pas terminé, soit que le média et/ou son S.M.A.R.T. sont foireux (il ne détecte pas les mauvais secteurs vus par badblocks2 ou les secteurs de réserve sont mauvais ou… pire) ; relancer des passes une par une jusqu’à ce qu’il n’y ait plus de mauvais bloc détecté.

Re-interroger S.M.A.R.T. pour voir l’évolution des réallocations :

# smartctl -a /dev/sdc | grep -i _sector

Ensuite on peut formater (partitionner éventuellement avant) en considérant que le média a remappé tous ses mauvais secteurs et est donc impeccable pour l’utilisation :

# mkfs.ext? -b 4096 ... /dev/sdc

Par la suite, on pourra de temps en temps consulter l’état de santé du média en service :

# smartctl -H /dev/sda

Si on est courageux, on peut lancer de temps en temps un contrôle du média par son S.M.A.R.T.
Si on est encore plus courageux, on configurera smartd pour que ces vérifications soient automatiques et pour que les alertes soient envoyées par courriel.

Attention à la communication entre l’O.S., S.M.A.R.T. et RAID (niveau carte mère / niveau OS / contrôleurs bas de gamme), voir la page Wikipedia sur S.M.A.R.T..

Que l’esprit « aware » soit en toi, sur tes données et sur ton espace de stockage

Degate est un logiciel libre pour faire de l'ingénierie inverse sur les processeurs.

Pour le présenter, Dorian Bachelot, mainteneur du projet, a accepté de répondre à nos questions.

Sommaire

• Présentation
• Entretien avec Dorian Bachelot
  • Présentation
    • Qui êtes-vous ? Quel est votre parcours ?
    • Est-ce que vous êtes parent de Roselyne ?
    • Qu’est-ce que Degate ?
    • Pourquoi dis-tu que c’est le seul bastion ?
    • Comment ça fonctionne ?
    • Il existe des protections contre ceci ? J’imagine que certaines entreprises n’aimeraient pas qu’on fasse de la retro-ingénierie sur leur puce, il me semble que certaines puces possèdent un genre de grillage.
    • Est-ce que les différentes façons de gravure qui utilise différent MOSFET (CMOS, FinFET, MBCFET, FD-SOI etc) ne demandent pas des analyses différentes ? Est-ce que ça sera fiable avec les derniers types de gravure avec des transistors imbriqués 3D ?
    • Qui se sert de Degate ? Est-ce une communauté de fans de consoles ou des professionnels confrontés à des puces qui ne sont plus documentées ou des gens du logiciel libre, etc. ?
    • Concernant la sécurité, quels types de puces sont concernées ? J’imagine qu’il ne s’agit pas d’analyser les processeurs généralistes de nos ordinateurs… Ce sont des puces qu’on trouve dans quels matériels ?
    • Comment en êtes-vous devenu le mainteneur ?
    • Tu n’utiliseras donc pas Degate dans le cadre de ton travail ?
    • Quelle est ta motivation ? Qu’est ce qui t’anime avec Degate ? Puisque tu as commencé l’informatique assez jeune, tu jouais peut-être avec des consoles ; est-ce que Degate te permet aussi d’imaginer recréer les puces de ton enfance ?
    • Est-ce que vous tirez un revenu de ce travail ? Est-ce une bonne wafer ?
  • Pour finir
    • Que dire sur vos autres projets ?
    • Que pensez-vous de la directive NIS 2 sur la cybersécurité ?
    • Au niveau personnel, quels logiciels libres utilisez-vous, sur quel OS ?
    • Au niveau professionnel, quels logiciels libres utilisez-vous, sur quel OS ?
    • Quelle est votre distribution GNU/Linux préférée et pourquoi, quels sont vos logiciels libres préférés ?
  • Références

Présentation

Entretien avec Dorian Bachelot

Présentation

Qui êtes-vous ? Quel est votre parcours ?

C’est sûrement très « bateau », mais comme beaucoup je suis avant tout un passionné d’informatique et d’électronique. J’ai commencé à programmer dans mes années collège (début des années 2010) et suis rapidement arrivé à découvrir Linux ainsi que d’autres galaxies (C++, git, virtualisation, reverse engineering…). Par la suite j’ai eu la chance de réaliser un diplôme d’ingénieur à l’ESIEA (école d’ingénieur généraliste sur Laval) qui m’a permis de découvrir de nombreux domaines comme l’électronique embarquée, la cybersécurité et l’intelligence artificielle. Comme beaucoup, j’ai un faible pour les domaines complexes et devoir me limiter à une seule spécialité pour mes études ne m’allait pas trop. C’est sur ce dernier point que démarre l’aventure Degate au côté du laboratoire de recherche en cybersécurité de mon école. Cette dernière proposait en effet un format « espoir recherche » permettant de creuser un sujet de recherche en plus des cours. Mon sujet a justement porté sur Degate, puisque comme nous allons le voir la rétro-ingénierie matérielle a l’avantage de toucher autant à l’électronique, qu’à la physique, la cybersécurité et l’intelligence artificielle !

Quant à aujourd’hui, après avoir travaillé sur le sujet de la rétro-ingénierie matérielle pendant presque 3 ans (en publiant 5 articles dans Hackable et en travaillant sur Degate) et avoir obtenu mon diplôme, je suis Tech Lead R&D Cyber/IA chez Neverhack (on vient de lever 100 millions d’euros). J’ai pu en effet garder une dualité de spécialité, à travers la cybersécurité et l’intelligence artificielle, principalement grâce à cette aventure d’espoir recherche (et donc en partie de Degate) ¹.

Est-ce que vous êtes parent de Roselyne ?

Et non, du tout, mais bien vu ;)

Qu’est-ce que Degate ?

En une phrase : Degate est un logiciel open source (GPL-3.0) et multiplateforme aidant ses utilisateurs à effectuer de la rétro-ingénierie sur des puces de silicium ².

Maintenant, pour donner un peu de contexte, le développement de Degate a commencé dès 2008 avec la thèse de master de Martin Schobert ³. Jusqu’à la fin de cette dernière en 2011, Martin a pu faire évoluer la solution et collaborer avec d’autres chercheurs pour l’utiliser sur des sujets de cybersécurité. Par exemple, Degate a pu être utilisé ⁴ pour aider à la rétro-ingénierie de la puce RFID MIFARE Classic de NXP (le développement de Degate a d’ailleurs pour source ce cas précis). Par la suite, les chercheurs Karsten Nohl et Starbug ont pu trouver une faille cryptographique dans la puce permettant d’outrepasser toutes les sécurités (on parle ici d’un impact économique énorme pour NXP) ⁵.

Degate est donc un logiciel avec une histoire riche de plus de 10 ans, qui a déjà permis d’avoir un impact dans l’industrie (et, suite au cas MIFARE Classic, dans la société). Il est aujourd’hui le seul bastion permettant à n’importe qui (ou presque) d’effectuer de la rétro-ingénierie matérielle sur des puces.

Pourquoi dis-tu que c’est le seul bastion ?

On peut voir ça sous différents angles, mais je parle d’unique bastion car Degate est le seul logiciel disponible à la fois gratuit, accessible (traduction de l’interface, documentation, etc.) et extensible (car open source). Or, les alternatives payantes sont généralement vendues sous conditions et donc difficilement accessibles. Seulement, comme je l’ai expliqué (modulo une déformation par mon parcours), la sécurité d’aujourd’hui passe, pour moi, forcément par une utilisation de la rétro-ingénierie matérielle beaucoup plus massive pour valider tout matériel critique. Et Degate n’est pas qu’un logiciel (surtout à sa création en 2008, c’était plus un outil ou un démonstrateur), c’est aussi une preuve d’importance (MIFARE Classic) et des ressources en ligne (wiki, articles, thèse, etc.). Il ne faut pas seulement voir le logiciel (avec ses défauts), mais plutôt l’approche : essayer de rendre plus accessible la rétro-ingénierie matérielle. Je ne clame pas que Degate réussit à remplir cette vision, mais je crois que nous sommes quasiment les seuls à essayer depuis maintenant plus de 10 ans (outre les projets visant à « rétro-ingénierier » certaines puces en particulier, sans prendre le prisme de la sécurité et de l’accessibilité).

Comment ça fonctionne ?

Avant tout il faut comprendre les contraintes et méthodes permettant d’effectuer de la rétro-ingénierie sur un objet aussi petit et complexe qu’une puce de silicium. Quand on parle d’une puce, on parle d’un agencement de milliards de transistors sur quelques millimètres et de leurs liens répartis sur plusieurs couches. La première étape est alors de définir un objectif, pouvant être la reconstruction d’un algorithme implémenté matériellement (et donc dans une zone réduite de la puce) ou encore la reconstitution complète du fonctionnement de la puce, par exemple pour construire un simulateur. Ensuite, il faut réussir à récupérer des images de la puce et de toutes ses couches (images en 2D ou 3D, un de mes articles dans Hackable aborde le sujet ⁶). Toutes les méthodes permettant d’obtenir ces images impliquent un processus destructeur pour la puce. Cela passe par exemple par un processus de polissage itératif et la prise de photographies (attention, on parle d’un exercice très complexe puisqu’une couche de silicium c’est extrêmement fin, et trop polir implique de devoir recommencer sur une nouvelle puce). On peut aussi prendre une approche chimique (utilisation d’acide pour attaquer couche par couche) ou laser. Sans développer beaucoup plus, ce processus est le plus important, car c’est avec ces photos très hautes résolutions que l’on va pouvoir débuter l’analyse de la puce.

C’est là que Degate rentre en jeu, son objectif est de permettre d’utiliser les images obtenues, de les importer dans le logiciel (on parle généralement d’images de plusieurs Giga, voire Tera, tellement la résolution et leur taille sont grandes) puis de commencer l’analyse. Ensuite, l’utilisateur peut analyser les parties de la puce en partant de la couche la plus basse, celle avec les transistors, et ainsi reconstruire les portes logiques (c’est ici que des connaissances en physique et en électronique sont importantes, il faut savoir lire à travers les transistors !). Comme vous vous en doutez, effectuer l’analyse de chaque transistor quand il peut y en avoir des milliards serait trop fastidieux, et Degate facilite le processus. Ce dernier propose en effet de construire une bibliothèque de portes logiques reconstituée depuis une zone de l’image de la puce, et puisque l’agencement des transistors ne change pas pour chaque porte logique, on peut alors automatiser la recherche et reconstitution de ces portes via des algorithmes de reconnaissance d’images. Il ne reste alors à l’utilisateur qu’à analyser les connexions entre les portes logiques toujours grâce aux images de la puce (couches supérieures, les liaisons entre couches sont appelées des « Via ») et ainsi reconstituer les algorithmes utilisés par la puce. Degate permet là encore d’automatiser une partie du processus en aidant à la reconnaissance des connexions et en proposant d’exporter toute l’analyse dans un langage type VHDL (permettant de simuler le fonctionnement de la puce, si l’analyse a été réussie).

Degate ne permet donc pas d’automatiser tout le processus de rétro-ingénierie, et une expertise humaine reste nécessaire (décapage de la puce, prise des photos, analyses des portes logiques puis des connexions), mais il permet de gagner un temps non négligeable sur l’analyse en automatisant plusieurs étapes. Pour cela, Degate implémente des algorithmes de reconnaissances d’images, supporte l’importation d’images extrêmement grandes (plusieurs millions de pixels de large), vous aide dans la navigation des images et couches, vous permet d’identifier les portes logiques formées par des transistors et bien plus.

Si le sujet vous intéresse, je peux vous donner les références suivantes : on peut citer Ken Shirriff qui est LA personne à suivre sur le sujet (auteur de beaucoup d’analyses sur des puces historiques ⁷, comme la Intel 8086 ou la fameuse Z80), ou encore la communauté Visual 6502 ⁸ qui ont rétro-ingénierié plusieurs puces (en partant de simples images pour finir par la création de simulateurs complets) ! Vous pourrez également explorer le super site Silicon Pr0n ⁹. Enfin, pour trouver une liste plus complète n’hésitez pas à vous rendre directement sur le dépôt de Degate ¹⁰.

Il existe des protections contre ceci ? J’imagine que certaines entreprises n’aimeraient pas qu’on fasse de la retro-ingénierie sur leur puce, il me semble que certaines puces possèdent un genre de grillage.

En effet, il existe beaucoup de méthodes pour essayer de s’en protéger. On parle de deux grandes catégories : les protections passives et actives. Les protections passives peuvent par exemple prendre la forme de résine que l’on “coule” sur les puces pour complexifier leurs récupérations (et aussi empêcher la récupération des références), ou d’une couche directement dans le silicium pour bloquer l’analyse visuelle de surface. D’autres méthodes existent, mais généralement de l’huile de coude et du bon matériel permettent de passer outre. Les méthodes actives sont plus recherchées et protègent contre d’autres approches de la rétro-ingénierie matérielle. Comme cité dans la question, l’ajout d’un grillage actif est une solution assez répandue dans les puces de cartes bleues par exemple. L’idée est à la fois de bloquer une analyse visuelle de surface de la puce, mais aussi d’empêcher le “probing” (essayer d’utiliser une sonde directement sur un “circuit” de la puce) ou la modification de la puce (par exemple en connectant deux “circuits” de la puce). Cela passe par un maillage avec des formes complexes (on peut voir ça comme un labyrinthe) alimenté par un courant qui, en cas de modification du circuit, peut rendre la puce non fonctionnelle. Il est alors compliqué d’aller voir et manipuler les couches inférieures en laissant la puce fonctionnelle. ¹¹

Est-ce que les différentes façons de gravure qui utilise différent MOSFET (CMOS, FinFET, MBCFET, FD-SOI etc) ne demandent pas des analyses différentes ? Est-ce que ça sera fiable avec les derniers types de gravure avec des transistors imbriqués 3D ?

À tout problème sa solution : les méthodes d’analyses 3D de puces de silicium se développent également ⁶. Si le matériel nécessaire pour créer les données 3D venait à être plus accessible, je prévois déjà l’ajout d’un mode d’analyse à Degate permettant de les exploiter. Je ne doute cependant pas que les méthodes d’analyses actuelles fonctionnent pour la majorité des cas, même si le problème est déjà suffisamment complexe pour ne pas rajouter ces spécificités. Je n’ai personnellement pas pu couvrir toutes les méthodes de gravures dans mes analyses ni les nouvelles approches en 3D. Seulement, ces méthodes s’appliquent pour l’instant majoritairement à la mémoire, ce qui n’est pas forcément la cible des analyses.

Qui se sert de Degate ? Est-ce une communauté de fans de consoles ou des professionnels confrontés à des puces qui ne sont plus documentées ou des gens du logiciel libre, etc. ?

Dès ses premiers jours, Degate a été pensé pour la cybersécurité. L’idée était de pouvoir faciliter l’analyse d’algorithmes implémentés directement dans les puces de silicium, à la fois pour essayer d’identifier des failles, mais aussi pour vérifier la présence de portes dérobées. En effet, d’un point de vue sécurité trop peu de personnes vont voir ces puces alors que tout dépend d’elles. Comment faire confiance à un système si l’on ne peut pas vérifier la sécurité de son composant le plus important et bas niveau ? Permettre à des chercheurs et passionnés d’attaquer le sujet est ma principale motivation quand je travaille sur Degate, le sujet est pour moi majeur. On a trop tendance à s’arrêter à la rétro-ingénierie logicielle, et c’est malheureusement un risque que l’on oublie trop.
Je sais aujourd’hui que Degate est utilisé (ou a été étudié) par des entreprises américaines dans le cadre de l’analyse de puces (je ne sais pas pour quel objectif), par la police allemande et par une université.

Malheureusement le domaine n’encourage pas beaucoup la communication et Degate pourrait être utilisé ailleurs. J’ai d’ailleurs de gros doutes sur son utilisation par une entreprise américaine sous forme de fork non-partagé (ne respectant alors pas la licence GPL qui est copyleft…). Mais ça, c’est un combat classique du monde libre (pour dire, on m’avait même proposé de me payer pour travailler dessus…).

Mais autrement, le logiciel peut être utilisé par d’autres communautés, comme pour les fans de vieux systèmes. Je sais que la communauté qui s’occupe de rétro-ingénierer la PlayStation s’est déjà intéressée à Degate ¹².

Concernant la sécurité, quels types de puces sont concernées ? J’imagine qu’il ne s’agit pas d’analyser les processeurs généralistes de nos ordinateurs… Ce sont des puces qu’on trouve dans quels matériels ?

C’est très large, généralement on parle de puces avec des missions/parties critiques. Par exemple (comme pour le cas MIFARE Classic), des puces implémentant des algorithmes cryptographiques sont importantes à regarder : au niveau logiciel on recommande (et c’est un euphémisme) de ne jamais réimplémenter ses propres primitives cryptographiques, pourtant beaucoup de puces le font (méthode simple pour booster les performances, aujourd’hui tout utilise de la cryptographie). Maintenant, on parle généralement de certaines parties/fonctions d’une puce plus que des puces entières. On peut par exemple citer en plus de la cryptographie tout ce qui concerne le stockage de données critiques (comme les clés de chiffrement). Aujourd’hui, je pense que l’on retrouve ces fonctionnalités dans tout type de matériel.

Comment en êtes-vous devenu le mainteneur ?

Comme je l’ai expliqué précédemment, c’est via un programme proposé par mon école d’ingénieur que j’ai été amené à travailler sur le sujet de la rétro-ingénierie matérielle à partir de fin 2018. Et comme Degate était le seul programme gratuit et open source permettant d’automatiser une partie du processus (indispensable pour arriver à des résultats sans y passer 10 ans), j’ai rapidement eu l’occasion de pouvoir l’utiliser. Malheureusement l’auteur originel du logiciel ne contribuait plus au projet depuis quasiment 8 ans à l’époque, et j’ai rapidement rencontré des difficultés pour l’utiliser plus largement dans mes recherches.

Après quelques mois de travail et un refactor à 70 % du projet (j’ai par exemple refait toute la GUI en Qt5 + OpenGL moderne) pour repartir sur de bonnes bases, j’ai publié mon fork sur Github. Par la suite Martin (l’auteur originel de Degate) a préféré mettre le projet initial en archive sur Github, et faire une redirection vers cette nouvelle version (aujourd’hui refaite à quasiment 80 % par moi-même). L’idée était de garder le nom et la communauté même si la grande majorité du logiciel a été refait.

Maintenant, suite à la fin de mes études, je dispose de moins de temps qu’avant et je suis forcément moins actif. Mais j’essaie de traiter toutes les issues et pull request, tout en continuant à travailler sur de nouvelles fonctionnalités. Je cherche également à faire pérenniser le projet en proposant à des étudiants comme moi (à l’époque) un financement pour travailler sur le sujet (et surtout Degate). Reste maintenant à trouver des personnes motivées, car le sujet est vraiment complexe.

Tu n’utiliseras donc pas Degate dans le cadre de ton travail ?

Aujourd’hui non, mais je sais que la question se pose pour des collègues. Le test d’intrusion matériel se développe, et le sujet se pose de plus en plus. Maintenant les compétences nécessaires pour s’attaquer à la rétro-ingénierie de puces de silicium sont un frein pour descendre aussi bas, sans compter le problème du matériel (faut-il encore pouvoir décaper/déstratifier les puces avant de pouvoir commencer l’analyse). La solution actuelle est de pouvoir accéder au design des puces (test en white box), mais les limites sont déjà visibles (un matériel est généralement composé de nombreuses puces de constructeurs différents).

Quelle est ta motivation ? Qu’est ce qui t’anime avec Degate ? Puisque tu as commencé l’informatique assez jeune, tu jouais peut-être avec des consoles ; est-ce que Degate te permet aussi d’imaginer recréer les puces de ton enfance ?

Étant aujourd’hui un ingénieur chercheur porté sur la cybersécurité, cela me force à voir Degate et la rétro-ingénierie matérielle à travers ce prisme. Pouvoir permettre à des chercheurs d’analyser des puces utilisées dans des millions de matériels à travers la planète est ce qui m’anime, même si je ne doute pas que bien d’autres cas d’utilisations peuvent être tout aussi intéressants. Je suis par exemple aussi très porté sur l’histoire, et la rétro-ingénierie matérielle est aussi un moyen de ne pas perdre certaines pièces de notre histoire.

Est-ce que vous tirez un revenu de ce travail ? Est-ce une bonne wafer ?

Je suis actuellement financé 100$/mois par le mainteneur principal de Rizin/Cutter (logiciel de rétro-ingénierie software) et j’ai déjà eu plusieurs autres propositions de financement. Ayant également publié des articles sur le sujet, j’ai quand même pu être rémunéré pour ce travail, mais on est très loin de quelque chose me permettant de vivre (et ce n’est pas l’objectif).

Pour finir

Que dire sur vos autres projets ?

Au niveau personnel je travaille (quand j’ai le temps) sur une nouvelle approche IA au service de la cybersécurité défensive. Malheureusement mon temps est très limité, et j’évite de trop m’éparpiller. Au niveau professionnel je suis aujourd’hui Tech Lead et Team Leader sur un projet d’automatisation de cybersécurité offensive. L’idée étant de créer un outil entièrement automatisé par IA permettant de jouer des attaques avec le même niveau de sophistication que les vrais acteurs (généralement quand je parle du projet on me parle de Skynet, pour ceux ayant la référence). Un produit devrait sortir dans les deux ans, nous avons déjà fait de nombreuses avancées scientifiques mais la route est encore longue. C’est aujourd’hui ce qui occupe le plus clair de mon temps !

Que pensez-vous de la directive NIS 2 sur la cybersécurité ?

La France a été pionnière en matière de réglementation dans le domaine de la cybersécurité, et je pense que la directive NIS 2 se place dans le même esprit que ce que l’on fait déjà depuis plusieurs années (avec la LPM de 2013 par exemple). Je sais que ces réglementations peuvent aussi faire peur, et l’accompagnement sera une condition nécessaire pour réussir son application. Malheureusement je pense qu’il est nécessaire d’agir au plus vite, les récents évènements géopolitiques ainsi que les (très) nombreuses attaques observées chaque semaine imposent d’investir dans la sécurité de nos entreprises. Je pense également que comme la NIS 1, la NIS 2 n’est qu’une étape, et que des évolutions seront nécessaires dans la prochaine décennie pour étendre les attentes concernant la sécurité des entreprises européennes.

Au niveau personnel, quels logiciels libres utilisez-vous, sur quel OS ?

J’utilise depuis maintenant quatre ans Manjaro, venant de Debian/Ubuntu, et je suis très satisfait (le modèle rolling release me plaît beaucoup à l’usage).

Au niveau professionnel, quels logiciels libres utilisez-vous, sur quel OS ?

Au niveau professionnel je tourne sur du Ubuntu 22.04, et j’utilise principalement du VS Code.

Quelle est votre distribution GNU/Linux préférée et pourquoi, quels sont vos logiciels libres préférés ?

Manjaro et Ubuntu sont les distributions que j’utilise dans la vie de tous les jours. Concernant les logiciels, la question est difficile puisque j’en utilise tellement. En ce moment je ne pourrais plus me passer de Joplin ou Signal, mais je pourrais en citer beaucoup (Virtual box, Kali linux, VSCode, Zotero…).

Références