La vie est mal configurée

Aller au contenu | Aller au menu | Aller à la recherche

samedi, janvier 20 2018

Sur la portée des attaques SPECTRE et MELTDOWN

Les attaques Meltdown et Spectre ont beaucoup inquiété. Devant certaines questions, il me semble pertinent de préciser certains points.

Ces attaques visent à faire fuir des informations depuis un logiciel attaqué vers un logiciel attaquant, ce dernier devant réaliser un certain nombre d’actions très spécifiques pour obtenir, indirectement, des informations censément secrètes. Elles s’appuient sur des chronométrages fins de certaines opérations très particulières, le temps nécessaire à les réaliser variant suivant la valeur des données secrètes. Elles contournent ainsi les mécanismes de protection qui permettent à une même machine de faire fonctionner séparément les programmes de plusieurs utilisateurs.

Ces attaques sont donc importantes pour les prestataires de services d’hébergement cloud, qui louent à des utilisateurs la possibilité de lancer des logiciels sur des machines (dites « serveurs ») puissantes et situées dans des locaux adaptés (data centers), avec des connexions Internet à haut débit et faible latence et des assurances de fonctionnement en continu (personnel de permanence, onduleurs en cas de coupure de courant). Elles sont également importantes pour les entreprises et organismes qui ont des serveurs où un grand nombre d’utilisateurs peuvent lancer des logiciels de leur choix ; par exemple, pour les universités, certains étudiants ayant à cœur de vouloir contourner les mécanismes de sécurité.

Qu’en est-il des utilisateurs individuels ? Une personne qui utilise seule sa propre machine ne va évidemment pas essayer de se pirater elle-même. On pourrait éventuellement envisager une attaque en escalade : tout d’abord, les intrus se rendraient maîtres d’un logiciel peu privilégié (n’ayant pas accès aux donnés de l’utilisateur humain de la machine) mais communiquant en réseau, puis à partir de là essaieraient d’obtenir les données de l’utilisateur ; mais cela semble assez difficile (il y a probablement d’autres failles plus faciles à exploiter).

Le cas qui me paraît le plus réaliste est celui des navigateurs Web, qui font fonctionner des logiciels venant de l’extérieur (principalement écrits en langage Javascript). Pour être exécuté efficacement, le Javascript est traduit (on dit « compilé ») en instructions directement exécutables par l’ordinateur. Il semble possible d’écrire du Javascript tel qu’avec certains navigateurs le produit de cette traduction puisse être utilisé pour réaliser les chronométrages permettant l’attaque. Parmi les contre-mesures discutées, il y a la détection, lors des processus de compilation, de configurations vulnérables à l’attaque Spectre (ou de configurations attaquantes) et l’ajout d’instructions empêchant la fuite d’informations.

On m’a évoqué le cas des processeurs ARM ou STMicro. Ceux-ci ne sont pas utilisés dans des ordinateurs personnels ou dans des serveurs classiques, mais plutôt dans des objets connectés ou non ou des terminaux mobiles (téléphones, tablettes…). C’est un univers vaste et il faut distinguer plusieurs cas.

Les attaques Spectre et Meltdown visent à contourner des mécanismes de protection et d’isolation de processus les uns et des autres. Elles n’ont donc aucun intérêt sur des processeurs simples n’ayant pas de tels mécanismes de protection, où chaque logiciel a accès à la mémoire de tous les autres (ce qui a d’ailleurs été longtemps le cas sur les ordinateurs personnels).

Ces attaques s’appuient sur des mécanismes (mémoires caches, exécution spéculative…) qui n’existent que dans les processeurs à hautes performances, notamment ceux que l’on met dans les ordinateurs personnels et les serveurs. Les processeurs plus simples n’utilisant pas de tels mécanismes ne sont pas vulnérables.

Ces attaques supposent que l’on puisse charger un logiciel intrus, donc qu’il soit possible de charger des logiciels nouveau sans que ceux-ci n’aient à être authentifiés par le fabricant de l’objet. Les objets n’ayant pas la possibilité de charger des nouveaux logiciels, ou qui restreignent ce chargement à des logiciels produits par le fabricant de l’objet ou du moins validés par lui, avec au moment du chargement vérification de ce fait (signature électronique), ne sont donc pas concernés.

mardi, janvier 9 2018

Retour sur quelques questions sur MELTDOWN et SPECTRE

Suite à la publication de mes billets précédents sur les failles MELTDOWN et SPECTRE, j’ai répondu à diverses questions, et je pense que certaines méritent une réponse publique.

Les attaques par canaux cachés n’ont rien de nouveau

Un de mes interlocuteurs pensait que ces failles étaient les premières failles de sécurité basées sur un problème dans le matériel. Ce n’est pas le cas — peut-être serait-il en revanche exact que ce sont les premières failles de sécurité basées sur un problème dans le matériel qui soient venues à l’attention des journalistes.

Les failles MELTDOWN et SPECTRE s’appuient sur l’exploitation de « canaux cachés » permettant de transmettre de façon indirecte des informations d’un logiciel privilégié (au sens qu’il a accès à des informations sensibles) vers un logiciel intrus, ces canaux de communication découlant de certaines fonctionnalités du matériel (mémoires caches, notamment). Les attaques par canaux cachés n’ont rien de nouveau.

Une attaque par canal caché tend à recouvrer des informations secrètes en exploitant des effets indirects de l’exécution du programme manipulant ces données. Par exemple, dans le cas de cartes à puce contenant des clefs cryptographiques secrètes et qui doivent le rester, on a appliqué des attaques consistant à mesurer finement la consommation électrique instantanée de la carte à puce ou son rayonnement électromagnétique. Dans le cas de logiciels sensibles s’exécutant sur la même machine que des logiciels malveillants (cas réaliste par exemple dans le cas de cloud computing, où des applications de plusieurs clients fonctionnent sur le même serveur), le logiciel malveillant peut notamment observer de petites fluctuations de son temps d’exécution dues à l’activité du logiciel sensible. Je n’ai pas le temps ce soir de rechercher les premières propositions de ce type d’attaques, mais je relève notamment l’attaque de Daniel J. Bernstein en 2005 contre des logiciels implantant le standard de chiffrement AES.

Ce type d’attaques est maintenant tellement représenté dans la littérature scientifique et technique que certains logiciels sont « durcis » pour éviter de laisser prise à ces observations exploitant l’isolation imparfaite fournie par les processeurs. Par exemple, pour éviter que des mesures fines du temps qu’un logiciel met à chiffrer des données ne soient exploitées pour retirer des informations sur les clefs cryptographiques, on mettra en œuvre du chiffrement en temps constant. Pour éviter que des informations ne fuient par les caches (je ne vais pas expliquer en quoi cela consiste, c’est assez technique), on va programmer les logiciels d’une façon à ne pas avoir d’action sur le cache qui permette de dériver des informations sur les données secrètes. D’ailleurs, un des buts d’une thèse que je dirige, celle de Valentin Touzeau, est d’analyser les logiciels pour détecter de telles vulnérabilités.

Il y a déjà eu des trous de sécurité importants dans le matériel, y compris d’Intel

Certains matériels Intel contiennent, en sus du processeur principal, un processeur auxiliaire nommé « moteur de gestion », caché du système d’exploitation installé sur le processeur principal et comportant son propre système d’exploitation et logiciels. En 2017 il a été révélé que ce moteur de gestion était vulnérable à des attaques.

Ce n’est pas la première fois qu’il y a des trous de sécurité importants nécessitant des mises à jour massives chez les prestataires d’hébergement

Je ne vais pas refaire l’historique de tous les trous de sécurité trouvés dans les logiciels utilisés chez les hébergeurs et me contenterai de mentionner le fait suivant. En 2008, donc à une époque où les services en ligne étaient déjà bien développés, avec beaucoup d’informations personnelles stockées chez des prestataires, on s’est aperçu que le générateur de clefs cryptographiques SSH et SSL livré notamment dans les distributions Linux Debian et Ubuntu avait été modifié, apparemment par erreur naïve et non par malice, de sorte que toutes les clefs générées étaient vulnérables. Cela voulait dire que des gens malveillants pouvaient se faire passer auprès de divers systèmes pour des utilisateurs ou administrateurs légitimes, ou encore intercepter des communications Web réputées sécurisées (le fameux logo cadenas) en se faisant passer pour un site légitime et récupérer toutes les informations secrètes transmises (mots de passe, y compris bancaires, etc.).

Malgré l’importance et la stupidité de ce bug, qui a nécessité une mise à jour d’urgence dans un très grand nombre de systèmes (y compris des systèmes non basés sur Debian ou Ubuntu, puisque ce qui compte c’est la machine qui avait généré les clefs), la presse grand-public n’en a pas parlé.

Il existe de la recherche universitaire en sécurité informatique

Il existe dans les universités, ou des organismes tels que le CNRS ou l’INRIA, de la recherche en sécurité informatique. Celle-ci n’est l’apanage ni des entreprises privées telles que Google, ni des organismes très orientés applications industrielles tels que le CEA, ni des services gouvernementaux spécialisés comme l’ANSSI ou la DGA-MI. D’ailleurs, les vulnérabilités MELTDOWN et SPECTRE ont été découvertes conjointement par des chercheurs de l’université technique de Graz, en Autriche, et une jeune chercheuse de cette équipe a rejoint le CNRS l’an dernier.

Ce qui est en revanche exact, c’est que les entreprises comme Google, Amazon, Facebook ou Microsoft ont des moyens sans commune mesure avec les laboratoires universitaires. Ainsi, il y a quelques années, j’ai vu un collègue recruter pour une des équipes de sécurité chez Google ; il « faisait son marché », envisageait de débaucher des universitaires (dont moi), etc., avec un budget pour 20 personnes. Par comparaison, le CNRS, tous laboratoires confondus, recrute cette année, est c’est exceptionnellement généreux, 2 jeunes chercheurs en sécurité informatique.

Où est la nouveauté ?

La nouveauté consiste en l’utilisation active de l’exécution spéculative des processeurs à hautes performances, conjointement aux canaux cachés.

Quel impact ?

À lire certains, la vulnérabilité MELTDOWN aurait permis de lire à volonté n’importe quelle portion de la mémoire de la machine attaquée. Or, après lecture plus approfondie des documents publiés par Intel et Google, on s’aperçoit que les données attaquables sont celles résidant en mémoire cache de niveau 1 au moment de l’attaque, ce qui est une infime portion de la mémoire de la machine. Un des codes de démonstration de la faille qui circule publiquement fait juste avant l’attaque un appel au système qui a pour effet secondaire de charger dans le cache de niveau 1 des informations qu’il va ensuite lire via MELTDOWN ; ce code de démonstration se contente cependant de provoquer le chargement de données absolument pas sensibles. Il n’est pas évident pour moi qu’il soit possible de forcer le système d’exploitation à manipuler des données sensibles de façon à ce qu’elles soient disponibles en cache de niveau 1 au moment de l’attaque (il est cependant possible qu’il y ait un autre volet de l’attaque qui n’ait pas encore été rendu public au 8 janvier et que la présence dans le cache L1 ne soit pas nécessaire).

En l’état de mes informations, je ne comprends donc pas trop l’urgence qu’il y a à mettre en œuvre des contre-mesures, éventuellement mal maîtrisées ou occasionnant des pertes notables de performance, contre l’attaque MELTDOWN.

J’insiste cependant que je ne suis pas un expert en sécurité informatique de bas niveau, et que je n’ai accès à aucune information secrète.

En revanche, les attaques MELTDOWN et SPECTRE m’inquiètent en ce qu’elles démontrent que les processeurs actuels, avec leurs nombreux dispositifs destinés à augmenter les performances, notamment les mémoires cache et l’exécution spéculative, sont devenus d’une telle complexité qu’il existe des interactions insoupçonnées des créateurs de ces systèmes. La compartimentation proposée par ces processeurs est très imparfaite et il est difficile de penser à tous les biais possibles d’attaque. On peut également se poser des questions sur le modèle de sécurité basé sur la séparation mémoire matérielle entre processus, et des processus entre utilisateurs : est-il adapté à une époque où le navigateur Web exécute des logiciels de toute provenance à l’aide de mécanismes complexes et donc potentiellement vulnérables ? Je n’ai évidemment pas de réponse à ces questions.

PS: L'hyperthreading peut sans doute aussi aboutir à ce que certaines données sensibles soient chargées en cache...

lundi, janvier 8 2018

MELTDOWN wonderment

It seems that the Meltdown leak only happens if (kernel) data is in the L1 cache.

This seems like an onerous restriction on applicability of the attack : it is like one would have to make a system call to the kernel which would read the secret data just prior to the attack.

This is a far cry from the first comments on the issue, which implied that any memory accessible by the kernel (thus, in Linux and MacOS X at least, all of physical RAM) was readable.

Or is there something not yet public ?

samedi, janvier 6 2018

MELTDOWN implemented

I now have a working implementation of the MELTDOWN attack, which I developed in about one day after reading the Lipp et al. paper. It is not pretty; the one from Pavel Boldin is much more complete.

I got stuck for hours, not understanding why I could not transfer information depending on secret data through the side channel, until I read Pavel Boldin’s implementation and realized that just before conducting the attack, he made a system call that made the kernel read the secret data under attack (as an example, he read from /proc/version, which makes the kernel read from a format string known as linux_proc_banner, and then checked that he could that format string from the supposedly protected kernel memory).

I suppose that the reason is that this loads the string into some of the CPU caches, which would imply that the MELTDOWN attack only works for data that is already in some of these caches. I suppose that if a cache reload of the secret data is needed, then the protection check will be performed before the speculative loads are performed.

I am unsure whether there is a method to force the cache loading of arbitrary protected memory locations.

I also have a working implementation for breaking kernel address space layout randomization (KASLR). I simply implemented the ideas from Jang et al., Breaking Kernel Address Space Layout Randomization with Intel TSX: namely, it takes fewer CPU cycles to generate a protection fault against a mapped, but protected, page, than for unmapped space; in both cases this generates a segmentation violation, but no trap is generated if the illegal accessed is wrapped in a transaction (Restricted Transactional Memory). It is sufficient to measure the time taken to complete the transaction, on my machine it is about 186 cycles when mapped versus 200+ cycles when unmapped.

PS: My idea about the data needing to be inside a close cache is confirmed by Intel's analysis:

For instance, on some implementations such a speculative operation will only pass data on to subsequent operations if the data is resident in the lowest level data cache (L1). This can allow the data in question to be queried by the application, leading to a side channel that reveals supervisor data.


vendredi, janvier 5 2018

Pourquoi l'informatique devient incompréhensible, et l'impact sur la sécurité

Les failles de sécurité SPECTRE et MELTDOWN sont, comme je l’ai expliqué dans des billets précédents, des attaques par canaux cachés. Il me semble pertinent de prendre ici un peu de recul sur ces questions ; je n’aurai pas la prétention de dire qu’il s’agit de philosopher, mais c’est un peu l’idée.

Grosso modo, quand on programme, on décrit une suite d’opérations à exécuter par la machine pour obtenir le résultat désiré. Le sens, on dit aussi la sémantique, de ces opérations est documenté, que l’on programme dans un langage de programmation de haut niveau (Python, C++, Prolog…) ou en langage machine (Intel x86…). Plus précisément, ce qui est documenté c’est la sémantique fonctionnelle, c’est-à-dire le résultat des opérations (par exemple, l’opération d’addition réalise une addition, sous réserve que le résultat ne dépasse pas un certain nombre de chiffres, etc.). Il existe en revanche diverses propriétés non fonctionnelles peu documentées et souvent difficilement prévisibles : le temps de calcul, la consommation électrique, etc. Naturellement, il est bien plus facile de raisonner sur les propriétés fonctionnelles que sur les propriétés non fonctionnelles.

Les mécanismes de sécurité incorporés aux langages, processeurs et systèmes d’exploitation modernes visent les propriétés fonctionnelles : notamment lorsqu’un programme tente d’accéder à des données auxquelles il n’a pas accès, cet accès est refusé. On peut ainsi isoler les uns des autres différents programmes, différents utilisateurs.

Il est toutefois bien plus difficile d’isoler les aspects non fonctionnels. Par exemple, si je lance un logiciel sur une machine, même si je n’ai pas officiellement le droit de lire la table des logiciels lancés par d’autres utilisateurs, je peux savoir qu’un autre logiciel est lancé si le mien est ralenti. Par des mesures plus fines, je peux même éventuellement me douter de ce qu’il fait : par exemple, s’il est dans une phase de calcul intensif sans grands accès à la mémoire principale, mes accès à la mémoire principale ne seront guère ralentis, tandis que s’il fait beaucoup d’accès, il ralentira les miens. D’une façon générale, plus il y a de ressources partagées (temps de calcul, mémoire, etc.) entre plusieurs utilisations, plus il y a la possibilité de passer des informations via des propriétés non fonctionnelles entre des domaines qui, a priori, sont fonctionnellement isolés. On appelle cela des canaux cachés.

Il y a maintes façons d’utiliser les canaux cachés. Par exemple, si on a la possibilité de faire fonctionner, sur la même machine, un logiciel qui a accès à une base de données sensibles mais n’a pas accès aux communications réseau et un logiciel qui n’a pas accès à la base de données et a accès aux communications réseau, séparés fonctionnellement (pas de canal de communication officiel entre les deux), on pourra transmettre des informations de l’un à l’autre par un canal caché (par exemple, mais il existe bien évidemment des méthodes plus efficaces, en alternant des périodes d’accès mémoire intensifs et faibles en une sorte de code Morse). La nouveauté des attaques MELTDOWN et SPECTRE est qu’il est possible de faire exécuter à un logiciel disposant d’accès privilégié aux données des instructions qu’il ne devrait pas vraiment exécuter, et qui n’ont d’ailleurs pas d’effet fonctionnel, mais conservent leurs effets non fonctionnels. Ce qui permet à ces attaques de fonctionner, c’est que diverses ressources matérielles (et notamment des mémoires cache) sont partagées entre des logiciels privilégiés (noyau du système d’exploitation, navigateur Web…) et non privilégiés (simple application, code Javascript d’une page Web…).

La complexité des machines actuelles, due à la recherche de hautes performance, avec la présence de nombreuses ressources partagées, est telle qu’il est difficile d’éviter les canaux cachés. Elle rend également difficile de démontrer quoi que ce soit de précis sur les propriétés non fonctionnelles, notamment le temps d’exécution. C’est un problème qui concerne notamment ceux qui veulent produire des dispositifs matériels répondant sous un certain délai garanti, par exemple des systèmes qui contrôlent des avions : comment, dans un système mettant en jeu plusieurs cœurs de processeur partageant de la mémoire, chacun avec des mémoires cache compliquées, garantir que l’exécution d’un programme prendra moins d’un centième de seconde dans tous les cas ? Nous sommes loin de ces processeurs des années 1980 dont la documentation donnait le temps d’exécution de chaque instruction...

Si l’on peut résumer une bonne partie de l’informatique depuis 70 ans, tant côté logiciel que matériel, on a progressivement éloigné le programmeur de l’exécution physique sur la machine, en rajoutant de plus en plus de couches de traduction, d’émulation, de virtualisation… Il y a d’excellentes raisons à cela : il est bon que le programmeur n’ait pas à se préoccuper des détails matériels de chaque machine, au risque que son programme ne fonctionne plus sur le modèle sorti un an après ; on peut mutualiser des ressources (dans un avion ou une voiture, mettre plusieurs tâches sur le même calculateur au lieu de mettre plusieurs calculateurs ; dans le cloud, mettre plusieurs utilisateurs indépendants sur le même serveur…). Cet éloignement nous empêche toutefois de bien appréhender les canaux cachés et propriétés non fonctionnelles.

Plus généralement, on a assisté à une bureaucratisation de la programmation. Sur un ordinateur personnel des années 1980, si l’on voulait dessiner une forme dans l’écran, il suffisait, au pire, d’aller écrire les valeurs des couleurs désirées dans la mémoire destinée à l’affichage vidéo : on voulait du bleu, on écrivait un code dans une case mémoire et on avait du bleu. Maintenant, il faut en quelque sorte remplir une série de formulaires administratifs pour avoir le droit de demander à un autre logiciel d’allumer le point. C’est la différence entre faire des travaux soi-même chez soi et demander au service de l’entretien d’envoyer un ouvrier les faire… Dans le premier cas, on maîtrise évidemment mieux ce qui est effectivement fait.

L'attaque MELTDOWN

Les réseaux sociaux et les blogs spécialisés en sécurité bruissaient de rumeurs depuis une semaine (pourquoi des modifications si urgentes dans le système de gestion de mémoire du noyau Linux, alors que d’habitude il faut des mois et des mois pour que le moindre changement soit accepté ?). Comme d’habitude lorsque des trous de sécurité majeurs sont découverts, ceux-ci n’étaient documentés que sous embargo, c’est-à-dire qu’on a d’abord informé les industriels ou groupes de développeurs susceptibles de fournir des correctifs, en leur laissant un délai suffisant, avant de publier les articles décrivant les problèmes.

Il y a en fait deux catégories d’attaques publiées ce jour : MELTDOWN et SPECTRE, qui partagent certaines caractéristiques. J’ai publié un autre billet sur SPECTRE, dont je vais reprendre ici quelques éléments explicatifs. Je vais discuter ici de MELTDOWN, en me basant sur la lecture de l’article décrivant les attaques (Lipp et al., Meltdown). Les attaques MELTDOWN sont celles contre lesquelles Microsoft, Apple et les développeurs de Linux ont intégré des contre-mesures. Je vais tenter de les expliquer à un niveau ne nécessitant pas de connaissances particulières en informatique.

Lire la suite...

jeudi, janvier 4 2018

L'attaque SPECTRE

Les réseaux sociaux et les blogs spécialisés en sécurité bruissaient de rumeurs depuis une semaine (pourquoi des modifications si urgentes dans le système de gestion de mémoire du noyau Linux, alors que d’habitude il faut des mois et des mois pour que le moindre changement soit accepté ?). Comme d’habitude lorsque des trous de sécurité majeurs sont découverts, ceux-ci n’étaient documentés que sous embargo, c’est-à-dire qu’on a d’abord informé les industriels ou groupes de développeurs susceptibles de fournir des correctifs, en leur laissant un délai suffisant, avant de publier les articles décrivant les problèmes.
Il y a en fait deux catégories d’attaques publiées ce jour : MELTDOWN et SPECTRE. Les attaques MELTDOWN sont celles contre lesquelles Microsoft, Apple et les développeurs de Linux ont intégré des contre-mesures. Je vais ici discuter des attaques SPECTRE, contre lesquelles il n’y a, à ma connaissance, pas de contre-mesure. Je me base pour cela sur la lecture de l’article décrivant les attaques (Kocher et al., Spectre Attacks: Exploiting Speculative Execution), article très pédagogique au moins au début. Je vais tenter de les expliquer à un niveau ne nécessitant pas de connaissances particulières en informatique.

Lire la suite...

vendredi, juin 6 2014

Comment ne pas traiter les problèmes

Le « classement vertical » a de l'avenir.

Lire la suite...

jeudi, janvier 30 2014

Architectures simples

Qu'est-ce qui existe comme processeurs/microcontrôleurs encore vendus actuellement, qui peuvent se programmer en C, et qui sont suffisamment simples pour que l'on puisse connaître facilement le nombre de cycles par instruction ? (Typiquement, pas de cache, pas de pipeline.)

PS Pour le moment, Atmel AVR et Freescale HCS12, mais c'est du 8/16 bits, j'aimerais en trouver en 32 bits.

lundi, novembre 11 2013

La sécurité de l'informatique embarquée en automobile

Mes fidèles lecteurs savent que je me suis plutôt intéressé à l'informatique embarquée dans les avions (qui, au moins pour la partie la plus critique, répond à des normes draconiennes).

Cet article en dit long sur le laxisme qui règne dans une partie de l'industrie automobile.

Un fait glaçant : certains dispositifs étaient tellement mal conçus qu'il est concevable qu'ils ait mal fonctionné sans pour autant positionner de code d'erreur. La preuve dans le procès évoqué repose sur les traces de freinage indiscutablement visibles sur la route ; gageons que les avocats du constructeur auraient sinon prétexté que le conducteur n'avait pas freiné...

PS On dirait un peu le Therac-25 (multi-tâche mal maîtrisé, etc.). À propos de parallélisme, une anecdote : j'ai un jour demandé à Donald Knuth ce qu'il pensait de ce sujet, et il m'a dit qu'il l'avait toujours soigneusement évité...

mardi, janvier 8 2013

Une question technique

Sur Empty Spaces (Pink Floyd), ou encore dans des versions concert de Parisienne Walkways (Gary Moore) ou Black Star (Yngwie Malmsteen), on entend parfois des sons de guitare tenus longtemps voire très longtemps.

  1. Quel est le procédé technique ?
  2. Certains modèles de guitare sont-ils plus adaptés ?
  3. S'il s'agit tout simplement d'avoir un gain de distortion ou un compresseur monstrueux, comment n'ont-ils pas un bruit énorme ?

lundi, août 29 2011

Conseils FAI et téléphone Android

Suite à diverses circonstances, je dois changer de FAI et de téléphone portable. J'envisage de prendre Free, mais j'hésite entre Freebox v5 et v6 (je ne compte pas utiliser la TV, mais les fonctionnalités serveur d'impression et SAN sont sympa), et pour le téléphone j'envisage un Android mais je ne sais pas lequel.

Des avis ?

lundi, avril 11 2011

I feel a little uncomfortable about computerized medical devices, and here's why

When I speak about safety-critical software, I tend to speak about civil aviation, because I've worked with Airbus for a number of years and I have some grasp of the kind of problems, regulations and technical solutions in that field. Civil aviation, however, is just the tip of the iceberg; there are other areas where failure of computer systems may have catastrophic consequences.

Lire la suite...

mercredi, février 3 2010

Informatique embarquée

Dans les réunions professionnelles auxquelles j'assiste, j'entends parfois dire du mal de l'informatique embarquée dans les automobiles (faiblesse des normes de sécurité, systèmes distribués avec recours massif aux sous-traitants, absence de redondances...) ; celle-ci ne se compare pas à ce que l'on fait en aviation civile, par exemple.

Le Washington Post mentionne que les autorités américaines ne se satisfont pas des explications de Toyota blâmant certains incidents sur des pédales d'accélérateur « collantes » (je suppose qu'elles se coinçaient en position d'accélération) et des tapis de sol inadaptés. Leur attention se porte sur la chaîne de commande électronique (informatisée) de l'accélération.

Quant aux autorités australiennes qui enquêtent sur les graves incidents du Vol Qantas 72 (l'avion avait fait de lui-même une manœuvre d'urgence avec descente rapide, blessant notamment les passagers debout ou assis sans leur ceinture), elles se penchent sur un éventuel dysfonctionnement du système de commande de vol électrique primaire (FCPC). Airbus va d'ailleurs fournir une mise à jour de ce logiciel suite à cet incident.

jeudi, janvier 7 2010

Les normes sur les tubes de Pitot des avions de lignes seraient inadaptées

Je viens de lire le second rapport d'étape du BEA sur l'accident du vol AF 447, avion immatriculé F-GZCP.

La page 74 est glaçante, sans mauvais jeux de mots :

L’examen des événements répertoriés d’UAS en croisière a montré que la plupart se situaient en dehors de l’enveloppe décrite dans l’Appendice C. En effet, les critères de certification ne sont pas représentatifs des conditions réellement rencontrées à haute altitude, par exemple en matière de températures. De plus, il apparaît que certains points, la taille des cristaux de glace au sein des masses nuageuses par exemple, sont mal connus et qu’il est difficile de ce fait d’évaluer les conséquences qu’ils peuvent avoir sur certains équipements, notamment les sondes Pitot. Dans ce contexte, les tests destinés à la validation de ces équipements ne paraissent pas adaptés aux vols à haute altitude.

Autrement dit, les normes ne sont pas assez sévères pour assurer la sûreté de vol des avions à haute altitude dans des masses nuageuses.

Plus polémique, le blog de Henri Marnet Cornus.

(SInon, personne ne semble évoquer la possibilité d'un bug ou d'un plantage informatique. Un point positif, Airbus est très à cheval sur son avionique critique.)