Lancement de la branche « Software Toolchain » de l’Open Compute Project

18
7
déc.
2016
Technologie

Dans le cadre du projet Open Compute qui vise à définir des conceptions ouvertes de matériel, une avancée importante a été réalisée avec la perspective d’utiliser une chaîne d’outils logiciels de conception ouverte, dont les implémentations de référence seront faites en utilisant des logiciels libres, mettant fin au problème pécuniaire de l’utilisation des fichiers aux formats propriétaires (et ouvrant des perspectives d’audit communautaire et d’utilisation de méthodes formelles pour prouver la validité de la conception).

Sont concernés notamment : la conception électronique et mécanique, l’affichage sur le Web de contenus 3D, de données de type CAO électronique, de résultats de simulations physiques (analyse thermique, analyse mécanique…), etc.

Toute aide sera bienvenue. Nous réaliserons une démonstration lors de l’évènement Open Compute Summit — les 8 et 9 mars 2017 à Santa Clara, en Californie — où nous emmènerons les meilleurs contributeurs.

Comme vous le savez, je suis impliqué dans le projet Open Compute (dit OCP, pour « Open Compute Project » — site www.opencompute.org). Ce projet est présenté — en reprenant les termes de la page d’accueil — comme consistant à ré‐imaginer le matériel informatique, le rendant plus efficace, flexible et extensible. Rassemblant notamment des ténors du marché, le projet est annoncé comme visant à ouvrir la boîte noire des infrastructures informatiques propriétaires pour obtenir plus de choix, de la personnalisation et une réduction des coûts.

Je suis aussi contributeur au projet FreeCAD (www.freecadweb.org) — FreeCAD, ainsi que KiCad, sont majoritairement développés en Europe — et nous avons œuvré pour éduquer la communauté Open Compute aux problèmes liés à l’utilisation des fichiers aux formats propriétaires pour les membres de la communauté qui n’ont pas les moyens de s’offrir des licences logicielles propriétaires qui valent une fortune (et je mesure mon propos).

Dans le cadre du projet Open Compute, notre implication est passée à un niveau supérieur la semaine dernière suite a l’annonce (en anglais) du lancement du sous‐groupe « Software Toolchain » (avec notamment l’ouverture de la liste de discussion opencompute-toolchain).

Nous avons réussi à franchir une étape et ça fait plaisir : l’objectif du sous‐groupe Software Toolchain est de construire une chaîne d’outils logiciels de conception ouverte qui permettra aux équipes de développement de travailler de manière collaborative sur un même schéma de conception et de développer les technologies associées. Les implémentations de référence seront faites en utilisant des logiciels libres.

Pour détailler un peu plus, voici un extrait significatif de l’annonce précitée, traduit en français (et enrichi de quelques liens pédagogiques) :

En créant une chaîne d’outils logiciels de conception ouverte pour des solutions de conception électrique, électronique, électromagnétique [N.D.T. : electrical engineering renvoie généralement à ces trois domaines de la physique] et de la mécanique, le sous‐groupe Software Toolchain vise à accélérer la collaboration à l’intérieur du projet Open Compute. Pour aider les ingénieurs à améliorer la qualité de conception et pour aider la communauté à fournir des remontées d’information efficaces, le sous‐groupe se concentrera initialement sur la définition d’API (cf. interface de programmation) standards pour simplifier la publication des fichiers de conception sur le Web et sur les moyens d’annoter les fichiers de conception pour fournir des remontées d’information directement via les outils de conception.

La première implémentation sera basée sur des logiciels libres existants tels que FreeCAD et KiCaD. Cependant, l’ouverture de l’API permettra à des vendeurs de logiciel indépendants d’implémenter des fonctionnalités au sein de leurs propres applications.

Ce sous‐groupe peut inclure des partenaires intéressés à différents domaines incluant :

  • outils d’affichage sur le web de contenus 3D ;
  • outils d’affichage sur le web de données du type CAO électronique (en anglais EDA pour « Electronic Design Automation » — cf. conception assistée par ordinateur pour l'électronique) ;
  • système de fichiers orienté objet en réseau ;
  • moteurs 3D avancés ;
  • outils d’affichage de résultats de simulation physique tels que l’analyse thermique, l’analyse mécanique, et bien plus à venir.

Pour ceux qui veulent nous aider à faire avancer le sujet :

  • si vous avez des compétences à partager et ressentez le même enthousiasme que nous, n’hésitez pas à rejoindre la liste de diffusion (en anglais) ;
  • si déjà vous lisez cette dépêche et prenez conscience des enjeux, faites du bruit dans vos GULL et sur les réseaux sociaux autour de cette nouvelle. :)

Nous avons du boulot et nous emmènerons les meilleurs contributeurs à l'Open Compute Summit (« OCP US Summit 2017 », les 8 et 9 mars, à Santa Clara, en Californie, aux États‐Unis d’Amérique) pour présenter la première démonstration de la chaîne d’outils logiciels libres. Naturellement, en trois mois, on ne risque pas de révolutionner la planète, mais nous ne pouvons pas louper l’événement !

Les plus gros membres du projet Open Compute sont Facebook, Microsoft, Google, Intel, Rackspace, et les convaincre de considérer favorablement ces solutions a été un exercice relativement intéressant. J’espère qu’on pourra leur prouver que l’on peut construire quelque chose d’aussi innovant que RuggedPOD (cf. le mot‐clef « ruggedpod » sur LinuxFr.org) !

Addendum :
Certains observateurs font remarquer que de manière générale, dans le cadre du matériel libre, la preuve formelle de code (cf. méthode formelle (informatique)) peut être considérée comme un atout particulièrement important du fait que des failles de sécurité dans la conception sont identifiables par des groupes malveillants de manière plus aisée qu’avec du matériel fermé, ces groupes pouvant garder pour eux leurs découvertes, de manière à les exploiter dans le secret.

Ils notent que, via le projet Software Toolchain, s’ouvrent des perspectives d’audit communautaire renforcé du code source définissant le matériel libre (avec des outils libres) ainsi que des perspectives de production de preuve formelle appliquée aux processus logiciels — ce qui n’a de sens, en termes de confiance, que si le code source des logiciels est ouvert —, notamment :

  • la preuve formelle de validité des données binaires de fabrication (qui se retrouveront en entrée des machines, notamment pour la gravure des circuits intégrés, la gravure des circuits imprimés, leur percement, le positionnement des composants sur les cartes, etc.) relativement au code source définissant le matériel libre ;
  • la preuve formelle de validité des simulations relativement au code source définissant le matériel et aux conditions de simulation ;
  • la preuve formelle de validité des processus comme le routage, etc. ;
  • la preuve formelle de validité du code source définissant le matériel libre par rapport aux spécifications ;
  • voire d’autres preuves formelles comme la robustesse du code définissant le matériel (que ce soit le code binaire de fabrication, le code source, ou même les spécifications) relativement à des types d’attaques répertoriés.

De plus, avec la libération des fichiers de conception matérielle viendra la capacité accrue de répliquer l’expérience en produisant des versions alternatives et dérivées. Or, la sécurité est influencée positivement par la diversité. Ceci dit, pour favoriser la diversité en conservant le bénéfice de la preuve formelle de code — sans quoi l’avantage de la diversité pourrait être compensé par la perte de couverture de la preuve de code —, il sera avantageux de privilégier des approches génériques de preuve de code dans la mesure du possible (ce qui est également d’un intérêt scientifique certain).

Certains ajoutent qu’il est déjà acquis que la direction prise est la bonne, même si, d’une part, des fonctions parasites resteront intégrables par des fabricants malveillants — par exemple, des chevaux de Troie matériels furtifs, réalisés au niveau du dopage du substrat en silicium des circuits intégrés (cf. ce commentaire de Misc< référençant des résultats de recherches) —, incitant avantageusement la communauté à superviser la fabrication et, même si, d’autre part, la substitution malveillante du matériel restera possible pendant la phase de distribution, incitant là aussi la communauté à organiser une forme de supervision.

  • # Exemple du BIM dans le bâtiment ?

    Posté par . Évalué à 5.

    Le bâtiment est en retard sur beaucoup de chose, mais depuis quelques années la démarche BIM (Building Information Modeling) se généralise dans les projet (surtout les gros)

    Cette démarche repose notamment sur des formats d'échanges standardisés :
    - l'IFC (Industrie Foundation Classes) : qui permet d'encapsulé un grand nombre de données dans la maquette numérique.
    - le BCF , qui permet de gérer l'échange d'information (annotation de plans 2D, de vue 3D, etc…)
    Le logiciel FreeCAD fait partie des logiciels compatibles IFC (mais jusqu'à quel version, je ne sais pas….)

    Pour le partage en tant que tel, il existe l'Open BIM Collective, dont les membres développent des outils de partage et de visualisation de maquette BIM sur le web (BIMServer.org, BIMSurfer, etc…)

    Je n'ai pas conscience de la masse de travail que pourrait représenter une "conversion" du format IFC pour en faire un format orienté électronique.
    Mais il y a peut-être quelque chose à faire à ce niveau là!

    Voilà, c'était ma petite pierre.

  • # compilation failed

    Posté par . Évalué à -6.

    Je suis ravi d'avoir pu aider à la rédaction de cette dépêche de très bonne tenue. Il y a juste un truc qui me chagrine, c'est qu'elle me génère des erreurs à la compilation (je rigole) : je n'avais pas mis les « cf. » en italique, or ça a changé pendant la phase de modération. Pourtant « cf. Ne s'écrit pas en italique » (cf. source). Si besoin de vérification plus poussée, je renvoie à la page 7 du Lexique des règles typographiques en usage à l'Imprimerie nationale :)

    Ok, je --> [ ]

  • # correction d'un lien wikipédia

    Posté par . Évalué à -8. Dernière modification le 12/12/16 à 12:00.

    Dans la dépêche, il y a un lien Wikipédia qui n'est pas fonctionnel, normalement associé à l'expression [[conception assistée par ordinateur pour l’électronique]] (1). Le voici pour vous : Conception assistée par ordinateur pour l'électronique.

    (1) pour les admins/modérateurs : ce lien était correctement orthographié lors de la phase de rédaction collaborative de la dépêche. Le défaut de génération du lien est lié à une correction malheureuse, en l'occurrence, pour remplacer l'apostrophe droite par une apostrophe inclinée (version qui va bien : ' / version corrigée en phase de modération, qui empêche la génération du lien : ).

  • # Attaque matérielle furtive dite « A2 » -- escalade de privilège contrôlable à distance

    Posté par . Évalué à -6.

    En écho au dernier paragraphe de la section addendum, j'invite les lecteurs intéressés à consulter ce nouveau commentaire qui présente une autre catégorie d'attaques, dites « A2 », à travers une publication qui montre comment un attaquant opérant au moment de la fabrication peut exploiter des circuits analogiques pour créer une attaque matérielle minuscule et furtive (requérant une séquence de déclenchement improbable avant d'affecter la fonctionnalité d'une puce) par le biais de condensateurs siphonnant la charge depuis des pistes environnantes et déployant une attaque qui force une bascule (la victime) à une valeur désirée, permettant une escalade de privilège contrôlable à distance — une attaque qui fonctionne, qui échappe à l'activation par un ensemble varié de tests d'évaluation et qui semble échapper aux défenses connues…

Suivre le flux des commentaires

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