La vie est mal configurée

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

samedi, mai 26 2018

Un humain tellement inhumain

La ministre de l’enseignement supérieur et de la recherche, Mme Frédérique Vidal, a expliqué qu’un des buts de ParcourSup par rapport à APB est de « remettre de l’humain » ; à l’opposé certains jugent « inhumain » le nouveau processus. Humain, inhumain, voilà qui mérite une petite analyse de vocabulaire.

Clairement, Mme Vidal considère qu’un processus plus humain est intrinsèquement meilleur, comme, dans d’autres contextes (alimentation, pharmacie), on considère souvent de nos jours que ce qui est « naturel » est intrinsèquement meilleur. L’« humain », le « naturel », sont considérés comme bons, par opposition à l’automatique, à l’artificiel, considérés comme mauvais.

Pourtant, quoi de plus humain, pour un·e enseignant·e, que de « saquer » une élève jugée « trop sûre d’elle pour son propre bien » car elle a d’excellentes notes dans d’autres disciplines, ou encore un étudiant dont les options politiques ou syndicales déplaisent ? Quoi de plus humain que de noter favorablement, même inconsciemment, un élève que l’on juge agréable ? Quoi de plus humain, pour des étudiants s’estimant mal notés, que de soupçonner l’existence de favoritisme ou de discrimination ?

Pour toutes ces raisons, on a très largement adopté dans l’enseignement supérieur, les examens et les concours, la correction sur copies anonymes. Pourtant, n’est-il pas déshumanisant de remplacer le nom de l’étudiant par un numéro d’ordre ?

Ainsi, ce qui est plus humain, au sens d’une plus grande intervention des sentiments et jugements humains, n’est pas forcément plus juste ou meilleur… ni même d’ailleurs plus humain au sens de respectueux de la dignité humaine.

Quant à ParcourSup, on soutient parfois qu’il s’agit d’un processus plus humain que l’algorithme APB parce qu’il pose des questions successives aux candidats au lieu de les affecter à la suite d’un calcul à partir de l’ordre de leurs préférences. Là encore, on semble considérer qu’il est meilleur d’impliquer l’humain à chaque étape plutôt que de lui demander de se fier au résultat ultime d’un calcul qu’il n’effectue pas lui-même. Attitude curieuse ! Comme si une moyenne de notes calculée à la main était plus humaine qu’une moyenne calculée à l’aide d’un tableur. De fait, l’allongement de la durée du processus due à l’attente des réponses des candidats, bref de leur facteur humain, conduit à une attente et une angoisse que certains jugent inhumaine.

Ainsi, cet argument de l’humanité du nouveau processus confond plusieurs sens de « humain » : « Qui appartient à l'homme, qui lui est propre » (on demande une intervention du candidat à chaque étape », « Qui épouse pleinement la nature humaine dans ses qualités et ses défauts » (y compris la subjectivité de son jugement), et « Qui est sensible à la pitié, qui fait preuve d'indulgence, de compréhension envers les autres hommes ». C’est ainsi qu’avec un processus humain selon les deux premiers sens celui-ci peut s’avérer inhumain au sens du troisième.

samedi, mars 17 2018

Ma gestion des conflits d'intérêts

Dans la recherche scientifique, nous avons souvent à nous préoccuper de conflits d’intérêts. On pense évidemment à ceux des chercheurs qui travaillent sur un sujet tel que les produits pharmaceutiques, les pesticides, etc., où il y aurait intérêt à biaiser les résultats des études en faveur de tel ou tel industriel qui financerait les recherches, ou emploierait par ailleurs le chercheur comme consultant (on en trouve facilement des exemples dans l’actualité). Dans mon domaine de recherche, ces problèmes ne se posent guère. En revanche, se pose souvent le problème des conflits d’intérêts lorsqu’il s’agit d’évaluer leurs collègues ou leurs travaux.

Les travaux scientifiques sont évalués avant leur publication en revues, comptes-rendus de conférence, ou ouvrages, du moins chez les éditeurs scientifiques sérieux : le travail répond-il aux standards de qualité de sa discipline ? Quant aux scientifiques (au sens large, j’inclus les universitaires de toute discipline), ils sont évalués, à divers points de leur carrière. Les évaluateurs sont, habituellement, des scientifiques plus ou moins du même domaine (pour évaluer une publication très technique, on prendra des spécialistes, alors que pour évaluer une carrière on pourra prendre des évaluateurs plus loin thématiquement). Fatalement, ces évaluateurs connaissent parfois les auteurs des articles, les candidats aux promotions. Certains critiquent d’ailleurs un fonctionnement « par cooptation » ; mais il est difficile de faire autrement : pour évaluer quelqu’un pour un poste en France, avec un dossier en français et dans le contexte particulier de l’enseignement supérieur et la recherche français, en général il faut un français du même domaine, qui n’est pas si vaste.

Il se pose donc des conflits d’intérêts. Voici donc comment je gère ceux-ci quand c’est moi l’évaluateur.

Le malaise

Il m’est arrivé que l’on me demande de rédiger un rapport sur le dossier d’une personne que j’apprécie beaucoup. Je ne rentrais dans aucune des conditions que l’organisme commanditaire de l’évaluation considérait comme constituant un conflit d’intérêts, et pourtant je me sentais mal à l’aise. Je fis ce travail mais in fine j’aurais préféré que cela fût quelqu’un d’autre.

Premier critère pour moi : je peux refuser une évaluation, même si je ne rentre dans aucun cas officiel de conflit d’intérêts, si celle-ci me met mal à l’aise d’une façon ou d’une autre.

(Par ailleurs, je me suis retrouvé à devoir donner mon avis sur la candidature de quelqu’un dont j’appréciais humainement la compagnie, mais dont la compétence ne me paraissait pas suffisante pour le poste. Cette personne, l’ayant appris, m’en a par la suite durablement voulu. Ce genre de problèmes est également à prendre en compte.)

L’apparence du favoritisme

Imaginons que j’évalue un dossier sans éprouver d’inconfort en le faisant, que je ne rentre dans aucun des cas de conflit d’intérêts identifiés par le commanditaire de l’évaluation. Je risque cependant, dans certains cas, que certains se fassent la réflexion que j’aurais agi par favoritisme ou, au contraire, inimité, s’il y avait entre moi et la personne à évaluer des liens, réels ou supposés, positifs ou négatifs, remettant en cause mon objectivité.

Second critère : éviter ce qui pourrait donner lieu à mauvaise interprétation.

Les critères du commanditaire

Certains commanditaires d’évaluation ont une liste officielle de critères signalant un conflit d’intérêt (par exemple, avoir été directeur de thèse du candidat, avoir co-signé une publication avec lui pendant les 3 dernières années...) ; d’autres non. Dans tous les cas, si j’estime avoir un conflit d’intérêts (réel ou potentiel), j’explique les faits au commanditaire et je le laisse estimer si ceux-ci constituent ou non un conflit d’intérêts en son sens. En effet, je n’ai pas à me substituer à lui en ce qui concerne la politique de son organisme, de son éditeur, de sa revue…

Ainsi, dans ce domaine comme dans d’autres, je sépare bien ce qui relève d’une éthique personnelle (qui, en l’espèce, relève plus du désir d’éviter des situations inconfortables que d’un questionnement purement moral) de ce qui relève d’une question de politique des organismes ou des publications, où je laisse la décision à ceux qui en ont la responsabilité.

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...

samedi, décembre 2 2017

Quelques remarques sur l'apocalypse logicielle à venir

J’ai eu l’agréable surprise de trouver dans The Atlantic, magazine grand public, un article sur des thèmes proches de ceux de certaines de mes recherches, qui plus est, ce qui est surprenant pour un magazine américain, avec des mentions de technologies informatiques françaises. J’ai plus de réserves, en revanche, sur le titre (The coming software apocalypse) et ce qui était visiblement un titre de travail (Saving the world from code).

Il me semble que la courte histoire de l’informatique est jalonnée d’articles (dans des revues plus spécialisées) expliquant que les façons de programmer les plus répandues ne pourraient plus durer et qu’il faudrait passer à d’autres approches, naturellement celles promues par la personne qui a rédigé l’article ou les personnes interrogées, suivis d’articles disant le contraire. Je ne retrouve hélas pas les références, mais je me souviens d’articles des années 1970 qui disaient le premier qu’il faut passer aux « méthodes formelles » pour raisonner sur les programmes et ainsi éviter les bugs, le second que ces méthodes formelles ne fonctionnent que sur de petits exemples jouets et ne sont pas adaptés à l’immense majorité des développements logiciels. Ceci devrait nous rassurer sur l’apocalypse à venir : d’autres apocalypses étaient déjà annoncées et ont été surmontées !

Passons maintenant au fond. On peut définir la programmation informatique comme l’activité de passer de la spécification de ce qu’un logiciel devrait faire à un programme effectivement exécutable par un ordinateur, comprenant une phase d’analyse (décomposition du problème en sous-problèmes jusqu’à ce que ceux-ci deviennent traitables par une machine) et une phase de programmation proprement dite, c’est-à-dire le passage d’idées abstraites (algorithmes, structures de données, interactions entre composants…) à un programme. (Ces deux phases ne se succèdent pas forcément dans le temps : on peut commencer de développer le logiciel, avoir un fonctionnement partiel, analyser ce qui manque, le programmer, etc.) La difficulté de la programmation, c’est l’éloignement entre la spécification et ce que la machine sait effectivement faire.

Dans sa forme la plus primitive, la programmation consiste à produire une suite d’instructions en langage machine, c’est-à-dire des codes numériques correspondant à des opérations à faire exécuter (par exemple, il existe un code pour demander une addition). C’est extrêmement fastidieux (il faut non seulement coder les instructions mais aussi se souvenir de numéros désignant les endroits où l’on a stocké les données) tout en nécessitant une grande minutie. Un premier progrès a été la possibilité de programmer en langage d’assemblage, c’est-à-dire en écrivant les noms des instructions (par exemple « add a,5 » pour demander d’ajouter 5 au registre a) et en laissant un logiciel, l’assembleur, calculer tout seul les numéros des stockages de données. Toutefois, cela revenait encore à descendre à un grand niveau de détail technique pour exprimer ce que l’on voulait faire.

On a donc proposé des langages de programmation de plus haut niveau que le langage d’assemblage, en premier lieu Fortran, dont le nom est juste la contraction de l’anglais pour « traducteur de formules ». On écrivait des programmes décrivant des procédures de calcul (pour la physique, l’artillerie, etc.) dans un format textuel assez lisible (par exemple, pour dire que a prend la valeur de trois fois b plus un, on écrivait a=3*b+1, il y avait des ordres pour dire de répéter une séquence d’instructions un certain nombre de fois) et un logiciel appelé compilateur traduisait en langage machine. La productivité des programmeurs était considérablement augmentée : on éliminait l’étape fastidieuse de codage vers le langage d’assemblage voire le langage machine, et les bugs que celle-ci pouvait introduire (bien entendu, à supposer que le compilateur lui-même ne contienne pas de bugs). Il me semble même avoir lu que certains disaient que cela éliminerait les bugs ! Hélas, il restait évidemment les bugs de plus haut niveau : ceux dans l’enchaînement des instructions à répéter, les formules etc. (et éventuellement des fautes d’inattention dans l’écriture du Fortran).

D’une façon générale, l’évolution des langages de programmation, depuis l’époque lointaine du premier Fortran, a tendu vers plus d’expressivité : permettre aux programmeurs d’exprimer ce qu’ils veulent voir exécuté sous une forme plus proche de ce qu’ils ont à l’esprit et avec moins de détails propres au fonctionnement de la machine. Cette évolution a porté tant sur la phase d’analyse que sur celle de programmation. Pour la programmation, il s’agit de pouvoir écrire d’une façon simple des directives qui seront transformées par le compilateur en des suites d’instructions complexes. Pour l’analyse, il s’agit de la fourniture de bibliothèques d’algorithmes et de structures de données déjà prêtes, souvent conçues par des programmeurs plus experts que le programmeur qui les utilisent, et qui lui évitent donc de « réinventer la roue ».

La proposition de l’article d’en venir à une programmation basée sur les modèles est donc une évolution naturelle. Les concepteurs de systèmes automatiques de contrôle (par exemple, de pilotage d’avion) raisonnent en termes de traitement du signal : prendre la mesure d’un capteur, éliminer les variations trop rapides (des parasites), détecter quand il dépasse un certain seuil…, opérations qu’ils représentent à l’aide de boîtes reliées par des fils, par analogie avec les vraies connexions électriques, lorsque chacune de ces boîtes était mise en œuvre par un composant électronique. C’est ce que proposent par exemple Scade, cité dans l’article, ou encore Simulink. Cette représentation est plus visuelle et intelligible pour les ingénieurs automaticiens que la mise en œuvre de ce traitement du signal dans un langage tel que C ou Fortran.

Une représentation de haut niveau, proche du concept que veulent mettre en œuvre les programmeurs, peut permettre par ailleurs la mise en œuvre d’aides au développement, — notamment, dans le cas de l’automatique, des simulations de la chaîne de traitement du signal sur des signaux représentatifs du système physique (par exemple, capteurs et actionneurs d’une aile d’avion), afin de se rendre compte si elle a les propriétés attendues (comme dans Simulink). L’exemple du début de l’article relève de la même idée : plutôt que de demander au programmeur de fixer des coefficients numériques par essai et erreur, on va lui fournir une visualisation instantanée qui lui permettra de les régler.

Toutefois, contrairement à ce que laisse supposer l’article, l’utilisation de tels langages graphiques ne supprime pas les bugs. Prenons le cas de la commande de vol électrique d’un avion de ligne. On va la concevoir graphiquement, à l’aide d’outils adaptés aux représentations des automaticiens spécialistes d’avionique et de contrôle aéronautique, puis (je simplifie) la transformer automatiquement en un logiciel que l’on peut effectivement embarquer dans l’avion. Cette transformation automatique sera à la fois plus fiable et moins coûteuse en personnel qu’une programmation manuelle. Rien ne nous dit toutefois que les lois d’automatique et les dispositifs de protection contre les erreurs et pannes décrits dans la représentation graphique suffisent à garantir la véritable spécification, à savoir « l’avion vole correctement » !

Par ailleurs, pour chaque représentation plus proche des préoccupations du développeur, il faut développer des outils ad hoc. On peut avoir un Scade, un Simulink, pour toutes les applications d’automatique, mais on peut difficilement, pour chaque problème spécialisé, développer un outil destiné à mieux attaquer ce problème.

On entend actuellement en France un discours bien rôdé selon lequel nous ne formerions pas assez de développeurs, les formations des universités et écoles publiques étant inadaptées. Le très médiatique docteur en médecine Laurent Alexandre répond, lui, que de toute façon ces tâches de développement seront bientôt assumées par des intelligences artificielles et qu’il conviendrait donc plutôt de mettre l’accent sur les humanités. Je suis sceptique quant à cette affirmation, qui me semble reposer sur l’anticipation de progrès considérables en intelligence artificielle, dont nous n’avons aucune raison de penser qu’ils se produiront à l’échelle de quelques décennies. Par ailleurs, ce n’est pas la première fois que l’on annonce la fin de la programmation au sens courant du terme. Il me semble bien que l’on avait déjà annoncé dans les années 1980 le remplacement de celle-ci par la programmation logique concurrente et des intelligences artificielles, comme dans le projet japonais d’ordinateur de cinquième génération ; mais ce n’est pas ce qui s’est passé…


samedi, novembre 11 2017

L'enseignement très spécialisé est-il un modèle ?

Mon billet sur la publicité dont jouit l’école 42 et les remarques méprisantes que certains commentateurs font à l’égard de l’enseignement universitaire a suscité des réactions. Une intéressante discussion a pris place dans ses commentaires, et j’aimerais rebondir sur certaines réactions, notamment celles de Laurent Bloch et de Loys Bonod.

Dominique Seux remarquait

« Alors, évidemment, si on était caustique, on s’étonnerait que les milliers d’enseignants-chercheurs de nos grandes universités scientifiques n’aient pas eu l’idée de lancer des formations en développement informatique. »

Cette remarque, nous l’avons vu, est absurde, vu que justement il existe de telles formations au sein des universités. Toutefois, il est possible de la modifier pour lui donner du sens :

« Alors, évidemment, si on était caustique, on s’étonnerait que les milliers d’enseignants-chercheurs de nos grandes universités scientifiques n’aient pas eu l’idée de lancer des formations en développement informatique, centrées uniquement sur la programmation, à l’exclusion de toutes les autres questions informatiques, des autres disciplines scientifiques et de toute formation générale. »

En effet, il ne me semble pas qu’il existe dans les universités de formation ne comprenant que de la programmation, ni même, au moins au niveau de la première ou deuxième année après le baccalauréat, que de l’informatique.

Relevons tout d’abord que pareille hyperspécialisation irait à l’encontre de la politique annoncée par l’actuelle ministre de l’enseignement supérieur, qui prône des licences pluridisciplinaires avec spécialisation progressive (ce qui est d’ailleurs déjà le cas en sciences à Grenoble, par exemple).

Par ailleurs, rappelons que l’État réglemente les diplômes à validité nationale (licence, master…), que pour les diplômes universitaires de technologie il y a un programme national, que les universités traversent une mauvaise période financière, avec de grandes difficultés à assurer leurs fonctions de base, et que donc la liberté que les « milliers d’enseignants-chercheurs de nos grandes universités scientifiques » auraient de lancer de nouvelles formations atypiques est très limitée ; ce n’est pas simplement une question d’en avoir l’idée.

Laurent Bloch relève, à juste titre, que les formations d’informatique, au moins au début, sont souvent couplées avec des enseignements de mathématique et/ou de physique, qui peuvent rebuter les étudiants. Il souligne notamment qu’une grande partie des élèves sortent de l’enseignement secondaire en difficulté en mathématiques.

L’enseignement secondaire français, même lorsqu’il y a des filières, comprend un très large enseignement « général », allant du sport à la philosophie. Cet enseignement est obligatoire, quels que soient les goûts et aspirations des élèves, et l’utilité, éventuellement nulle, des disciplines enseignées pour leurs choix de carrière et la vie qu’ils envisagent. Il est courant que certaines de ces disciplines rebutent les élèves, qui ensuite en conçoivent un dégoût marqué et ne veulent plus les retrouver dans l’enseignement supérieur. C’est donc une question qui dépasse largement les mathématiques et la formation des « développeurs ».

Voyons toutefois le cas particulier de l’enseignement de l’informatique. Il est possible de se focaliser sur la programmation (éventuellement en se spécialisant sur tel ou tel langage, telle ou telle technologie Web, etc.) et d’ignorer tout le reste. L’inconvénient d’une telle formation est qu’elle mentionnerait des outils sans pour autant expliquer comment ceux-ci fonctionnent, alors que souvent, en informatique, il faut avoir une certaine connaissance (non détaillée) du fonctionnement interne des outils pour les utiliser efficacement. Par exemple (je m’excuse d’avance pour mes lecteurs non informaticiens si je deviens technique), les bibliothèques standard des langages de programmation modernes proposent des implantations efficaces des notions d’ensemble et de fonction à support fini, par arbres binaires, par tables de hachage, voire par liste ou tableau d’association. Chacun de ces cas correspond à certains usages, mais il est impossible de le savoir si on les utilise comme des « boîtes noires » sans chercher à comprendre leur fonctionnement. La conséquence probable d’une utilisation aveugle et « bricolée » sera un logiciel qui fonctionnera bien sur de petits jeux de données mais dont les performances se dégraderont très vite lorsque les données seront plus grandes. Il en est de même de la conception d’une base de données sans comprendre un peu le fonctionnement interne d’un moteur de bases de données.

En raison de cela, les formations classiques en informatique comprennent non seulement de la programmation, mais aussi de l’algorithmique et d’autres matières. Traditionnellement, l’enseignement de l’algorithmique s’appuie sur des démonstrations mathématiques, notamment des preuves par récurrence. De telles démonstrations passent au-dessus de la tête de bon nombre d’étudiants actuellement en informatique à l’université, et on leur substitue donc souvent des explications « avec les mains » (par exemple, on peut montrer la complexité en n log n du tri fusion par un petit dessin). De même, on peut expliquer les bases de données relationnelles avec des raisonnements ensemblistes, mais il est sans doute possible de limiter l’usage du vocabulaire mathématique. Il y a toutefois des limites qu’on ne peut pas dépasser en matière d’incompréhension mathématique sans entraîner l’incompréhension informatique.

On le voit, la question posée par 42 n’est pas seulement celle de l’école sans enseignant (il existe depuis longtemps des méthodes de langues, de musique etc. destinées à l’apprentissage sans enseignant, et personne ne s’en émeut). Elle est plutôt celle d’un apprentissage très étroit, produisant en quelque sorte des ouvriers du tertiaire avec peu de recul sur leur activité. Or, tandis que certains la couvrent de lauriers dans les médias, d’autres (voire parfois les mêmes) déplorent le « cloisonnement » des disciplines universitaires et des formations ; clairement les universitaires subissent des injonctions contradictoires !

mercredi, novembre 8 2017

Au sujet de l'école 42 et de la publicité dont elle bénéficie

Dominique Seux, chroniqueur aux Échos, a le lundi 6 novembre choisi d’évoquer la fameuse école 42 de Xavier Niel sur l’antenne de France Inter. Il a notamment déclaré :

« Alors, évidemment, si on était caustique, on s’étonnerait que les milliers d’enseignants-chercheurs de nos grandes universités scientifiques n’aient pas eu l’idée de lancer des formations en développement informatique. »

Si on était caustique à l’égard M. Seux, on relèverait que, justement, les enseignants-chercheurs des universités scientifiques ont lancé de telles formations depuis des décennies. Pour prendre des exemples locaux, l’École nationale supérieure d’informatique et de mathématiques appliquées de Grenoble (ENSIMAG) fut fondée en… 1960, le département informatique de l’institut universitaire de technologie (IUT) de Grenoble en 1966 ; les MIAGE (formations aux Méthodes informatiques appliquées à la gestion des entreprises) existent depuis 1969. Bref, rien de nouveau sous le soleil.

Puisque M. Seux évoque les « milliers d’enseignants-chercheurs de nos grandes universités scientifiques », rappelons qu’il y a de l’ordre de 3400 enseignants-chercheurs de statut universitaire en informatique. Je ne sais pas ce que M. Seux s’imagine qu’ils enseignent, peut-être de la théorie de haute volée ou de l’histoire de l’informatique ? Ce n’est pas le cas ! (Ou du moins, c’est très rarement le cas, évidemment à Normale Sup on peut se permettre de faire de la théorie de haute volée…) La grande majorité des enseignements portent sur ce que les étudiants doivent savoir pour occuper, plus tard, des emplois de développeur, administrateur système, etc.

Revenons sur 42. M. Seux indique (j’ignore si ces chiffres sont exacts) que cette école reçoit 50000 candidatures par an et n’en accepte que 900. C’est donc une école extrêmement sélective à l’entrée. Ensuite, si l’on en croit les informations diffusées par les médias, il y a une très forte pression de sélection interne (les étudiants qui n’arrivent pas à se débrouiller sont exclus). En résumé, il s’agit d’un enseignement (ou d’une absence d’enseignement) qui s’adresse à une très petite minorité.

Les universités, quant à elles, ont une mission d’enseignement très générale — on a beaucoup rappelé récemment qu’elles sont censées accepter tout bachelier (il existe également des voies d’accès sans baccalauréat). Il n’est pas clair que les méthodes « sans enseignants » qui conviennent à une infime minorité conviendraient au public de l’enseignement de masse. J’en doute même fortement. Je sais bien qu’il est tentant (on sent bien ce sous-entendu derrière le discours sur les milliers de fonctionnaires dont on se demande bien ce qu’ils font) de penser que l’on pourrait largement se passer de la masse salariale d’enseignants, mais tout ce qui est tentant n’est pas forcément possible.

Prenons un parallèle. Personne ne suggère que l’on supprime l’enseignement des mathématiques et qu’on le remplace par la mise à disposition de manuels et dispositifs informatiques. Pourtant, le grand mathématicien Srinivasa Ramanujan, lorsqu’il était adolescent, a en grande partie appris les mathématiques seul en s’aidant d’un ouvrage de synthèse. Imaginez les économies que l’on pourrait faire en se défaisant des professeurs de mathématiques de lycée !

Si j’évoque cette chronique, c’est parce que celle-ci s’inscrit dans tout un discours médiatique à l’égard de l’enseignement de l’informatique en France, où l’on oppose la modernité de l’école 42 aux pratiques supposées archaïques des universités, et où l’on vante l’enseignement privé. Pour ma part, j’ai un raisonnement simple : enseigner à une infime minorité sélectionnée est facile — je le sais, j’ai enseigné 13 ans à l’École polytechnique (*). La question difficile est celle de l’enseignement de masse, surtout si celui-ci doit déboucher sur des emplois (il me semble d’ailleurs que les diplômés d’informatique des universités n’ont en général aucun problème pour trouver un emploi). Pourquoi faut-il encore et encore rappeler pareilles évidences ?

(*) Et même à l'École polytechnique la grande majorité des enseignements d'informatique, en masse d'étudiants, portent sur les bases du développement de logiciels et non sur des aspects de haute volée.

mercredi, novembre 1 2017

L'égalité, concept plus difficile qu'il n'y paraît

En mathématiques, on manipule souvent des égalités, mais il n’est pas habituel, si l’on n’est pas logicien, de s’interroger sur ce que recouvre cette notion d’égalité. J’aimerais évoquer ici quelques problèmes que le traitement de l’égalité peut poser ; j’ai essayé dans la mesure du possible de donner des exemples familiers de tous. J’ai mis entre crochets des digressions plus techniques.

On définit parfois l’« égalité de Leibniz » ainsi : « deux objets sont égaux si toute propriété vraie de l’un est vraie de l’autre » ; autrement dit, ils sont indistinguables. Cette définition est séduisante, mais souffre de difficultés, comme nous allons le voir.

(Une petite parenthèse. On appelle cette définition « égalité de Leibniz », mais j’ignore si Leibniz l’a effectivement posée comme telle. En mathématiques, il n’est pas rare d’attribuer à des auteurs des définitions qu’ils n’ont pas posées mais qui sont dans le fil de leurs idées ou de définitions qu’ils ont posées. J’invite les historien·ne·s des mathématiques à laisser des commentaires...)

Prenons l’égalité d’école primaire, 1+3=3+1. Le membre de gauche, 1+3, est distinguable du membre de droite, 3+1 : le premier commence par 1 (ou, si on le voit comme arbre syntaxique, est un nœud + dont la branche de gauche est 1), le second par 3 ! Il est faux que toute proposition vraie de l’un est vraie de l’autre !

On m’objectera que mon critère est trop syntaxique et omet la sémantique de l’opération d’addition. Bien. Tentons donc de définir celle-ci : si l’on définit les entiers naturels comme étant soit 0 soit le successeur S(x) d’un naturel x, et que l’on considère 1 comme une notation pour S(0) et 3 comme une notation pour S(S(S(0))), on peut définir x+S(y) comme S(x+y) et x+0 comme x. Cela induit une notion de calcul : tant qu’on a une expression de la forme x+S(y) on peut la remplacer par S(x+y), jusqu’à ce qu’il ne soit plus possible de procéder à pareils remplacements — on dit que l’on obtient alors une forme normale. En termes techniques, on parle de système de réécriture, et effectivement les formes normales associées à 1+3 et 3+1 sont bien identiques.

[Cette définition par réécriture est séduisante, mais elle suppose que chaque terme ait une forme normale unique, ce qui n’est pas vrai en général ; on devra donc démontrer des propriétés de confluence et de terminaison du système de réécriture.]

Cette intervention du calcul n’est toutefois pas suffisante pour démontrer une égalité tout aussi familière, à savoir 0+x=x+0. En effet, si la réécriture transforme le membre de droite en x, le membre de gauche reste 0+x. Pour parvenir à démontrer l’égalité, on doit faire intervenir un raisonnement par récurrence sur x : on constate que c’est vrai pour x=0, que si c’est vrai pour x alors c’est vrai pour x+1, donc on conclut que c’est vrai pour tout x.

[La vision syntaxique n’est pas si stupide qu’il n’y paraît. Ceux qui ont fait de la logique se rappelleront peut-être comment on définit le domaine de Herbrand des termes, et que l’on peut construire (pour démontrer le théorème de compacité, le théorème de complétude ou le théorème de Lowenheim-Skolem) un modèle en quotientant ce domaine par une relation d’équivalence. La relation d’égalité sémantique est ainsi une relation d’équivalence entre termes (vus syntaxiquement) compatible avec les opérations et les prédicats (on parle de congruence) et avec le système d’axiomes.]

Prenons maintenant un autre exemple familier : les « fractions », ou, pour parler en termes plus savants, les nombres rationnels. On sait que 2/3=4/6. Pourtant, là encore, on peut distinguer 2/3 et 4/6 : ils n’ont pas le même numérateur ! Une notion d’égalité à la Leibniz n’est donc utilisable que si l’on restreint les propriétés par lesquelles on est autorisé à distinguer les éléments : on va ainsi interdire de faire intervenir des questions sur le numérateur ou le dénominateur. On va donc considérer comme égaux des éléments indistinguables selon une certaine définition de l’observabilité.

On peut également, en l’espèce, définir l’égalité sur les formes « réduites » des fractions, c’est-à-dire celles où un calcul a éliminé les facteurs communs au numérateur et au dénominateur (par exemple, dans 4/6, il y a un facteur commun 2 au numérateur et au dénominateur). Là encore, c’est une commodité appréciable…

Lorsque l’on définit les fractions, on parle de couples d’entiers — par exemple ici (2,3) et (4,6). Nous avons vu que ce n’est pas tout à fait exact, vu que l’on considère comme égaux tous les couples d’entiers qui se réduisent identiquement, bref toute une classe d’équivalence d’entiers — mais passons. Évoquons maintenant le fait bien connu que 2=4/2. 2 est un entier, 4/2 est une fraction donc un couple d’entiers ; a priori ces deux objets ne vivent pas dans le même univers — un entier, ce n’est pas la même chose qu’un couple d’entiers ! Nous les identifions pourtant ; si nous étions parfaitement rigoureux, nous devrions évoquer le fait que l’entier x et le rationnel x/1 se comportent exactement pareil du point de vue des opérations arithmétiques et des comparaisons, ce qui nous permet de les identifier (en termes savants, faire intervenir l’injection canonique des entiers dans les rationnels, préservant la structure d’anneau ordonné).

D’une façon générale, les écrits mathématiques usuels abondent de ces « abus de notation », de ces raisonnements « à équivalence près ». Il y a souvent, outre le discours de la preuve elle même, un méta-discours expliquant au lecteur comment combler les omissions et raccourcis : les « sans perte de généralité », les avertissements que certains objets distincts seront identifiés, etc. Tout ceci aide à alléger un discours mathématique qui, sinon, deviendrait trop lourd donc peu lisible et compréhensible pour les humains.

Les difficultés arrivent lorsque l’on transcrit des raisonnements rédigés pour des humains en des raisonnements destinés à être vérifiés étape par étape par une machin, par des logiciels tels que Coq. En effet, dans ce cas, il faut soit expliciter les identifications, abus de notation et autres détails de raisonnement qui avaient permis d’alléger la rédaction, soit utiliser des mécanismes du logiciel destinés à les reconnaître (par exemple, certains allègements de rédaction se traitent en Coq avec le mécanisme des structures canoniques ; les raisonnements à équivalence près se traitent par les setoids, etc.).

[Ces mécanismes ne sont toutefois par parfaits, loin s’en faut ; mon collègue Pierre Corbineau, lorsque je lui ai demandé à quel point on évitait les problèmes avec les setoids m’a dit « ça marche… sauf quand ça ne marche pas » (il me semble notamment qu’il est très difficile de raisonner modulo équivalence sur l’argument d’un type dépendant). On pourrait également mentionner le fait qu’en Coq, donner un élément vérifiant une certaine propriété (par exemple, donner un entier n inférieur à une certaine borne) revient à donner un couple formé de l’élément et d’une preuve que l’élément vérifie la propriété ; bien que rien d’effectivement observable ne dépende de quelle preuve est utilisée (on peut prouver le même fait mathématique d’une multitude de façons), on peut entrer dans de grandes complications en raison de la non identification d’objets ne différant que par les preuves. D’une façon générale, en Coq, on gagne à travailler avec des objects syntaxiquement uniques, ou, à défaut, avec des formes normales.]

On parle beaucoup, ces dernières années, de remplacer le traitement de l’égalité en théorie des types (notamment en Coq) par des fondations univalentes. Si j’ai bien compris, il s’agit de donner un meilleur traitement de l’égalité. Je ne comprends cependant pas le rapport entre d’une part les problèmes de raisonnement modulo équivalence et la solution proposée, basée sur des notions d’homotopie !

vendredi, septembre 22 2017

Les conférences ou revues scientifique bidons

Les chercheurs en informatique un tant soit peu expérimentés savent qu’il existe depuis longtemps (enfin, au moins depuis une vingtaine d’années) des conférences scientifiques bidons, c’est-à-dire des événements qui se donnent quelques apparences d’un vrai colloque, mais ne contrôlent pas valablement la qualité des interventions. Se sont rajoutées des revues bidons, c’est-à-dire des publications qui se donnent l’apparence de revues de publication scientifique mais qui, là encore, ne contrôlent pas valablement la qualité des articles publiés.

Dans certains cas, le manque de contrôle est tel que des articles générés aléatoirement, et absolument sans sens, ont été acceptés. L’outil SCIgen permet de produire des documents ayant superficiellement l’apparence d’articles de recherche en informatique (présentation, vocabulaire) mais absolument sans aucun sens ; son dérivé MathGen produit des documents ayant superficiellement l’apparence d’articles de recherche en mathématiques (y compris des formules), mais sans aucun sens là non plus. Dans un cas, un « article » consistant en la phrase Get me off Your Fucking Mailing List (« enlevez mon adresse de courrier électronique de votre putain de liste de diffusion ») répétée a été accepté, ce qui indique une absence totale de lecture avant acceptation.

Pourquoi ces revues et conférences bidons existent-elles ?

Sans prétendre lire dans les pensées des organisateurs de ces publications et événements, je soupçonne que leurs motivations sont les suivantes :

  1. Dans certains cas, il s’agit tout simplement d’une activité lucrative : la personne qui assiste au colloque (notamment pour y intervenir), l’auteur d’un article publié, payent une participation aux frais. Il suffit que celle-ci dépasse sensiblement les coûts d’organisation ou de publication pour qu’un bénéfice soit dégagé. (Notons que cela n’est pas propre aux publications bidons : certains grands éditeurs de revues scientifiques dégagent des marges considérables pour les mêmes raisons.)

  2. Dans certains cas, il s’agit d’une activité d’auto-promotion : un groupe de scientifiques ayant du mal à se faire reconnaître monte son colloque, sa revue, où ils s’évaluent les uns les autres.

Quant aux chercheurs qui soumettent des communications à ces revues ou conférences, je pense qu’il existe les cas suivants :

  1. Par inexpérience : ils ne font pas la différence avec une revue ou conférence sérieuse. Ceci me semble d’autant plus probable qu’ils sont écartés des circuits scientifiques habituels.

  2. Dans le cas de conférences organisées dans des endroits « intéressants », ils peuvent vouloir se faire payer un voyage aux frais de leur université, de leur organisme de recherche ou de l’organisme qui finance leurs travaux.

  3. Ils peuvent vouloir, en toute connaissance de cause sur la nullité de la revue ou conférence, allonger leur CV.

Rappelons que les chercheurs subissent une pression constante pour démontrer qu’ils font réellement de la recherche valable. La vérification de cela se fait souvent bureaucratiquement, par l’examen d’une liste de publications et d’autres activités (exposés dans des conférences internationales…). Il y a donc une incitation permanente à multiplier les publications et en tout cas à ne surtout pas apparaître comme « non publiant ». On voit parfois des obligations couperet, par exemple la délivrance d’un doctorat est subordonné à la publication d’au moins un article dans une revue internationale.

Comment distinguer les revues et conférences sérieuses des bidons ?

Il ne s’agit pas d’une science exacte, mais plutôt de l’application de bon sens et d’une connaissance des usages scientifiques. Ce qui suit est issu de mon expérience en informatique, il est cependant possible que certains points s’appliquent à d’autres disciplines.

Prendre l’avis de chercheurs expérimentés

Les chercheurs expérimentés dans un domaine connaissent les revues et conférences habituelles de ce domaine ainsi que leur niveau de sélectivité.

Caveat : ce critère peut encourager à toujours publier dans les mêmes revues rassurantes de quelques grands éditeurs, même quand ces revues sont essoufflées et ne méritent plus la réputation qu’elles ont pu avoir, tandis qu’on ignorera comme suspectes des revues plus jeunes.

L’appel à publications

Les revues sérieuses sollicitent rarement les chercheurs pour qu’ils leur envoient des articles. À l’inverse, les publications bidons envoient des courriers électroniques de masse.

Caveat : il peut arriver que des coordinateurs de numéros spéciaux de revue cherchent à s’assurer d’un nombre suffisant de soumissions et sollicitent leurs collègues.

Les conférences sérieuses envoient un appel à communication, ne serait-ce que parce que les auteurs doivent respecter des dates précises d’envoi qu’il faut rappeler. Cet appel est diffusé via des listes ou sites thématiquement adaptés. À l’inverse, les conférences et publications bidons envoient souvent leurs sollicitations à des chercheurs hors de la discipline concernée.

Des appels répétés, avec décalage des dates de soumission, indiquent que la conférence s’inquiète de ne pas recevoir suffisamment de soumissions. Cela ne veut pas dire que la conférence est bidon, mais plutôt qu’il ne s’agit pas d’un événement des plus prestigieux.

Dans tous les cas, une conférence ou journal sérieux met en avant son comité scientifique (comité de sélection, comité éditorial…).

En revanche, les conférences ou journaux bidons tendent à mettre en avant des critères extra scientifiques tel que leur « facteur d’impact » ou l’indexation de la publication par des systèmes bibliométriques comme SCOPUS, voire Google Scholar — ce qui est d’autant plus ridicule que Google Scholar indexe tout le contenu d’apparence scientifique ouvertement accessible sur le Web. De même, certains journaux peu sérieux indiquent qu’ils sont « prestigieux » — or quand on est véritablement prestigieux, on n’a pas besoin de le dire, tellement cela va de soi.

L'évaluation

Une conférence ou une revue sérieuse doit avoir le temps d'expertiser les articles, ce d'autant plus qu'elle en reçoit beaucoup et que ceux-ci sont longs et techniques. Les referees doivent placer le travail d'évaluation dans un emploi du temps souvent déjà très chargé. Un article accepté en quelques jours n'a donc probablement pas été sérieusement expertisé.

Le lieu de la conférence

Les conférences bidon cherchant à attirer les chercheurs peu scrupuleux en quête de vacances frais payés tendent à être organisées dans des lieux touristiques (Las Vegas, Orlando, les îles grecques…).

Caveat : il peut exister d’excellentes raisons d’organiser une conférence sérieuse dans de tels lieux, notamment la présence d’une bonne capacité hôtelière, de centres de congrès, d’un aéroport bien desservi... Par ailleurs, il ne faut pas oublier qu’un lieu touristique peut avoir des habitants y compris des scientifiques — je suis ainsi allé deux fois en conférence à Venise tout simplement car ces années là c’étaient des collègues de l’Université de Venise qui organisaient.

Le comité scientifique

Une conférence ou journal sérieux fait sélectionner les communications acceptées par un comité composé de scientifiques compétents du domaine, de préférence jouissant d’une certaine reconnaissance de leur pairs. (Cela ne veut pas dire que le comité doit être composé exclusivement de « mandarins », car on sait bien que ceux-ci sont souvent trop occupés pour bien faire leur travail éditorial.)

S’agissant de disciplines où l’on s’attaque à des problèmes qui ne sont pas propres à un pays ou une langue, on s’attend à un comité international. En informatique, cela veut dire qu’il y aura des membres en poste aux États-Unis et/ou Canada, en Europe occidentale et centrale, au Japon et/ou Corée, éventuellement en Australie et/ou Nouvelle-Zélande, en Inde, parfois en Chine, Brésil, Argentine, Chili. Un comité ne comprenant que des membres d’un seul pays peut être suspecté d’être une « bande de copains » pratiquant l’autopromotion.

Caveat : il va sans dire qu’il est normal que le comité d’une conférence française, destinée à faciliter les rencontres, les collaborations et la vie d’une communauté scientifique française, soit principalement composé de chercheurs français.

Les membres du comité doivent être clairement identifiés. En informatique, on donne généralement un lien vers leur page Web professionnelle, qui comprend elle même généralement un lien vers une liste de publications ou d’autres indications démontrant leur activité scientifique.

À l’inverse, les publications et conférences bidons n’indiquent pas leur comité scientifique, ou encore celui-ci est composé d’inconnus.

Caveat : il arrive que des conférences et publications bidons ajoutent des scientifiques sérieux comme membres d’un supposé comité scientifique sans le consentement de ceux-ci (bien évidemment, ils ne sont pas sollicités lors du processus éditorial). Il arrive aussi que des scientifiques sérieux soient bernés : sollicités par un collègue pour être membre d’un comité, ils acceptent et découvrent trop tard qu’ils servent de caution à un processus non respectueux de la rigueur scientifique.

Les sollicitations à être membre du comité scientifique

La sollicitation pour être membre d’un comité scientifique vient ordinairement d’un collègue et non d’une maison d’édition. On peut d’autant plus suspecter une escroquerie si le courrier est exagérément flatteur mais semble ignorer le domaine d’activité précis de la personne sollicitée. Aucune revue respectable ne sollicite des chercheurs « à l’aveuglette » pour peupler son comité scientifique.

Les thématiques

Une conférence scientifique, un revue sérieuse a une thématique d’ensemble bien identifiée, souvent explicitée par une liste de sous-thèmes (voir par exemple l’appel à communications de CAV 2017). Ceci s’explique aisément : dans le cas d’une conférence ou d’une revue destinée à la publication de résultats originaux, et non de vulgarisation, il faut bien que le comité éditorial soit spécialiste des sujets traités ; par ailleurs l’assistance d’une conférence n’est souvent pas en mesure de suivre la présentation de résultats de recherche trop éloignés de ses thématiques.

Caveat : on sollicite parfois, dans une conférence thématique, des exposés hors de cette thématique ; il existe par ailleurs des conférences destinées à des échanges entre plusieurs champs scientifiques. Les exposés sollicités ne sont alors normalement pas des présentations de résultats originaux de recherche, mais plutôt des tutoriels, introductions, exposés de vulgarisation.

À l’inverse, les conférences bidons ont souvent des thématiques vastes et floues, utilisant des termes ronflants mais imprécis (par exemple « cybernétique » ou « systémique »), parfois groupant plusieurs disciplines sans grand rapport, ou encore mettent en avant des mots-clefs à la mode (par exemple Big Data ou Cloud).

Caveat : il existe dans les thématiques à la mode de vrais problèmes scientifiques et il peut donc être légitime d’organiser des conférences dessus. Par ailleurs, dans certaines disciplines scientifiques, il est de coutume d’organiser des grandes conférences à spectre thématique très large, mais qui sont en fait l’agrégation d’un très grand nombre de sessions thématiques, chacune gérée par des spécialistes de leur thème.

Il n’y a bien entendu rien de mal à pratiquer l’interdisciplinarité. Toutefois, les travaux interdisciplinaires posent des problèmes d’évaluation certains. Les domaines flous et mal définis, sans thèmes, méthodes ou communauté scientifique bien identifiée, attirent les escrocs.

L’éditeur ou l’organisation organisatrice

Une conférence organisée par une société savante reconnue (par exemple l’ACM) ou encore des chercheurs d’une université réputée, une revue ou compte-rendu de conférence publié par un éditeur connu (Springer LNCS...), peuvent jouir d’une présomption de sérieux. À l’inverse, il existe des éditeurs, notamment en Inde, spécialisés dans les publications peu sérieuses. Plus près de chez nous, mes collègues de sciences humaines me disent que certaines collections d’un éditeur parisien bien connu relèvent largement d’une publication à compte d’auteur sans véritable filtre éditorial (en clair, l’auteur est publié tant qu’il paye).

Caveat : Ce critère est à manier avec précaution.

  1. On a vu de grands éditeurs publier des ouvrages ou des revues de piètre qualité, des sociétés savantes (je pense notamment à l’IEEE) être insuffisamment regardants…

  2. Ce critère tend à conforter l’oligopole des grands éditeurs scientifiques (Elsevier, Springer) qui font des bénéfices considérables avec l’argent du contribuable.

Le faible rapport avec la fraude scientifique au sens ordinaire

Les revues et conférences vraiment bidons publient n’importe quoi, mais en même temps personne ne consulte leurs articles.

La fraude scientifique au sens ordinaire consiste d’une part à truquer des résultats (prétendre que des expériences ont réussi alors que non, ignorer délibérément que des expériences ont échoué, etc), d’autre part à plagier des résultats existants (ce qui peut d’ailleurs se faire de façon plus adroite qu’un simple copier-coller), dans le but de publier dans des lieux prestigieux, ceci afin de promouvoir sa carrière ou de solliciter des financements.

Or, en informatique du moins, on ne promeut pas efficacement et à long terme sa carrière en publiant dans des revues bidons (si on les liste dans son CV, on se « grille » vite — il ne faut d’ailleurs pas oublier que les collègues parlent entre eux et que les comportements douteux finissent par être connus bien au-delà du laboratoire). Par ailleurs, il n’y a pas besoin d’inventer des résultats enthousiasmants pour publier dans les revues bidons, puisque celles-ci ne vérifient pas le contenu des articles.

Il s’agit donc de deux phénomènes séparés, même s’ils ont une cause commune : la volonté d’embellir CV et compte-rendus d’activité.

jeudi, juin 29 2017

Enquête sur un bug

Le débogage informatique, c’est difficile : il faut des connaissances techniques, une tête froide, beaucoup de logique, de méticulosité... et même d’inventivité, car il faut imaginer l’inimaginable. D’ailleurs, les étudiants, même dans des filières très sélectives, ont souvent beaucoup de mal à s’y mettre.

Je conseille le récit de cette recherche de bug, mettant en jeu Ahrefs, une entreprise avec des racines en Ukraine, des bureaux à San Francisco et son siège à Singapour, les développeurs d’OCaml, de l’INRIA et d’autres organismes, et enfin Intel, le géant des microprocesseurs. C’est quasiment une enquête policière… on perçoit les abîmes de perplexité des personnes impliquées.

On peut aussi consulter la page de suivi du bug chez OCaml, la liste des errata de ces processeurs chez Intel, les notes accompagnant le paquet Debian fournissant un microcode supprimant le bug, qualifié de nightmare-level; et (merci à mes lecteurs) un billet de Xavier Leroy.

PS J'ai un ordinateur portable avec un des types de processeurs concernés et j'ai eu des exécutions OCaml (la compilation de Coq) qui échouaient mystérieusement avant de réussir. Je n'avais pas creusé !

mercredi, juin 28 2017

Experts en cybersécurité

J’apprends qu’une émission de télévision a interrogé Alain Bauer au sujet des récentes cyberattaques.

Les organismes de recherche français (CNRS, INRIA, CEA, universités, écoles d'ingénieurs…) ainsi que des services gouvernementaux (ANSSI, DGA-MI...) ont des experts en sécurité informatique.

Ceux-ci ne sont pas forcément difficiles à trouver. Une recherche Google sur « CNRS sécurité informatique » donne en premier choix l’adresse d’un colloque « Sécurité informatique, mythes et réalité ». On y trouve très rapidement le nom d’intervenants tels que Gildas Avoine, Marc-Olivier Kiljian, le colonel de gendarmerie Éric Freyssinet, Jean-Yves Marion, etc. On peut aussi tout simplement penser à Guillaume Poupard, le directeur de l'ANSSI.

On peut donc se demander pourquoi on ne fait pas appel à eux. Se pourrait-il que ce soit parce que les scientifiques et les vrais experts ne parlent pas avant de s’être renseignés ?

mardi, juin 27 2017

Quelques précisions sur les concours de recrutement de chercheurs au CNRS

Il est rare que le résultat des concours de recrutement dans l’enseignement supérieur et la recherche fasse l’objet de polémiques publiques. C’est pourtant le cas des concours de chargé de recherche au CNRS de cette année, plus précisément de ceux de l’Institut des sciences humaines et sociales (InSHS), une des divisions de cet organisme ; on en parle dans Le Monde et sur France Culture ! C’est l’occasion pour moi de revenir sur le déroulement de ce concours.

Quand on parle de concours de la fonction publique, on imagine une suite d’examens écrits et oraux, plus ou moins scolaires, portant sur les connaissances générales et spécifiques attendues du personnel recruté. Les concours de recrutement de chercheurs ne se déroulent absolument pas comme cela.

Le candidat (ou la candidate, bien évidemment) soumet en ligne un dossier comportant d’une part un résumé de ses travaux de recherche précédents (y compris une liste de publications, brevets, etc.) d’autre part un projet de recherche et d’intégration dans des laboratoires du CNRS. En effet, le travail de recherche scientifique, une fois mené, se concrétise principalement sous la forme de publications décrivant les résultats auxquels on est arrivé, dans des revues ou ouvrages spécialisés, après passage devant un comité de lecture et de sélection.

On vérifie d’abord si le dossier est complet et si le candidat vérifie les conditions légales pour concourir, c’est-à-dire la possession d’un doctorat (sauf dispense par une commission scientifique). Le candidat est déclaré « admis à concourir ».

Le dossier est examiné par une commission compétente pour la discipline concernée (on peut candidater dans plusieurs disciplines en même temps), formée de membres élus par les chercheurs du CNRS et par des enseignants-chercheurs ou chercheurs d’autres organismes. Il s’agit, plus précisément, soit d’une section du Comité national de la recherche scientifique (qui a pour autre rôle notamment d’évaluer les chercheurs du CNRS et de se prononcer sur leurs promotions) soit d’une commission interdisciplinaire. Ces sections et commissions sont numérotées, c’est pour cela que dans les articles de presse cités on parle de postes de section 36, 39, etc.

À l’issue de cet examen, une partie des candidats (mettons la moitié) sont admis à poursuivre et à se présenter à une audition où ils présenteront leurs travaux, leur projet et répondront à des questions. L’utilité de cette audition, brève en raison du nombre importants de candidats à passer, est discutée, notamment en raison de la rigidité administrative qu’elle impose (on fait venir, à leur frais, des candidats parfois de très loin, et l’absence est éliminatoire).

La commission produit un classement d’admissibilité, comportant habituellement plus de candidats que de postes à pourvoir (un concours est habituellement ouvert pour quelques postes, voire un seul). Ce classement est ultérieurement transmis à un jury d’admission, commun à plusieurs sections ou commissions, qui établit un classement définitif en sélectionnant parmi les admissibles. Ce jury d’admission est lui aussi formé de scientifiques du domaine, dont des représentants des sections compétentes et des personnalités scientifiques extérieures nommées par la direction — je précise cela, car certains propos tenus dans l’actuelle polémique suggéraient qu’il comprenait des « administratifs ». On m’a toutefois plusieurs fois suggéré que l’avis de la direction de l’institut y est important.

Le plus souvent, le classement d’admission, comportant une liste principale d’autant de candidats que de postes, puis une liste complémentaire, reproduit celui d’admissibilité, à l’exception de candidats ayant démissionné du concours (par exemple, parce qu’ils ont obtenu un poste à l’étranger). Parfois, le jury d’admission permute des candidats de la liste complémentaire, ce qui a une importance notamment si des postes non pourvus sur d’autres concours sont redéployés, ce qui permet de recruter un candidat de plus que le nombre initialement prévu sur un concours donné. Il est en revanche rare que des candidats en liste principale soient déclassés, et c’est ce qui suscite la polémique.

L’an dernier, le jury d’admission de l’institut d’informatique (InS2I) a déclassé des candidats en liste principale (voir le classement d’admissibilité et le classement d’admission), ce qui a provoqué une polémique entre la section 6 et la direction de l’institut, la première publiant une motion, la seconde répliquant par un courriel aux laboratoires dans laquelle elle détaillait les raisons du jury d’admission. Je ne citerai pas in extenso ce courrier, mais on y évoquait la nécessité d’équilibrer les thématiques (le jury d’admissibilité ayant favorisé certains thèmes de recherche, très théoriques, au détriment des autres) et les provenances (quatre candidats classés ayant leur directeur de thèse ou leur co-directeur de la même équipe du même laboratoire).

Je serais donc curieux d’en savoir plus sur les raisons des jurys d’admission InSHS de 2017, au delà des postures convenues.

Réf: Décision de constitution auprès de chacun des instituts du CNRS d'un jury d'admission pour les concours de recrutement des chargés de recherche ouverts au titre de l'année 2017, réf. DEC171262DRH, Bulletin officiel du CNRS, avril 2017, pp 244-251

PS Ce billet, rédigé sur mon temps libre, ne comporte ni approbation ni improbation des positions du CNRS, et n'est pas non plus une référence officielle concernant la procédure des concours — seuls les textes et sites officiels font foi.

PS² Réaction du conseil scientifique de l'InSHS, et réaction de la direction du CNRS à la polémique.

mercredi, juin 21 2017

Le chercheur et la vie réelle

Les réseaux sociaux ont beaucoup bruissé hier de cette attaque du député Jean-Luc Mélenchon envers le député et ex-collègue Cédric Villani :

Il y en a quand même, ils [ne] sont au courant de rien, donc quand on va leur expliquer… Non mais il y a des braves gens là-dedans ! Il y a des braves gens ! Bon il y a beaucoup de DRH, des gens comme ça qui ont une conscience sociale assez faible (pas toujours, hein !), mais il y a beaucoup de…[fait des moulinets avec sa main au dessus de sa tête] des chercheurs, des intellectuels, des chais pas quoi… J’ai vu le matheux là, je vais lui expliquer ce qu’est un contrat de travail, il va tomber par terre ! Parce qu’il [ne] le sait pas, tout simplement, il [ne] sait pas ce qu’il y a dedans ! Il ne sait pas que la journée de huit heures, c’est cent ans de luttes ! Le gars il croit que ça a toujours été comme cela !

Cédric Villani a répondu ainsi :

Cher @JLMelenchon, Directeur de l'IHP, j'en ai vu des contrats de travail... mais c'est tjs un plaisir de recevoir des cours particuliers !

Beaucoup de choses ont été dites suite à cette passe d’armes, mais je voudrais donner quelques points factuels.

L’image d’Épinal du chercheur est un être quelque peu fantasque et déconnecté du réel, à l’apparence excentrique, distrait et pas fait pour gérer des réalités terrestres, comme Tryphon Tournesol. Cédric Villani a d’ailleurs abondamment joué de son apparence pour construire sa présence dans les médias — bien entendu, la plupart des chercheurs, fussent-ils en mathématiques, ont une allure bien plus passe-partout. Au-delà de ces aspects superficiels, qu’en est-il réellement ?

En 2017, un chercheur qui veut disposer de moyens doit répondre à des appels à projets de recherche, pour lesquels on lui demande la présentation d’un budget, qui peut faire apparaître des coûts salariaux. Je passe à mes lecteurs la liste détaillée des amusants aspects extra scientifiques à prendre en compte — amortissement du matériel, cotisation ou absence de cotisation chômage, calculs de gratifications de stage, TVA, partage de propriété intellectuelle, règlement financier de l’appel à projet, etc. Très souvent, le chercheur n’est guère aidé pour cela par les services administratifs et doit donc apprendre « sur le tas ».

Quant à un directeur d’unité tel que Cédric Villani, si normalement ce n’est pas lui qui signe in fine le contrat de travail au nom de l’établissement, c’est parfois lui qui organise les recrutements de contractuels (cela peut aussi être un chef de service ou de projet qui le fait), et bien sûr il voit normalement passer pour approbation tous les contrats de travail des contractuels rattachés à sa structure. Là encore, je passe à mes lecteurs la complexité de la gestion administrative et financière d’une unité avec plusieurs tutelles, chacune ayant ses propres marchés publics, ses propres particularités d’emploi.

Bien entendu, cela ne fait nullement du chercheur, fût-il directeur d’unité, un fin connaisseur des aspects financiers et administratifs ou du droit du travail des fonctionnaires et des contractuels de la fonction publique. En même temps, il est bien forcé de s’y intéresser un tant soit peu, sauf à aller au devant de graves problèmes...

(Sinon, il me semble bien que les luttes sociales étaient au programme d’histoire du baccalauréat C du temps où Cédric Villani l’a passé ; cela sans présager de son attention sur cette partie du programme.)

jeudi, juin 15 2017

Les limites de ma vulgarisation

Le ''Journal du CNRS'' m'a sollicité ce printemps pour deux articles qu'ils ont mis en ligne :

  1. Un point de vue sur la question de l'usage des « algorithmes » par les pouvoirs publics et les questions qu'il faut se poser en matière de transparence, d'opposabilité et de contrôle démocratique.
  2. Un article plus relié à mon domaine de recherche sur les méthodes pour assurer la fiabilité des logiciels de contrôle-commande en avionique, sujet qui m'a beaucoup occupé de 2002 à 2007.

J'ai par ailleurs publié avec Virginie Gautron un article aux Archives de politique criminelle un article sur l'usage des « algorithmes » pour rechercher des profils suspects dans la population.

Si je suis effectivement expert en méthodes formelles et j'ai effectivement réalisé avec d'autres des outils industriels dans ce domaine, je ne suis expert ni en méthodes d'apprentissage ni en leur application aux problèmes sociaux ou juridiques ; se pose donc la question de ma légitimité à écrire sur ces sujets.

Je m'en suis évidemment tenu à des généralités que n'importe quel scientifique du domaine qui se tient un peu au courant pourrait énoncer, par exemple au rappel de faits statistiques de base; j'ai par ailleurs fait relire une partie de mes propos par des spécialistes. Pourtant, je ne me sens guère à l'aise, et j'ai d'ailleurs tenté de rediriger mes interlocuteurs vers des collègues plus à même de répondre à leur demande.

J'éprouve, je ne le cache pas, un certain agacement quand je vois des universitaires, faisant état de leurs titres et en tirant légitimité pour s'exprimer en public, parler de sujets qu'ils ne connaissent guère pour dire au mieux des platitudes, au pire des faussetés. Le danger est donc pour moi de me comporter d'une façon que je réprouve chez les autres.

D'un autre côté, il semble que les instances de médiation scientifique, les collègues d'autres disciplines voire les pouvoirs publics manquent d'interlocuteurs scientifiques en informatique. Si personne n'accepte ce rôle, fût-ce pour parler de domaines qu'ils ne connaissent que de loin, ils trouveront d'autres interlocuteurs, encore moins qualifiés. Par ailleurs, le niveau d'explications à fournir n'est souvent guère élevé et ne nécessite pas de connaissances approfondies ; après tout, on attend d'un enseignant-chercheur en informatique qu'il puisse assurer des enseignements de licence même s'ils ne portent pas sur sa spécialité !

Qu'en pensez-vous ?

mercredi, mai 31 2017

Sécurité informatique, soupir

Je reviens d’un petit colloque sur la sécurité informatique. Quelques réflexions.

Complexification

Les ordinateurs personnels d’il y a une trentaine d’années étaient simples. Une documentation technique très complète du système (instructions du processeur, registres des contrôleurs d’entrée sortie, appels systèmes…) pouvait être fournie en quelques volumes. En revanche, les ordinateurs actuels (qu’il s’agisse de machines de bureau, de portables ou de smartphones) sont très complexes. La documentation de l’architecture x86 prend plusieurs milliers de pages.

Il y a trente ans, un développeur (même novice) pouvait rapidement maîtriser une grande partie du fonctionnement de sa machine. De nos jours, c’est impossible : il y a trop de choses, qui changent qui plus est toutes les quelques années. Il y a vingt ans, je comprenais à peu près le fonctionnement d’un système Linux (mais pas le détail), de nos jours il y a bon nombre de zones mystérieuses.

Dans l’exposé d’Éric Freyssinet et les interventions de Jean-Yves Marion, on a bien senti la même évolution dans le développement des outils d’intrusion informatique. Le cliché des films est le « petit génie » de l’informatique opérant isolément : or les attaques sont complexes à mettre en œuvre et mettent souvent en jeu plusieurs groupes de personnes, chacun spécialisé sur une partie du problème.

Parallèlement, on assiste à une fuite en avant et une complexification des mesures de sécurité. Il y a longtemps, sur un système Unix, il existait les processus utilisateurs, les processus privilégiés (ceux de l’utilisateur root) et le noyau du système. Maintenant, on a éventuellement au dessus du noyau un hyperviseur, peut-être lui même virtualisé dans un autre hyperviseur… voire un composant matériel « sécurisé » indépendant du processeur principal.

Bien entendu le logiciel se complique aussi. Aux débuts du Web, le trafic passait « en clair » (http) sur le réseau, de sorte que toute personne qui avait accès aux équipements réseau pouvait espionner le trafic. Récupérer une page Web était relativement simple. Depuis on est largement passé à une transmission chiffrée (https), plus sûre mais aussi considérablement plus complexe pour le logiciel.

Plus un système est compliqué, plus il offre de possibilités d’erreur et de « surface d’attaque ».

Une pensée a posteriori

Comme on le voit bien sur l’exemple de http suivi de https, la sécurité est souvent rajouté a posteriori par-dessus une fonctionnalité. Ceci conduit à des systèmes complexes et parfois assez baroques.

Mais qui a pu avoir une idée pareille ?!

Au récit du fonctionnement technique de certaines attaques, on se demande comment quelqu’un a pu penser que c’était une bonne idée que de concevoir le système attaqué en y laissant une faille béante. Quelques exemples :

  1. L’Étoile de la Mort de l’Épisode IV de la Guerre des Étoiles a une bouche de refroidissement dans laquelle un simple tir par un appareil de combat léger provoque sa destruction totale.

  2. Un périphérique Firewire avait naguère le droit d’initier un transfert de ou vers la mémoire de la machine sur laquelle il était branché sans contrôle de ce à quoi il avait le droit d’accéder — on vous prêtait une caméra ou un disque dur, celle-ci pouvait donc prendre le contrôle de votre machine.

  3. Certaines machines à base de processeurs Intel avaient une console de commande système à laquelle on pouvait accéder en fournissant un mot de passe vide — apparemment, elle vérifiait que le mot de passe fourni par l’utilisateur était le bon en ne comparant que jusqu’à la longueur du mot de passe fourni par l’utilisateur…

  4. Quelqu’un avait cru bon de modifier le générateur de nombres aléatoires d’OpenSSL d’une façon qui réduisait considérablement son aléa et rendait des clefs de chiffrement trouvables par recherche exhaustive, car la modification supprimait un avertissement dans un outil de recherche de bugs.

On en est au point parfois où l’on se demande s’il s’agit d’incompétence ou d’erreurs sciemment mises en place à la demande de tel ou tel service.

Internet of Things

Les entreprises qui vendent des objets connectés ont pour objectif d’arriver rapidement sur le marché ; la sécurité représente un surcoût en temps et en argent. Ces entreprises peuvent avoir un cœur de métier traditionnel (électroménager…) éloigné des réseaux et de la sécurité. Elles ne sont pas forcément prêtes à fournir des mises à jour de sécurité en continu (à l’inverse de fournisseurs de systèmes d’exploitation tels que Microsoft, Apple, ou Ubuntu). Comme on peut s’y attendre, la sécurité est faible.

On a, dit-on, des bot-nets de réfrigérateurs et de caméras de surveillances connectées. On s’attend à des bot-nets de voitures connectées. On espère, mais peut-être est-ce un fol espoir, que dans ces véhicules la partie compromise ne sera que le système de divertissement et non ce qui contrôle la conduite. Et que dire des dispositifs médicaux connectés !

Des systèmes sécurisés inutilisables donc inutilisés

En théorie, il est possible de chiffrer son disque dur (de façon à rendre les informations qui s’y trouvent illisibles pour un voleur, par exemple), de chiffrer son courrier électronique (de façon à ce que les opérateurs de réseau et hébergeurs de courrier ne puissent pas le lire), d’utiliser une messagerie instantanée chiffrée.

En pratique, peu de gens le font : les logiciels qui font cela ne sont pas installés par défaut, ils demandent une configuration spécifique (voire l’intervention de prestataires extérieurs), parfois ne fonctionnent pas pour des raisons mystérieuses. Même parmi les chercheurs en informatique, a priori un public a priori plus sensibilisé et apte techniquement que la majorité de la population, on sent ces difficultés.

Conclusion

Je ne déborde pas d’optimisme.

- page 1 de 94