Vu initialement sur ElectroniqueS, la publication de cette information sur le site de Thales
Je me cantonnerai uniquement aux systèmes embarqués.
1) Il me semble que c'est un message très positif pour la fondation RISC-V et je souhaite que celà permettra d'inciter d'autres entreprises à participer à l'effort du partage de la connaissance et surtout à participer financièrement aux développements qu'elles utilisent. En effet, c'est une constatation de la mauvaise pratique de certaines entreprises (toutes tailles confondues) qui utilisent les développements open source dans des solutions commerciales sans se conformer strictement aux exigences des licences de manière spontanée. Ceci étant, je trouve qu'il y a eu énormément d'efforts depuis ces 10 dernières années.
Note: Thales n'a rejoint le CII qu'en 2017, ce qui est tardif mais déjà bien. Mais je ne les vois pas dans le yoctoproject pourtant très lié à "Linux embarqué"…
2) Je suis perplexe quant à l'utilisation de l'expression "Fort de son expertise en sécurité et sûreté des systèmes critiques embarqués" dans les articles : c'est vrai sans aucun doute. Mais ce n'est pas l'image que je perçois: je ne trouve aucun document public, aucun article en partage qui me le prouve.
Je préfère l'image données par TI qui partage sa connaissance sur la sécurité dans les systèmes embarqués sur leur site. D'ailleurs, je vous recommande chaudement leur eBook "Building your application with security in mind" qui est un bon point d'entrée pour ce sujet. Si vous en avez d'autres sur le sujet "sécurité dans les systèmes embarqués", je pense que je ne serai pas le seul intéressé! :-)
Je nous souhaite que Thales fasse de même, la partage des bonnes pratiques fait partie de la gestion de projets, et qui plus est, encore plus si c'est open-source!
# Lien eBook
Posté par plr . Évalué à 2.
Le lien vers l'eBook est défectueux dans le journal. Il est ici: "Building your application with security in mind"
[^] # Re: Lien eBook
Posté par patrick_g (site web personnel) . Évalué à 5.
C'est corrigé dans le journal.
[^] # Re: Lien eBook
Posté par Jimmy . Évalué à 2.
C'est tout frais : https://github.com/Thales-RISC-V
# RISC-V
Posté par abriotde . Évalué à 5.
C'est surtout une belle monté en puissance de ce processeur Open-Source dont la réalisation concrète m’apparaissait très peu probable. Thales n'est pas le seul à le soutenir, et cela me laisse rêver de pouvoir un jour commander une carte totalement Open-Harware (OLinuXino?) jusque dans le processeur et son firmware.
[^] # Re: RISC-V
Posté par Jimmy . Évalué à 4.
L'ambition des créateurs de RISC-V est réellement d'en faire le "Linux du hardware".
C'est probablement le bon moment pour qu'une telle initiative prenne racine. Un aspect important pour l'adoption par l'industrie est que plusieurs implémentations du jeu d'instructions RISC-V sont sous licence BSD, bien plus permissive que la GPL adoptée par le processeur Leon (processeur SPARC utilisé dans le spatial, dont le développement a initialement été financé par l'ESA).
[^] # Re: RISC-V
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
GPL ou BSD cela ne change pas grand chose. La licence découlant de la loi sur les droits d'auteur s'applique sur le code source, les fichiers "netlist" mais pas sur la puce elle-même. Ainsi, une modification d'un HDL GPL impose simplement de fournir les soft à ceux qui ont les netlist, mais pas au propriétaire du hardware lui-même.
"La première sécurité est la liberté"
[^] # Re: RISC-V
Posté par martoni (site web personnel, Mastodon) . Évalué à 8. Dernière modification le 28 novembre 2018 à 14:28.
Attention, Risc-V n'est pas un processeur mais juste un standard pour le jeux d'instructions (le langage d'un processeur). Libre aux gens d'implémenter ensuite l'ISA (Instruction Set Architecture) comme il le veulent.
On trouve déjà tout un tas de processeurs basés sur Risc-V, et pas seulement des «soft-core» :
Quand au softcore pour les FPGA il y en a une tripotté.
J'ai plus qu'une balle
# secret défense
Posté par papap (site web personnel) . Évalué à 4.
"Fort de son expertise en sécurité et sûreté des systèmes critiques embarqués" dans les articles : c'est vrai sans aucun doute. Mais ce n'est pas l'image que je perçois: je ne trouve aucun document public, aucun article en partage qui me le prouve.
Normal, qu'ils ne disent rien là-dessus, tout est secret défense. Donc motus et bouche cousue.
[^] # Re: secret défense
Posté par plr . Évalué à 4.
Bien entendu, on peut entendre ce message; je le connais étant dans le monde de l'entreprise depuis un certain temps.
Mais il m'est incompréhensible. D'ailleurs, tu ne donnes pas ton avis là-dessus, tu fais juste un constat connu : j'aurais aimé lire ta prose plutôt que de voir d'autres moinsser ton commentaire, qui me semble être un bon départ de discussion.
Pour ma part, je n'arrive pas à accepter le message qui indique qu'on va être dans le monde "open-source" et ne rien communiquer, pas même un livret de bonnes pratiques.
Toute analogie ayant ses limites, ça me fait penser à un passant qui aide un aveugle un peu ignorant à traverser la route en lui disant quand traverser mais qui ne lui expliquera pas qu'il y avait un dispositif de guidage au sol devant le passage piéton et que la musique lui indique quand le feu est vert. OK, pourquoi pas, mais pourquoi je lui ferais confiance et je ne trouve pas ça fair-play.
Et je ne parle même pas de l'illusion de "sécurité" du "secret-défense" dans ce domaine (plus ou moins vrai); histoire vécue: c'est le PC qui est installé chez le client avec un dongle d'utilisation, toutes les communications en protocole propriétaire sécurisé, mais qui est ouvrable et qu'on peut récupérer/cloner/modifier toutes les données stockées, mots de passe (md5) y compris sans y laisser aucun indice à l'installateur… Ou de la récupération de documents confidentiels dans la poubelle commune à l'extérieur d'un bâtiment ultra-sécurisé (au XXe siècle)
D'où mon attentisme empreint d'espoir.
[^] # Re: secret défense
Posté par flan (site web personnel) . Évalué à 3.
En fait, je ne vois pas trop ce que tu attends.
En matière de sécurité informatique, Thalès a quand même « quelques » notions (vu qu'ils produisent du matériel classifié avec des vraies contraintes de sécurité, ce n'est pas parce que ce ne sont pas des standards grand public et que c'est du matériel étatique que ça ne vaut rien).
Ceux qui ont besoin d'y croire (en gros, l'État français) ont les moyens d'évaluer la sécurité du matériel Thalès. Quant aux autres, je pense que Thalès se moque un peu de les convaincre ou pas, à mon avis.
[^] # Re: secret défense
Posté par Guillaume Knispel . Évalué à 8.
C'est extrêmement dur de se prévaloir d'une expertise en sécurité si tout est secret (ou en quoique ce soit, d'ailleurs, mais en fait encore plus particulièrement en sécu)
Même la NSA publie des trucs…
En passant j'ai fait un peu de presta pour Thales il y a quelques années et du micro échantillon que j'en ai vu à l'époque, la culture m'a semblé ultra corporate avec assez peu de collaboration interne hors cadre d'un contrat (les différents BU passant des appels d'offre auxquelles les autres et les externes peuvent répondent simultanément, et "grâce" à ce système Thales maintenait/adaptait probablement la même bibliothèque des dizaines de fois sans que les gens qui travaillent réellement dessus puissent ne serait-ce que savoir qui sont les autres—et ce y compris pour être intégré en tant que composant dans un même système). Pour faire de la sécu à un bon niveau, il faut de la collaboration informelle y compris en dehors de l'entreprise. Alors je sais pas si ça fonctionne toujours comme ça et si c'est global à tout Thales, mais si déjà c'est si dur de collaborer informellement en interne, en externe j'ose même pas imaginer.
# Expertise de Thales
Posté par bmrgb . Évalué à 10.
À la lecture, je ne suis pas sûr que tu comprennes bien l'étendue des activités de Thales dans l'embarqué.
Thales à travers ces multiples entités produit par exemple avec plus ou moins de succès et de talent :
- des systèmes radars pour la marine et de l'avion ;
- des systèmes de combat pour navire ;
- des systèmes de guidage hypervéloce ;
- des systèmes de guerre électronique (détection et contre-mesure) ;
- des systèmes de communication (terrestre et spatiale) ;
- des systèmes de positionnement pour satellite ;
- des autopilotes (avions, hélicoptères et drones) ;
- des systèmes intégrés de capteurs de surveillance pour l'industrie ;
- des systèmes de détection intrusion pour les réseaux ;
- des systèmes de contrôle d'accès notamment pour la SNCF.
Par système, j'entends le soft mais aussi la partie hardware bien sûr et ça n'est qu'un aperçu.
Thales publie de manière relativement correct dans tous ces domaines - y compris le militaire. Il suffit de taper thalesgroup.com dans Google Scholar pour s'en convaincre.
Les articles et whitepapers pour la partie sécurité que tu n'as pas trouvé sont là :
https://www.thalesesecurity.com/resources/research-reports-and-white-papers
Je pense qu'ils peuvent sans trembler parler d'expertise et rien qu'au vu du nombre de cours donné dans les écoles d'ingénieur françaises par des gens de chez eux, on peut difficilement les accuser de ne pas partager les bonnes pratiques.
[^] # Re: Expertise de Thales
Posté par plr . Évalué à 1.
Je te remercie pour cette présentation digne d'une plaquette marketing (hé!ho! ne te vexes pas, je suis taquin de nature!). Je connais Thalès globalement mais pas dans son organisation interne. Je pense que le sujet ici abordé concerne essentiellement le grand public et industriel; je ne pense pas que Thales utilise le résultat pour ses applications défense et armement. D'ailleurs, on s'autorise (dans les milieux autorisés) à se poser la question de savoir s'il n'y aurait pas une peu de tirage de couverture à soi: à la limite, je m'en fiche, bien au contraire surtout si celà pousse les autres fondeurs à metttre plus de sécurité dans les uC et uP (micro-contrôleurs / micro-processeurs).
Ne me fais pas dire ce que je n'ai pas dit: oui, Thales a une vrai expertise dans le domaine de la sécurité. Mais, à mon goût, je trouve qu'il ne partage pas suffisamment avec les communautés open-source et que celà ne se voit pas à mon niveau (plus développement/intégration que recherche) avec des micro-processeurs qui sont ridiculement peu performants par rapport à ceux qu'utilisent Thales.
C'est d'autant plus vrai que tu cites l'ensemble des entités et lorsqu'on connait le nombre d'employés; je ne trouve pas de référence à un mail de thalesgroup ni dans le code source que j'ai de freertos, ni dans le linux "rt" que j'ai sous la main. Pourtant, il y a des offres d'emploi/stage avec demande de maîtrise des ces os là…
En comparaison, il y a un certain temps, les NXP, Freescale, TI, Atmel(Microchip), Intel, Microsoft (entre autres) étaient de très mauvais contributeurs, je te laisse aller voir leurs contributions, c'est colossal et je les remercie!
Je propose un lien direct avec des conseils très concrets sur la sécurisation de uC/uP, en échange, le lien qui est proposé (merci quand même, je ne vais pas cracher dans la soupe!) vers des publications où il faut décliner toute son identité pour accéder à une information dont on ne saura pas la pertinence par rapport à ma recherche: hélas, je n'ai pas l'autorisation de fournir ces informations.
Pour être dans le concret, quand dans une installation, j'ai plus d'un millier (petite installation) de uC allant du 8 bits au 32 bits tous reliés par des bus spécifiques (pas le droit d'en dire plus sur les distances et sur les medium), et que je souhaite améliorer la sécurité globale du système alors que j'ai une contrainte économique très forte (Thales n'est pas présent dans mon segment): redondance de micro-processeurs, redondance d'appareils, synchronisations des redondants, mise en place de canaris à bon escient dans des uC à très faible empreinte, surveillance, tracking des modifications de configuration de périphériques internes/appareils hardware (donc autant surveillance interne qu'externe, utilisation de certaines préconisations de SIL4), utilisation d'un "serveur tiers" pour la validation de certaines demandes d'autorisation, etc. Je trouve plus d'information constructive dans des petites sociétés et chez les fondeurs ce qui fait que je serais tenté de me tourner vers eux d'abord avant d'aller voir Thales, ce qui n'est pas forcément raisonnable (celà dépend du projet)
La contrainte économique fait que j'aurais souhaité que les uP de génération actuelle aient plus de blocs hardware dédiés sécurité (on commence à avoir AES presqu'en standard, il y en a d'autres qu'on est obligé de faire en sw alors que le coût en hw serait négligeable): je suis sûr que si les pratiques de sécurisation étaient plus partagées depuis un moment, on en bénéficierait tous car les fondeurs intègrent les blocs que les client demandent.
Conclusion: je suis frustré qu'à mon niveau (et je pense représenter un certain nombre d'ingénieurs en systèmes embarqués dans des petites structures qui déploient des myriades de capteurs en réseau), on ne puisse pas bénéficier des miettes de recherches qui ont été amorties depuis bien longtemps… Et encore plus lorsque tu vois la NSA avec SELinux (sans l'utiliser, ça m'a aidé à trouver des pistes d'améliorations sur un système)
# Thales et non Thalès
Posté par Jokernathan . Évalué à 2.
Il y a une petite typo dans le tag (et dans quelques commentaires), l'entreprise Thales s'écrit sans accent. Avec accent c'est bien le grec qu'on connait tous.
[^] # Re: Thales et non Thalès
Posté par plr . Évalué à 2.
Mea culpa!
Et en effet, c'est logique : on trouve des offres d'emploi/stage super intéressants proposés sur le site web de Thales parce que Thalès, lui, n'a sans doute pas eu le temps de finir le site web de son école! :-D
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.