Bodor Denis

De nos jours, vérifier l'authenticité d'un message, qu'il s'agisse de celui provenant d'un humain ou d'une machine est devenu presque quelque chose de totalement obligatoire. Tout un tas de mécanismes sont d'ores et déjà en place pour bon nombre de protocoles et de formes d'échanges, qu'il s'agisse du certificat d'un site web, d'un mail signé avec OpenPGP, d'une authentification pour une connexion distante avec SSH, et j'en passe. Mais qu'en est-il pour les petites choses, comme une simple ligne de texte, une URL ou la donnée embarquée dans un QRcode ?

Vous avez remarqué que le FUD (Fear, Uncertainty and Doubt), tant utilisé par le passé contre GNU/Linux et le logiciel libre en général, est devenu la norme pour la promotion de bon nombre de solutions et services en ligne ?

Dans un précédent article [1], nous avons vu comment il était possible, avec une Raspberry Pi Pico, de créer relativement facilement un périphérique USB au comportement arbitrairement défini. Mais bien avant l'arrivée du microcontrôleur RP2040, il était déjà possible de faire cela depuis bien longtemps, trèèèèèès longtemps même. Et je ne parle pas d'Arduino (Leonardo en l'occurrence et son ATmega32u4), mais d'un composant que vous possédez peut-être déjà, sans le savoir, dans votre boîte à outils : l'EZ-USB FX2LP.

Une vidéo récente sur la chaîne secondaire de Matthias Wandel [1] m'a récemment fait vérifier presque l'ensemble des câbles que j'utilise pour mes montages et autres expériences. En effet, Matthias, qui généralement diffuse du contenu autour du travail du bois, a constaté que ses câbles munis de pinces, achetés très récemment, présentaient une résistance relativement surprenante, quelque 300 mΩ pour 15 cm, ce qui n'est peut-être pas un problème pour des signaux (selon la fréquence), mais en est clairement un pour une alimentation.

Lorsqu'il s'agit de tirer le maximum des ressources à disposition d'une plateforme, en particulier dans l'embarqué, le processeur n'est généralement pas souvent la solution la plus adaptée. Du matériel dédié comme les accélérateurs matériels, en particulier pour les calculs matriciels ou la cryptographie, viennent souvent assister le processeur et l'alléger des tâches demandeuses en calcul. L'une des options possibles dans ces situations est l'utilisation du GPU, via des frameworks dédiés. Une humble Raspberry Pi peut être un excellent terrain de découverte pour prendre en main ce type de technologies.

Je ne vous apprends rien en vous disant que GNU/Linux dispose de bien plus de pilotes de périphérique que, disons, OpenBSD. Ceci n'est pas bien grave en soi puisqu'il suffit d'en développer de nouveaux, tout en s'inspirant du travail du développeur s'étant déjà cassé les dents sur le sujet (merci, le logiciel libre). Là où cela devient pénible, c'est que les bêtises coûtent cher lorsqu'on touche à un noyau et qu'elles se soldent généralement par des resets brutaux et à répétition. Ne serait-il pas merveilleux de pouvoir accéder à certains matériels depuis l'intérieur d'une machine virtuelle, pour rendre cela plus digeste ?

Dans un précédent article [1], nous avons découvert LiteX, une solution permettant de créer des périphériques et SoC en toute simplicité, sans avoir à apprendre à utiliser des langages de description de matériel comme Verilog et VHDL. Aujourd'hui, poussons plus loin l'exploration de ce framework doublé d'une infrastructure de construction et basé sur Python en faisant fonctionner un système d'exploitation GNU/Linux sur une plateforme « full FPGA » RISC-V.

Lorsqu'on parle de domotique, on pense généralement aux capteurs et aux automatisations permettant de gérer facilement son habitation pour piloter son chauffage, simuler une présence, faire des économies d'énergie ou tout simplement améliorer son confort en se débarrassant des tâches fastidieuses et répétitives. Cependant, la sécurité est également un point important, qu'on soit sur place ou à distance, et dans ce cas précis, rien de tel que de mettre en place une vidéosurveillance.

Dans un précédent article [1], nous avons exploré la possibilité de créer des machines virtuelles « vierges » dans le but de tester des ports OpenBSD en cours de développement, en particulier pour nous assurer que les dépendances étaient correctement décrites et complètes. Tout ceci était motivé par le fait de devoir jongler entre différentes versions du système (current versus release ou stable). Si cette contrainte n'est pas là, les choses deviennent beaucoup plus simples à gérer et les VM peuvent être remplacées par quelque chose de bien plus léger : un simple environnement chrooté.