ARM propose ses solutions spécialement destinées au marché des véhicules autonomes, Réactions à la publication du 27/09/2018

[Lionel]

Le marché des smartphones est celui qui rapporte le plus à nombre de sociétés dont ARM.
Il est le présent commercial mais le futur semble se jouer ailleurs, sur les véhicules autonomes. Tous les industriels s'y intéressent de très près.
Jusqu'à maintenant ARM proposait des solutions dérivées d'autres marchés pour tenter de se faire sa place dans les voitures de demain.
Elle a annoncé des développements spécifiques qui prendront la forme d'une R&D dédiée et d'un plan pluriannuel.
C'est en particulier le cas pour un projet appelé Arm Safety Initiative qui vise à augmenter considérablement le niveau de sécurité de ses puces, que ce soit en fiabilité ou en renforcement de la sécurité pour éviter toute prise de contrôle.
La première puce annoncée est le Cortex-A76AE, très loin de ce que l'on trouve dans un iPhone avec une consommation de 30W. Dans le futur, d'autres puces estampillées AE seront proposées.

Lien vers le billet original

[Fafnir]

Comme le dit Cuk la paranoîa de Mojave est pénible. Comment ARM résoud cet aspect?

[iAPX]

Mouaip c'est principalement suivre des standards (bienvenu ceci dit) à tous les niveaux et la possibilité de faire fonctionner les cœurs par paire pour vérifier à chaque cycle que les résultats sont identiques, ce qui protège d'un dysfonctionnement rare (mais dans ce cas le système fait quoi puisqu'il n'y a pas de 3ème pour arbitrer?!?), mais certainement pas d'une erreur de conception bien plus courante puisque nos CPU sont truffées de bugs dû à leur complexité.

Ça me laisse perplexe, à la fois l'absence d'arbitrage pour s'assurer de la continuité de service en cas de dysfonctionnement d'un cœur dans un engin aussi critique pour la sécurité physique des personnes, mais aussi de ne pas aborder frontalement le problème de la complexité qui amène mécaniquement des bugs de conception.

Ce message a été modifié par iAPX - 27 Sep 2018, 12:04.

[MaitreSoda]

Pour l’automobile, ça veut essentiellement s’assurer de respecter la norme ISO26262. On estime en général que pour un niveau d’ASIL C, il faut compter facilement +50% d’effort de R&D par rapport à un produit sans contrainte de sécurité de fonctionnement. Mais la référence de qualité de développement étant déjà relativement plus élevée dans l’industrie auto que dans l’electronique grand public, on doit certainement avoir des valeurs encore supérieures.

[iAPX]

Pour l’automobile, ça veut essentiellement s’assurer de respecter la norme ISO26262. On estime en général que pour un niveau d’ASIL C, il faut compter facilement +50% d’effort de R&D par rapport à un produit sans contrainte de sécurité de fonctionnement. Mais la référence de qualité de développement étant déjà relativement plus élevée dans l’industrie auto que dans l’electronique grand public, on doit certainement avoir des valeurs encore supérieures.

Désolé mais pour ce qui concerne les cœurs de CPU, ils sont testables tellement partiellement que c'en est presque un gag surtout depuis le passage au 64bits, sans parler même des possibilité d'incorporer des backdoors de la part de certains fondeurs dans le dos du client.

Quand à avoir 2 cœurs se surveillant mutuellement c'est le plus gros gag: que se passe-t'il en cas de désaccord entre les deux?
La seule solution est d'arrêter de les utiliser immédiatement en plein milieu d'un process qu'il faut donc relancer sur un couple d'autres cœurs en espérant qu'ils soient disponible?!?
Ou d'arrêter le process et on en parle plus?
C'est couplé au niveau des bus interne des cœurs, ou alors au niveau du bus système (au-dessus des caches L1 et L2 alors) ?
Dans le premier cas ça ne détecte pas les erreurs des caches, pourtant vu leur nombre de transistors...
Dans le second cas ça peut détecter une erreur longtemps après qu'elle soit commise, lors de l'éviction du cache, et s'être propagé à un autre process (partage mémoire, queue en mémoire partagée, etc.), et faire arrêter un autre process que le responsable!
Tout ça est tout sauf transparent (ce que prétendu) et repose sur des systèmes sophistiqué de transactions pour réussir (NetBeans venez à mon secours! lol)

Tout ça me parait plus de la poudre aux yeux que de la sécurité, puisque quand on arbitre à deux on doit basculer sur un dispositif séparé en cas de désaccord (pas sur la même CPU donc, voir pas le même module électronique), sinon il faut un arbitrage à 3, bien plus solide en cas de défaillance et non-supporté.
C'est bien d'avoir une initiative, mais si elle était sérieuse on aurait des détails techniques plus pointus permettant de se faire une idée...

PS: après la sécurité qu'on laisse tomber, on s'engage dans des voies totalement irrationnelles pour limiter les bugs avec des objectifs intenables (et d'ailleurs pas tenus puisque les bugs de conception passeront au travers des mailles du filet), pour finalement arriver à des dispositif s'arrêtant sur des problèmes plutôt liés à la fabrication et aux conditions d'exécution. Aucune garantie pour la sécurité physique des personnes...

Ce message a été modifié par iAPX - 27 Sep 2018, 21:44.

[Princo22]

Quand à avoir 2 cœurs se surveillant mutuellement c'est le plus gros gag: que se passe-t'il en cas de désaccord entre les deux?

Le développeur a la main dans ce cas.
C'est pas idiot en soit, c'est efficace et simple à la fois, pour un coût plutôt raisonnable.

Après, l'intérêt du truc, comme toi, j'ai un peu de mal. Le truc tel que présenté va détecter une erreur de calcul ou une erreur de cache bas level. Autant dire rien.
Bug de l'archi, erreur de code, erreur de mémoire sont infiniment plus probables. Tu as lâché le terme exact à mon sens: poudre aux yeux.

Après, l'idée même d'utiliser des CPU généralistes en parlant de sécurité critique, c'est risible donc...